Frage zu Err Flag bei TWI/I2C

Hi!
Nach langer Zeit habe ich mal wieder eine Frage an alle, da ich darüber keine Informationen im Netz gefunden habe und hoffe, dass jemand von euch Ahnung dazu hat.

Mein momentanes Problem ist, dass ich zw. zwei µCs (ATM2560 und ATM88) eine I2C Verbindung mit Hilfe der TWISLAVE Libary aufgebaut habe. Der ATM88 ist der Slave. Nun sende ich ein Byte an den ATM88 und lese danach die Variable Err aus, die auf 0 gesetzt wird, wenn es keine Fehler gab und auf 1, wenn es einen Fehler gab. Im Falle von 1 sende ich das Byte so lange, bis Err 0 ist.
Allerdings passiert es öffters, dass das Err auf 0 gesetzt wurde, obwohl das Zeichen nicht oder nicht richtig beim Slave, dem ATM88, ankam.

Meine Frage ist nun: Wird Err auch auf 0 gesetzt, wenn etwas gesendet wurde, aber nicht garantiert wird, dass auch das Gewünschte angekommen ist?
Wenn das so ist, wer hat eine Idee, wie ich überprüfen kann, ob beim Slave das Richtige angekommen ist?

Ich hoffe, ich versteh mein Problem und könnt mir helfen!
Viele Grüße,
jon

soweit ich weiß, kann wird im TWI-Protokoll nicht geprüft, ob alle Bits richtig übertragen worden sind (Stichwort Checksumme). Meines wissens nach funktioniert es so, dass der Master ein Byte überträgt und der Empfänger ein Acknowledge sendet, wenn er der Meinung ist, dass er alle Bits korrekt empfangen hat. Sollte aus irgendwelchen Gründen wärend der Übertragung aus einer 1 eine 0 werden, so wird dieser Fehler nicht bemerkt.

Ok. Eigentlich schade...
Deswegen nun meine weiterführende Frage, die sich nach einer Antwort sehnt^^: Wie kann ich überprüfen, ob das Richtige angekommen ist? Gibt es da eine zuverlässige Möglichkeit?

Schon mal Danke für deine Antwort!
jon

Wie schon mal gesagt, kann man bei der Übertragung nur feststellen, ob alle 8Bit durch sind, dann sagt der Emfpänger ACK.
Ob das die richigen waren geht erstmal nicht.
Man könnte gleich nach dem Senden zurücklesen,
oder eine Checksumme anhängen, damit der Empfänger selbst feststellen kann ob die Daten an sich OK sind.
Evtl. ist der Slave auch abgelenkt und verbummelt die Daten :-k

Spätestens hier ist man an dem Punkt, das man sich ein Protokoll überlegen muss..

Nur der Sender, also der, der SDA bedient, kann erkennen, ob seine Bits korrekt durch sind.
Der Listener nicht, aber gerade der soll ja ACK oder NAK setzen.

Es gibt einige Libraries, die diese "Eigenprüfung" unterlassen, das ist natürlich schlampige Arbeit, genau wie das Erkennen eines Bit-stretching durch den Taktgeber.

Bei Überlegungen zur Verbesserung durch CRC oÄ ist halt das Problem, dass ein standard I2C Baustein da nicht mitspielt. Ein IO Expander setzt das um, was er zu empfangen glaubt

Grundsätzlich brauchst du dafür irgendwas wie eine Prüfsumme. Wenn du mehrere Bytes verschickst, dann mach z.B. ein XOR (EOR) über alle Bytes und hänge das an. Der Empfänger muss dann nur Prüfen ob die Prüfsumme stimmt. Natürlich kann man damit nicht alle Fehler erkennen, aber es sollte eine Verbesserung geben.
Wenn die Prüfsumme falsch ist müssen aber alle Bytes natürlich nochmal gesendet werden, da du nicht weißt wo genau der Fehler liegt.

Das ganze musst du aber per Software machen, I²C an sich kann sowas nicht.

Hi!
@PicNick, weißt du, ob da die TWISLAVE Library von mcselec schlampig, oder ordentlich arbeitet? (Es darf auch jeder andere auf diese Frage antworten^^)

jon

Da diese SLAVE-Library kostenpflichtig ist, hab ich das noch nicht checken können.
Die Soft-I2C Routinen vom Bascom jedenfalls
https://www.roboternetz.de/wissen/in...e#I2C_Software
kümmern sich jedenfalls NICHT um die Datenbits, das stretchen checkt er allerdings schon

Bei HW-TWI gottseidank passt die Hardware auf und setzt den Status "Bus Lost", wenn was mit den Daten ist. Das landet bei Bascom üblicherweiser alles in dem gleichen ERR-Bit.
Dadurch kann man aber nicht unterscheiden, ob ein ACK fehlt oder ob die Daten vernudelt worden sind.
So oder so: Man hat keine standard TWI-Möglichkeit, dem Empfänger zu sagen, dass er gerade Schrott empfangen hat.