PIC I2C Slave ack auf Daten

Question

Ich untersuche das I2C-Protokoll für PIC16F88X. Was ich tun möchte, ist, einen I2C-Slave entweder ACK oder NACK zu aktivieren, abhängig von den Daten, die auf dem I2C empfangen werden.

Der PIC kann ACK oder NACK auf der I2C-Adresse gesendet auf der Leitung, aber von dem, was ich gelesen habe, wird immer ACK auf die folgenden empfangenen Bytes. Ist das korrekt?

In der folgenden Mitteilung:

Start - I2c_Addr+write/ACK - Register_value/Nack 

ich den Slave möchte in der Lage sein Ack oder Nack je nach dem Wert in Register _ Wert. Wenn der Slave Register _ Wert nicht versteht, sollte es nicht Ack.

Könnte jemand bitte entweder bestätigen, dass dies nicht möglich ist, oder mir sagen, wie es geht?

Answer 1

Ihr Unter der Annahme der MSSP periphere

kurze Antwort mit: Was für fragen ist nicht wahrscheinlich möglich, mit einem PIC, zumindest ohne Bit hämmert I/O-Leitungen. Der Grund dafür ist, dass ack/nack an der 9. Taktflanke überprüft wird und der SSPIF-Interrupt erst am Ende des 9. Takts ausgelöst wird. Sie könnten versuchen, das BF-Bit, wie es gesetzt ist, wiederholt zu überprüfen, sobald das Datenbyte in das E/A-Register (8. Takt) geschoben wird. Wenn Sie einen Vergleich durchführen und das SSPOV-Bit vor dem 9. Taktzyklus setzen, sollte dies einen NACK erzeugen, dies ist ziemlich skizzenhaft, wenn Sie Interrupts laufen haben.

längere Antwort: Es klingt wie Ihr Versuch zu validieren, wenn das Datenbyte, das der Slave empfängt, gültig ist oder nicht ack verwendet. persönlich würde ich das nicht tun, ack ist es, die integrität der linie zu signalisieren, datenintegrität nicht zu verifizieren. Wenn das Gerät ein Slave ist, muss der Master per Definition genau wissen, wie es funktionieren soll und kann die Gültigkeit des Bytes überprüfen, bevor es auf den I2C-Leitungen ausgegeben wird. In solchen Fällen gehe ich davon aus, dass Sie auch die Kontrolle über den I2C-Master-Code haben, eine gemeinsame Header-Datei verwenden, die alle Befehle definiert, oder gültige Daten-Bytes, die gesendet werden können, um Fehler im Code zu vermeiden.

Wenn Sie aus irgendeinem Grund sicherstellen müssen, dass das richtige Byte gesendet wurde, lassen Sie den Master den Slave nach einem Antwortbyte fragen, lassen Sie den Slave einen Code zurückgeben, der das Ergebnis der vorherigen Übertragung angibt.

Wenn Sie die Integrität der I2C-Linie garantieren möchten, funktioniert keiner dieser Ansätze wirklich. Ihre einzige Option wäre, eine Menge von Bytes beim Booten oder periodisch mit einem CRC zu senden und zu überprüfen, ob es auf dem Slave übereinstimmt. Im Allgemeinen werden I2C-Leitungen entweder funktionieren oder nicht, sie sind langsam, haben im Allgemeinen kurze Leiterbahnen und haben eine hohe zulässige Buskapazität, wenn sie nicht funktionieren, werden Sie überhaupt keine Ack sehen.

Answer 2

Meine Vermutung ist nein, wenn die I2C-Hardware in den PIC integriert ist. Alle Hardwarelösungen, mit denen ich gearbeitet habe, haben eine Zustandsmaschine, die nicht anders kann, als das zweite Byte zu ACK zu machen, es sei denn, etwas stimmt nicht mit der Übertragung (ein Bit fehlt zum Beispiel). Sie sollten besser Ihre eigene I2C-Implementierung in Software mit Bit-Banging und einem Open-Collector-Puffer für die ACK machen. Dann können Sie alles tun, was Sie wollen. Es wird kein I2C-Standard sein, also seien Sie vorsichtig, wenn Sie Geräte an den Bus anschließen, die nicht Ihren Spezifikationen entsprechen. Ich bin mir nicht sicher, aber ich denke für jedes Standard-I2C-Gerät, wenn es kein ACK empfängt, kann es die Daten erneut übertragen oder einfach nur fehlerhaft, da es nicht sicher ist, wer den Bus nach einem Fehler kontrolliert (signiert von einem NAK)).