PIC16F88X の I2C プロトコルを調べています。私がやりたいことは、I2C で受信したデータに応じて、I2C スレーブを ACK または NACK にできるようにすることです。
PIC は、回線上で送信された I2C アドレスに対して ACK または NACK を返すことができますが、私が読んだものからは、後続の受信バイトに対して常に ACK を返します。あれは正しいですか？
次の通信では:
Start - I2c_Addr+write/ACK - Register_value/Nack
レジスタ値の値に応じて、スレーブが Ack または Nack できるようにしたいと考えてい_ます。スレーブがレジスタの値を理解していない場合、応答しない_でください。
誰かがこれが不可能であることを確認するか、それを行う方法を教えてください。
MSSPペリフェラルを使用していると仮定します
短い答え: PIC では、少なくとも I/O ラインのビット バンギングがなければ、あなたが求めていることはおそらく不可能です。その理由は、9 番目のクロック エッジで ack/nack がチェックされ、9 番目のクロックの終わりまで SSPIF 割り込みが発生しないためです。データ バイトが I/O レジスタ (8 番目のクロック) にシフトされるとすぐに設定されるため、BF ビットを繰り返しチェックすることを試みることができます。比較を実行して 9 番目のクロック サイクルの前に SSPOV ビットを設定できる場合、これは NACK を生成するはずですが、実行中の割り込みがある場合、これは非常に大ざっぱです。
より長い答え: スレーブが受信したデータ バイトが有効であるか、ack を使用していないかどうかを検証しようとしているように思えます。個人的に私はこれをしません.ackはデータの完全性を検証するのではなく、回線の完全性を知らせることです. デバイスがスレーブである場合、マスターは定義上、それがどのように動作するかを正確に認識し、I2C ラインにプッシュする前にバイトの有効性をチェックできる必要があります。このような場合、I2C マスターのコードも制御できると仮定し、送信できるすべてのコマンドまたは有効なデータ バイトを定義する 1 つの共通ヘッダー ファイルを使用して、コードの不一致を回避します。
何らかの理由で適切なバイトが送信されたことを保証する必要がある場合は、マスターがスレーブに応答バイトを要求し、スレーブが前の転送の結果を示すコードを返すようにします。
I2C ラインの完全性を保証することが目的の場合、これらのアプローチはどれも実際には機能しません。唯一のオプションは、ブート時に大量のバイトを送信するか、CRC を使用して定期的に送信し、スレーブで一致することを確認することです。一般に、I2C ラインは動作するかどうかのいずれかであり、低速であり、一般にトレースが短く、許容バス容量が大きく、動作しない場合は ack がまったく表示されません。
I2CハードウェアがPICに組み込まれている場合、私の推測ではありません。私が使用したすべてのハードウェアソリューションには、送信に問題がない限り（たとえば、ビットが欠落している場合）、2番目のバイトをACKする以外に方法がないステートマシンがあります。ビットバンギングとACK用のオープンコレクタバッファを備えたソフトウェアで独自のI2C実装を作成する方がよいでしょう。その後、あなたはあなたがやりたいことを何でもすることができます。I2C標準ではないため、仕様どおりに機能しないデバイスをバスに配置する場合は注意が必要です。オフハンドかどうかはわかりませんが、標準のI2Cデバイスの場合、ACKを受信しないと、データを再送信するか、障害後に誰がバスを制御できるかわからないため、障害が発生する可能性があります（NAKによって示されます）。 ）。