Xmega TWI-Master, riesiger timeout gewollt?

Hallo,

ich habe hier einen code, in dem ich TWIInpPC in einer Loop Schleife aufrufe.
Vor und direkt nach dem Aufruf erzeuge ich einen Puls, den ich zusammen mit SDA und SCL mit einem Oszilloskop aufzeichne (siehe Fotos).

Es ist kein Slave angeschlossen.

Folgt auf das Adressbyte kein Acknowledge (NACK, SDA bleibt high), dann wartet die Routine >100ms. Zusätzlich wartet die Routinne bei erneutem Aufruf >100ms bevor sie das Adressbyte sendet.

Ist das so gewollt? Sollte die Routine nicht unmittelbar mit einem false zurückkehren?

Ich möchte den TWI-Master Treiber für die Kommunikation mit einem anderen Prozessor benutzen und das NACK für eine Flusskontrolle verwenden. Lange Wartezeiten wären störend.

Gruß

Thomas

Hallo Rolf,

gestern ist mir das aber auch aufgefallen, habe aber noch keinen OSZI dran gehängt.

Wenn ich einen SCAN mit TWISTAT mache dauert es deutlich länger als wenn ich den I2CSTAT auf dem XMEGA nutze. Wenn ich ein neues Board mit I2C durchteste lasse ich meist eine Schleife durchlaufen Adr 1-127 um zu prüfen, das ich keine Fehler gemacht habe und der TWISTAT hat ca. die 3-4 Fache Zeit gegenüber dem I2CStat gebraucht. War für mich jetzt nicht dramatisch, aber man merkt es schon. Eigentlich müsste doch die Pause bei beiden gleich sein? Oder ist der I2C mit Software einfach schneller?

Gruss
Thorsten

Sorry Rolf,

ich verstehe absolut nicht, wieso hier der lange timeout nötig ist.
Bei einer I2C Kommunikation sendet der Master eine Start condition + Adressbits + RWBit und ckeckt bei seiner 9-ten SCL HighFlanke, ob ein Acknowledge vom Slave gesendet wurde. Wenn kein Acknowledge gesendet wurde, muss der Master abbrechen. Worauf soll er denn dann noch warten? Ich hab ja hier kein Clock Stretching vom Slave. In diesem Fall müsste der Master warten.
Der lange timeout ist besonders beim Pollen von Slave-Adressen störend, wie Thorsten bereits anmerkte.

Habe ich etwas falsch verstanden?

Im meinem zweiten Foto sieht man übrigens noch eine stop condition vor der start condition. Komisch ist auch, dass der timeout zweifach zuschlägt. Ich habe > 200ms Pause auf den SDA/SCL Leitungen.
Erklärungsversuch: Master starte Kommunikation und läuft in den timeout. TWIInpPC kehrt ohne Senden einer stop condition mit false zurück.
Bei erneutem Aufruf von TWIInpPC wird zuerst 100ms gewartet, dann mit einer stopcondition das "alte" abgebrochen und mit einer neuen start condition eine neue I2C Kommunikation eingeleitet.


Gruß

Thomas

Hallo Rolf,

ich muss leider widersprechen.

Ein I2C-Slave muss sich nach Empfang der Addressbits sofort entscheiden und dann während der 9-ten SCL Flanke entweder die SDA-Leitung oder die SCL Leitung auf low ziehen (acknowledge oder clock-stretching). Dies ist zeitkritisch und nur sicher in Hardware ausführbar bzw. in einem schnell reagierenden Interrupt.
Tritt keiner der beiden Fälle ein, darf der Master nur annehmen, das kein Slave mit dieser Adresse angeschlossen ist, oder dass das Slave nicht bereit war. Auf jeden Fall ist es erforderlich die Kommunikation mit einer [stop-]start-condition + Addressbits neu zu starten. Der timeout ist an dieser Stelle meiner Ansicht nach total überflüssig.

Ein timeout ist natürlich sinnvoll, wenn z.B. das Slave fehlerhaft ist und die SCL dauerhaft auf low zieht.

Den user-timeout finde ich gut, aber geht etwas an dem vorbei was ich brauche. Das Slave darf ja ruhig länger brauchen. In diesem Fall muss es halt den clock stretchen. Hier würde ein zu kurz gewählter timeout die ansonsten fehlerfreie Kommunikation zu Nichte machen.

Wie auch immer, ich werde in meinem Fall wohl anders vorgehen müssen. Verstehen Sie meine Meinung bitte nur als konstruktive Kritik.

Gruß

Thomas