SRF02. Wie ohne Timer Messwert-Abfrage steuern

[Klebwax]

@Klebwax

Tut mir leid, jetzt kommen eher Fragen

Und was passiert tatsächlich mit folgenden beiden C-Codezeilen?

Erzeuge STOP mit sofort folgendem START in der TWI-Hardware:

TWCR = (1<<TWSTO)|(1<<TWINT) | (1<<TWEN)|(1<<TWIE);
TWCR = (1<<TWSTA) |(1<<TWINT) | (1<<TWEN)|(1<<TWIE);


Der Compiler macht daraus:
4d6: 85 e9 ldi r24, 0x95 ; 149
4d8: 80 93 bc 00 sts 0x00BC, r24 <<== Register für TWI-Hardware im mega168 und anderen AVRs.

4dc: 85 ea ldi r24, 0xA5 ; 165
4de: 80 93 bc 00 sts 0x00BC, r24


Hier liegen wir garantiert unter den 1.3 us und nun stellen sich mir folgenden Fragen:
Was macht die Hardware tatsächlich, wenn sie STOP'en und sofort wieder START'en soll?
Wird dann der Softwareteil beim START'en verzögert? Kann ich mir beim besten Willen nicht vorstellen.
OK, nach dem START wird es etwas dauern, bis im TWSR das Bit TWINT wieder gesetzt wird. Klar, das macht die Hardware.

Wenn ich die TWI-Hardware benutze, dann sollte ich natürlich nicht dein angegebenes "... und im Code darauf gewartet wird. ..." dahingehend wörtlich nehmen, dass ich nun eine Schleife im Code bauen soll, die zwischen STOP und START prüft, "... das sich der Status ändert ..."?

Kannst du deine Erklärung genauer formulieren, bzw. mir eine Erklärung geben, die ich verstehe?


Da die TWI-Hardware, nach einem durch die Software angegebenem STOP-Kommando an das Register TWCR, sich nicht mehr per Interrupt meldet, da nämlich kein Status-Wert für diese Aktion definiert ist im TWSR-Register (ODER habe ich diese Info noch nicht gefunden!), kann ich somit den nächsten START-Aufruf tatsächlich nur ohne Interrupt-Kontrolle erzeugen.
Also auch im Extremfall wie oben angegeben.


Im Handbuch finde ich folgendes: (mega48 bis 328 )

Im Kapitel "Overview of the TWI Module" Unterpunkt "Bus Interface Unit":
"When in Transmitter mode, the value of the received (N)ACK bit can be determined by the value in the TWSR."
Also hier noch keine Angabe, was im TWSR nach einem STOP steht.

Im Kapitel "Using the TWI" ist das Bild "Interfacing the Application to the TWI in a Typical Transmission" angegeben, welches die Aktionen von Software und Hardware sehr schön im (typischen) Zusammenspiel zeigt.
Hinter dem STOP wird hier nichts mehr angegeben.
Hast du hier eine Info, ob, und wie, der STOP-Zustand auf dem BUS im TWSR 'zu sehen' ist?

Und das dazu wohl wichtigste Kapitel:
"Overview of the TWI Module" Unterpunkt "Control Unit" ist zu finden, wann das Bit TWINT im TWSR gesetzt wird um anzuzeigen, das die Hardware fertig ist.
• After the TWI has transmitted a START/REPEATED START condition.
• After the TWI has transmitted SLA+R/W.
• After the TWI has transmitted an address byte.
• After the TWI has lost arbitration.
• After the TWI has been addressed by own slave address or general call.
• After the TWI has received a data byte.
• After a STOP or REPEATED START has been received while still addressed as a Slave.
• When a bus error has occurred due to an illegal START or STOP condition.
Dort ist KEINE ANGABE vorhanden, das ein STOP das Bit setzt.
Aus meiner Sicht ist somit nicht zu prüfen, wann das STOP 'fertig' ist. --> Alles eben beim ATmega und nicht in einem PIC.


Gruß aus dem frühen neuen Tag
Sternthaler


Nachtrag:
Vielleicht doch ne' Lösung vorhanden?

In "Transmission Modes" Unterkapitel "Miscellaneous States" steht natürlich noch etwas zu diesem "illegal START or STOP condition"
Table 22-6. Miscellaneous States

0x00 Bus error due to an illegal START or STOP condition
No TWDR action 0 1 1 X
Only the internal hardware is affected, no STOP condition is sent on the bus. In all cases, the bus is released and TWSTO is cleared.

Wenn ich deinen Text richtig verstehe, willst du mir sagen, zwischen Stop und Start muß eine Delay gemacht werden, ich liege falsch wenn locker sage "das kann man gleich hintereinander machen". Das mag bei den AVRs wohl sein, glaub ich aber eher nicht.
Bei mir geht sofort eine große Warnleuchte an, wenn ich ein Delay im Code sehe. Ist dieselbe Leuchte, die angeht, wenn ein neues Gerät von Panzerband zusammengehalten wird.

muss man eigentlich warten bis das STO wieder zurück gesetzt wurde (siehe Tabelle in DS).

Das ist so ein gängiges Verfahren, ich kann aber nicht sagen, ob das hier klappt. In diesem Fall ist noch etwas anders, der TWI-Controler wartet mit einem Start, bis der Bus idle ist, und am Ende eines Stops wird der Bus idle.

Was aber sicher nicht geht ist

TWCR = (1<<TWSTO)|(1<<TWINT) | (1<<TWEN)|(1<<TWIE);
TWCR = (1<<TWSTA) |(1<<TWINT) | (1<<TWEN)|(1<<TWIE);

da wird in der zweiten Zeile TWISTO auf Null gesetzt, und in der Zeit ist ein Stop nicht erzeugt. Möglicherweise hat der TWI-Controler noch garnicht mitbekommen, daß TWISTO gesetzt war, er läuft ja nicht mit dem selben Takt, wie die CPU, sondern mit dem TWI-Clock oder einem vielfachen davon.

MfG Klebwax

[oberallgeier]

Vielleicht plage ich mich noch mit dem alten 20 MHz-DSO an die Sache, aber ich glaube, da bekomme ich vertrauenswürdige Ergebnisse zum Start/Stop- bzw. Stop-Start-Problem nur deutlich unter meinem aktuellen Bustakt (explizit nenne ich 500 kHz, TWBR ist dann 12). Übrigens nennt das Datenblatt 8272D–AVR–05/12 aus Seite 340:

tBUF    Bus free time between a STOP and    fSCL = 100kHz 4.7 –    µs
        START condition                     fSCL > 100kHz 1.3 –    µs

[oberallgeier]

@oberallgeier ... Du mußt den Returnwert von "i2c_start (Sadd + I2C_WRITE)" auswerten ...

Wie oben geschrieben, das geschieht normalerweise. Und jetzt ist (wieder mal) Anlass darüber nachzudenken. Grundlage ist ordnungsgemäßes Programmieren von sicherem und schnellen Code für eine Singel-Master-I²C-Übertragung.

MUSS ich - und wenn ja, WARUM, beim I²C-Master zu Beginn einer I²C-Übertragung den Returnwert auswerten? ICH (also mein Controller) sendet. Als Master. Da hat doch niemand den Bus lahmzulegen und ich müsste die früheren Aktionen ordnungsgemäß abgeschlossen haben. Ausnahme ist Mister Murphy-Law, der schon mal, wie sein Kollege Wackel-Kontakt und andere, dreinpfuschen kann. Aber normalerweise sollte doch der I²C-Bus zu Beginn der Übertragung nicht besetzt sein - ist ja kein Multimaster.

Beim anschließenden Schreiben oder Lesen wird/kann das sinnvoll sein. Aber auch da überlege ich noch.

Nicht dass es mir auf die paar zusätzlichen Maschinenbefehle für das "if" ankäme. Ich finde nur überflüssige Befehle sind ebenso unschönes Programmieren wie falsche.

[RoboHolIC]

MUSS ich - und wenn ja, WARUM, beim I²C-Master zu Beginn einer I²C-Übertragung den Returnwert auswerten? ICH (also mein Controller) sendet.

Weil dir eventuell seit dem letzten PowerUp ein EMP-Puls auf dem I2C-Bus den Slave aus dem Tritt gebracht hat und dieser Slave vielleicht keinen Reseteingang besitzt, über den du ihn programmtechnisch wieder zur Ordnung rufen könntest.
Du kannst die Abfrage auch weglassen und stattdessen den Controller regelmässig vorbeugend eine I2C-Zauberformel sprechen lassen. Das ist irgendwas wie "mindestens 8x einen H-L-Wechsel auf der Clockleitung, während die Datenleitung H-Pegel hat". Könnte in der Philips-Doku (bzw. NXP) über den I2C-Bus stehen, müsste ich aber erst suchen.

Konkretes Beispiel gefällig?
Mein aktuelles Projekt mit I2C-Bus hängt nach dem Flashen häufig.
Ein einziger Controller als Master und ein einziger Gesprächspartner, der nur Slavemodus kann; alles ganz elementar und minimal.
Mein eigener, ursprünglicher Ansatz, den Bus in einen geordneten Zustand zu bringen war, zu Beginn jedes Datenaustauschs das I2C-Modul des Controllers zu deaktivieren, wieder zu aktivieren und dann einen I2C-Startzustand auf den Bus zu bringen.
Nette Idee, hilft aber leider nicht. Ein PowerUp dagegen hilft immer. Vermutlich liegt das Problem darin begraben, dass das Flashen den Controller aus einer laufenden I2C-Kommunikation rausreisst, der Slave mangels Reset-Eingang aber in undefiniertem Zustand verharrt. Ich habe das noch nicht weiterverfolgt, weil ich bei der aktuellen Anwendung die Windows-Option habe: Power OFF , dann Power ON .

[Klebwax]

MUSS ich - und wenn ja, WARUM, beim I²C-Master zu Beginn einer I²C-Übertragung den Returnwert auswerten? ICH (also mein Controller) sendet. Als Master. Da hat doch niemand den Bus lahmzulegen und ich müsste die früheren Aktionen ordnungsgemäß abgeschlossen haben.

Der Beginn einer I2C-Übertragung ist das Herstellen einer Start-Kondition. Nun ist es aber so, daß die Funktion i2c_start() wesentlich mehr macht. Sie ist schon der erste Teil der Übertragung, denn sie sie sendet auch noch das Adressbyte. Daß man das in einer Funktion zusammengefaßt ist, hat der Programmierer dieser Funktion zu verantworten. Ich würde das nicht so machen, sondern daraus zwei Funktionen bauen, auch einer der Gründe das selbst zu machen.

Und jetzt zu dieser Funktion selbst. Als erstes setzt sie das TWISTA-Bit (sorry, wenn ich die Bitnamen mal etwas falsch schreibe, ich müßt sonst jedesmal nachschlagen). der TWI-Controler macht dann laut Datenblatt folgendes: er wartet, bis der Bus idle wird, und setzt dann Start. Da macht sogar schon die Hardware einen Check. Geht dabei etwas schief, meldet die Funktion i2c_start() einen Fehler. Dann sendet die Funktion die Adresse, wird sie nicht mit ACK quitiert, meldet die Funktion den gleichen Fehler (schlecht). Antwortet ein Slave nicht auf seine Adresse mit ACK, muß die Transaktion mit einem Stop abgebrochen werden!. Also muß der Returnwert ausgewertet werden. Dies erstmal zum Speziellen.

Ausnahme ist Mister Murphy-Law, der schon mal, wie sein Kollege Wackel-Kontakt und andere, dreinpfuschen kann. Aber normalerweise sollte doch der I²C-Bus zu Beginn der Übertragung nicht besetzt sein - ist ja kein Multimaster

Oder das Device ist Busy, das EEPROM schreibt gerade, ein US-Sensor misst, dein selbstgemachter Slave ist noch nicht hochgelaufen oder, oder ...

Beim anschließenden Schreiben oder Lesen wird/kann das sinnvoll sein. Aber auch da überlege ich noch.

Nicht dass es mir auf die paar zusätzlichen Maschinenbefehle für das "if" ankäme. Ich finde nur überflüssige Befehle sind ebenso unschönes Programmieren wie falsche.

Es ist also eher umgekehrt, beim Verbindungsauf ist es Pflicht. Aber, wenn ich bei einer Datenübertragung nun schon eine minimale Rückmeldung bekomme, sollte man sie auch verwenden. Das ist jetzt das Inhaltliche.

Prinzipiell gilt aber:
Errorcodes sind dazu da, ausgewertet zu werden! Ein Code, der das nicht macht, fällt durch jedes Audit. Und ja, es führt dazu daß Fehlerbehandlung manchmal den größten Teil des Codes ausmacht. Und eigentlich sollte eine Library wie z.B. die I2C Library, die von fremden Programmieren verwendet wird, jeden Übergabeparameter auf gültige Werte überprüfe, und im Fall ungültiger Werte mit einem Fehlercode zurückkehren. Schau dir mal einige Funktionen der libc oder andere professionelle Libraries an, da ist die Beschreibung der Errorcodes häufig länger als die Funtionsbeschreibung.

Weil dir eventuell seit dem letzten PowerUp ein EMP-Puls auf dem I2C-Bus den Slave aus dem Tritt gebracht hat und dieser Slave vielleicht keinen Reseteingang besitzt, über den du ihn programmtechnisch wieder zur Ordnung rufen könntest.
Du kannst die Abfrage auch weglassen und stattdessen den Controller regelmässig vorbeugend eine I2C-Zauberformel sprechen lassen. Das ist irgendwas wie "mindestens 8x einen H-L-Wechsel auf der Clockleitung, während die Datenleitung H-Pegel hat".

Das ist eher "unschlau". Dazu müßte man erstmal die I2C Hardware abschalten. Und dann dauert die Sequenz natürlich viel länger, als den Controler auf idle prüfen zu lassen, und einfach den Status auszulesen.
Und es ist mitnichten eine "Zauberformel" sondern leicht zu erklären. Wenn der Slave mit Read adressiert worden ist, wartet er auf 8 Clocks um Datenbits zu liefern und ein neuntes mit dem ACK. Führt der Host diese Sequenz nicht vollständig durch (Absturz, Reset o.ä.), hängt der Slave (es gibt kein Timeout bei I2C). Das Toggeln von SCL führt das zuende und das High auf SDA ist ein NAK. Das bricht dann die Übertragung ab.

Konkretes Beispiel gefällig?
Mein aktuelles Projekt mit I2C-Bus hängt nach dem Flashen häufig.
Ein einziger Controller als Master und ein einziger Gesprächspartner, der nur Slavemodus kann; alles ganz elementar und minimal.
Mein eigener, ursprünglicher Ansatz, den Bus in einen geordneten Zustand zu bringen war, zu Beginn jedes Datenaustauschs das I2C-Modul des Controllers zu deaktivieren, wieder zu aktivieren und dann einen I2C-Startzustand auf den Bus zu bringen.
Nette Idee, hilft aber leider nicht. Ein PowerUp dagegen hilft immer.

Das passiert nicht nur beim Flashen sondern auch beim Debuggen. Single Step oder Breakpoint, Register anschauen .. noch mal von vorne, Peng!
Und genau hier kommt die Resetsequenz ins Spiel. Wenn beim Init nach Reset der Bus nicht idle ist, schick die 8 Clocks. Ich mache das, bevor ich überhaupt die I2C Hardware anschmeiße. SDA und SCL als Input und auf High abfragen. Wenn nicht, SCL als Output und toggeln. Dann wieder Input. Wenn sie dann nicht high sind, Errorcode ausgeben und Halt (embedded Bluescreen).

MfG Klebwax

[oberallgeier]

Oh Leute, da komme ich vor lauter andächtigem Lesen garnicht nach mit dem Dazulernen! Bitte macht weiter, so kann man (kann ich) das I²C-Thema mal lernen ... und noch ein bisschen C dazu.

... Errorcodes sind dazu da, ausgewertet zu werden! ... Fehlerbehandlung manchmal den größten Teil des Codes ausmacht ...

Wie war das noch? Es kann nur die Anwesenheit, nicht aber die Abwesenheit von Fehlern sicher festgestellt werden. Und das schlägt auch hier mit voller Wucht zu. (Und hat seine Konsequenzen). Ansonsten muss ich sagen - können tu ich I²C noch nicht besser, aber ich lerne grad sehr viel dazu. Und in so einer tiefschürfenden Runde macht das Lernen viel mehr Spass als das Datenblatt so vor sich hinzulesen.

Klasse macht ihrs!

Sternthaler, danke für den Link zum 8271G; mein letztes ist das 8271E. Nun ist das Dutzend Datenblätter der 48-168-328-Familie voll.

[RoboHolIC]

Und es ist mitnichten eine "Zauberformel" sondern leicht zu erklären. Wenn der Slave mit Read adressiert worden ist, wartet er auf 8 Clocks um Datenbits zu liefern und ein neuntes mit dem ACK. Führt der Host diese Sequenz nicht vollständig durch (Absturz, Reset o.ä.), hängt der Slave (es gibt kein Timeout bei I2C). Das Toggeln von SCL führt das zuende und das High auf SDA ist ein NAK. Das bricht dann die Übertragung ab.

@klebwax
Wie unterscheidet man nach dem Controller-Reset einen Bus im Idle-Zustand (SCL und SDA, beide H) vom wartenden Slave, der gerade eine "1" übertragen will ?

Und was, wenn der Slave mit write adressiert wurde - macht das einen Unterschied?
Was, wenn die Adressierung mit bitgebangten Einsen erst eine gültige Adressierung bewirkt?
Was unterscheidet von Slave kommende Einsen von NAK (oder was es das ACK???) ?

Ich sehe einfach noch nicht die geschlossenen Lösung für den Bus-Reset: Müssen jetzt acht getaktete Einsen gesendet werden, oder maximal acht und nach jedem geprüft? Ich krieg das nicht zusammen. Ich habe mich halt bisher nicht in die I2C-Diagramme hineingedacht, weil es bei mir mit einem PIC16 auf der Ebene der Steuerbits und des IRQ-Flags schönwettermäßig recht bald funktionierte. Auch der neuerliche Erhellungsversuch mit RN-Wissen und dem relevanten Teil der Contollerdoku war erfolglos.

Kannst du das mit Fallunterscheidung mal wasserdicht darlegen - du scheinst I2C ja fundiert zu kennen. Das wäre super, auch im Sinne von oberallgeier's Anregung zum geballten I2C-Know How-Thread.

Gruß
RoboHolIC

[Klebwax]

@klebwax
Wie unterscheidet man nach dem Controller-Reset einen Bus im Idle-Zustand (SCL und SDA, beide H) vom wartenden Slave, der gerade eine "1" übertragen will ?

garnicht. Du bekommst dann später einen Fehler. Du müßtest das Problem dann bei der Reinitialisierung in deiner Fehlerbehandlung beseitigen. Am einfachsten ist, vor der Initialisierung generell die Clocks zu liefern.

Und was, wenn der Slave mit write adressiert wurde - macht das einen Unterschied?

Bei einem Write treibt nur der Master den Bus, nie der Slave. Der Slave kann also den Bus nicht blockieren.

Was, wenn die Adressierung mit bitgebangten Einsen erst eine gültige Adressierung bewirkt?

Der I2C Bus ist Open Collector, man kann keine 1 Senden. Und was hat "gültige Adressierung" mit "Bus ist nicht Idle" zu tun?

Was unterscheidet von Slave kommende Einsen von NAK (oder was es das ACK???) ?

Ein High auf dem Bus beim ersten bis achten Takt ist eine 1, beim neunten ist ein NAK.

Ich sehe einfach noch nicht die geschlossenen Lösung für den Bus-Reset: Müssen jetzt acht getaktete Einsen gesendet werden, oder maximal acht und nach jedem geprüft?

Wenn ich mich recht erinnere, steht "mindestens 8" in den I2C Spec. Und eigentlich kann man keine 1 Senden. Der I2C Bus ist Open Collector, man kann die Leitung nur loslassen. Wenn in der Spec 1 oder High steht, ist gemeint, daß der Master den Bus nicht treibt. Deswegen habe ich ja oben geschrieben: ich schalte vor der Initialisierung SDA auf Input (der Pin ist dann hochohmig und das ist dann equivalent zu einem nicht angesteuerten Transistor im Open Collector Triber), SCL auf Output, liefere die Clocks, schalte dann SCL auf Input und prüfe auf Bus Idle.

Ich krieg das nicht zusammen. Ich habe mich halt bisher nicht in die I2C-Diagramme hineingedacht

Das wäre aber zum Verständniss hilfreich. Ebenso die Lektüre der Spec, die NXP (vormals Philips) kostenfrei zur Verfügung stellt. Wenn man sich auf Single Master sowie Standard und Fast Mode beschränkt, gehört sie zu den einfachsten und kürzesten Protokollbeschreibungen, die ich kenne.

weil es bei mir mit einem PIC16 auf der Ebene der Steuerbits und des IRQ-Flags schönwettermäßig recht bald funktionierte

Da geht dann die Arbeit richtig los. Wie ich an anderer Stelle gesagt habe, kann der Schlechtwettercode viel länger sein.

- du scheinst I2C ja fundiert zu kennen.

Nun ja, in einem System mit zwei Open Colector Treiber können sich nicht viele Dinge verbergen, insbesondere wenn es so alt ist, daß die ersten Slaves mit Sicherheit reine Hardware waren, und die meisten heute noch sind.

MfG Klebwax