MIDI-IF送受信のデータバッファは、同じものを使うように大幅に修正。
送受信のバッファリング部分を共通化するとともに、割り込み処理で行う場合もあるため、間接アドレスを使う部分はバックアップするのと、割り込みと通常処理がバッティングしないように、排他処理の見直し。
一時間くらいで修正完了。バッファは40バイト確保できたので、なんとか大丈夫。取りこぼし（バッファオーバーフロー）は起こしていません。
I2C通信でのEEPROMへ書き込む処理も一応、できました。
続いて、読み取り処理なので、作成したことがあるので、大体のフローはわかっています。そんなに時間は、かからないと始めたのですが、不可解な現象に悩まされています。
すでに５時間くらいかなぁ。。。。
EEPROMからデータ送信しないので、プロトコルやPIC側の設定を何度も見直しているのですが、ロジアナで見ると、恐ろしいことが、、、
以下が、マスタ受信の手順
- START信号（SEN）
- コントロールデータ（0xA8）送信：EEPROMからACK応答あり
- アドレス2バイト送信：EEPROMからそれぞれACK応答あり
- RESTART信号（RSEN)
- コントロールデータ（0xA9）送信：EEPROMからACK応答あり
- 受信開始（RCEN）
- BFが１になったら、SSP1BUFからデータ取得
- ACK応答して次のデータ受信処理、またはNACK応答してSTOP処理（PEN）
不可解な現象は、６の段階で、SCLからクロックが出ないのです。なので、当然、EEPROMも、クロックに同期させたデータを返せないです。そう、PIC側の問題。
多分、何か暗黙の設定が必要なのでしょう。SCL/SDA(RC0/RC1)は、受信ポートにしてデジタルポートにしています。I2Cのイネーブルにしています。すでに、送信はできているので、受信に関してなにか設定（呪文）があるのかな。。。。
I2C割り込みフラグ、各種有効化ビット、エラーフラグ（コリジョン、オーバーフロー）なども見直しています。バッファの空読みをしても変わりません。
クロックが出ないってどういうこと！？
＜追記＞
クロックストレッチと言って、スレーブ側がデータ転送を遅延させるために、SCLをLOWに保持させることができるようです。うーん、これが起きているのか！？