SRF02. Wie ohne Timer Messwert-Abfrage steuern

[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

[RoboHolIC]

@ klebwax
Zunächst vielen Dank für deine ausführliche Antwort und deine Bemühung, mir Verständnis zu verschaffen. Leider blieb das große Achsoo noch aus, da hab ich noch weiter gesucht:

Zunächst habe ich ein Zitat aus der mir vorliegenden Philips-I2C-Spec.: ( Ver. 2.1, Jan. 2000 )

I2C-bus compatible devices must reset their bus logic
on receipt of a START or repeated START condition
such that they all anticipate the sending of a slave
address, even if these START conditions are not
positioned according to the proper format.

Das besagt ja, dass eine START Condition -auch zu Unzeit angewendet- eine Resetierung der Buslogik im konformen I2C-Slave bewirkt.

Über den Busreset habe ich dort mit dem Suchbegriff "reset" nichts Einschlägiges gefunden,
dafür aber bei Freescale folgendes:

The sequence for a Bus Reset is as follows:
• Disable the host MCU IIC controller
• Create a START condition
• Clock SCL for at least nine clocks
• Check for SDA high
• Create a STOP condition
• Enable the host MCU IIC controller

Dieser Vorschlag legt nahe, dass der Reset des Slaves auch beim STOP erfolgt.

Zusammengenommen verstehe ich einen möglichen zielgerichteten Resetvorgang daher so:
"Der Controller erzeugt bei nicht-getriebener (floating) SDA-Leitung wiederholt Clocksignale und prüft SDA, bis er den Zustand SDA = H vorfindet, der ihm erlaubt, ein START-Signal auf dem Bus durchzusetzen, das den Slave resettet, gefolgt von Dummy-Bit und abschliessendem STOP."
Möglicherweise genügt (s.o.) auch die STOP Condition alleine, sobald SDA = H.
Das Dummybit ist ggf. nötig, weil Die Abfolge START Condition - STOP Condition nicht erlaubt ist.

Trifft diese Formulierung den Punkt?

Ein paar Worde noch zu deiner ausführlichen Antwort:

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

OK, Denkfehler meinerseits.

Und was hat "gültige Adressierung" mit "Bus ist nicht Idle" zu tun?

Szenario: Controllerreset während der Chip- oder Registeradressierung. Ein Clearance-Versuch sieht SDA und SCL floating. Was tun? Busy oder nicht? Acht oder neun Clockpulse vervollständigen evtl. eine gültige Adressierung mit READ-Bit, die restlichen Clocks gehen für den Rest der Registeradresse drauf oder takten bereits die Antwort des Slave - genaues über den Zustand des Protokolls kann der Controller m.E. nicht aus SDA und SCL ablesen.
Beliebig viele weitere Clocks sind auch nicht statthaft, das kann kollidieren mit einer reservierten Sonderadresse (1111 1111).
Alles m.E. fragwürdig im Sinne der I2C-Spezifikation. Vielleicht liege ich auch voll daneben - das ist eben mein Rätselraten, jedenfalls nicht völlig abseits jeglicher Logik.

Nun ja, in einem System mit zwei Open Colector Treiber können sich nicht viele Dinge verbergen

Eines ist schon eines zuviel.

Gruß
RoboHolIC

[oberallgeier]

... vielen Dank für ... Antwort und deine Bemühung, mir Verständnis zu verschaffen. Leider blieb das große Achsoo noch aus ...

RoboHolIC mir gehts genauso. Ich gehe diesen Thread durch und Suche mir in meiner Datenblattsammlung die entsprechenden Passagen der Atmel-Application-docs, in Datenblättern, Wikis und so. Nachgucken, versuchen zu verstehen oder zu begreifen. Das bringt schon immer wieder so ein kleines "Aha!". Dann springt man - springe ich - auch mal in die THE I2C-BUS SPECIFICATION von Philips, VERSION 2.1 JANUARY 2000. Da gibts dann Dinge wie:

1.3 Version 2.1 - 2000
Version 2.1 of the I2C-bus specification includes the following minor modifications:
· After a repeated START condition in Hs-mode, it is possible to stretch the clock signal SCLH
 (see Section 13.2 and Figs 22, 25 and 32).

und anderes das ich nie wusste und "nie brauchte". Irgendwann ist dann der Kopf so voll, dass ich wieder im Wald stehe und von vorn anfangen muss. Dann leg ich das für den Tag beiseite. Aber manchmal komm ich doch ein Stück weiter.

Dumm, jede PWM hat AUCH ihre Register, ihre Wünsche und Vorschriften - und die hatte "man" ja schon früher einigermassen geschafft. Also wirds schon mal werden.

[Klebwax]

Irgendwie hab ich Probleme, ein Zitat im Zitat zu erzeugen, hier mein Versuch:

Zunächst habe ich ein Zitat aus der mir vorliegenden Philips-I2C-Spec.: ( Ver. 2.1, Jan. 2000 )

I2C-bus compatible devices must reset their bus logic
on receipt of a START or repeated START condition
such that they all anticipate the sending of a slave
address, even if these START conditions are not
positioned according to the proper format.

Das besagt ja, dass eine START Condition -auch zu Unzeit angewendet- eine Resetierung der Buslogik im konformen I2C-Slave bewirkt.

Über den Busreset habe ich dort mit dem Suchbegriff "reset" nichts Einschlägiges gefunden,
dafür aber bei Freescale folgendes:

The sequence for a Bus Reset is as follows:
• Disable the host MCU IIC controller
• Create a START condition
• Clock SCL for at least nine clocks
• Check for SDA high
• Create a STOP condition
• Enable the host MCU IIC controller

Dieser Vorschlag legt nahe, dass der Reset des Slaves auch beim STOP erfolgt.

Hier wird mehrfach das erzeugen einer Start/Stop condition genannt. Das Problem dabei ist, daß das nicht geht, wenn der Slave SDA auf low hält. Ansonsten klingt der Freescale Vorschlag bekannt. Ich bild mir aber ein, ähnliches auch bei NXP gesehen zu haben.

Nach meiner praktischen Erfahrung gibt es zwei Probleme, die sich mit den gängigen I2C Funktionen (start(), stop(), write(), readACK(),readNAK() ) nicht leicht auflösen lassen:

• Lesen von einem Slave, der das Lesen von mehreren Bytes zulässt, ohne das letzte Byte mit einem NAK (sondern einem ACK) zu quitieren
• Abbruch eines READ durch einen Reset/Debugger/Absturz/... im Master

In beiden Fällen gewinnt der Slave die Kontrolle über SDA und der Master kann, wenn SDA low ist, weder Start noch Stop erzeugen.

 

Deswegen ist

• Create a START condition

etwas fragwürdig. Bisher bin ich mit der Strategie: SDA freigeben, SCL 8 mal takten gut gefahren. Bevor es dann richtig losgeht, kommt pflichtgemäß sowieso ein Start.

Beliebig viele weitere Clocks sind auch nicht statthaft, das kann kollidieren mit einer reservierten Sonderadresse (1111 1111).

Reserviert heißt ja nicht, daß die Adresse nicht auf dem Bus sein darf. Es heißt ja nur, daß kein Slave sie verwenden darf. Und es wird sich daher auch keiner angesprochen fühlen, das passt doch. Es sei denn, du hast eines dieser "Reserved for future purposes" Devices am Bus. Es geht ja hier nicht um einen gültigen I2C Datentransfer sondern um das Auflösen einer Fehlersituation ohne Poweronreset.

Eines ist schon eines zuviel.

Das wirst du nie vermeiden können. Es gibt sicher einige tausend I2C Devices, und daher ebensoviele oder mehr Entwickler, die die Spec für sich interpretiert haben.

Ich gehe diesen Thread durch und Suche mir in meiner Datenblattsammlung die entsprechenden Passagen der Atmel-Application-docs, in Datenblättern, Wikis und so. Nachgucken, versuchen zu verstehen oder zu begreifen. Das bringt schon immer wieder so ein kleines "Aha!". Dann springt man - springe ich - auch mal in die THE I2C-BUS SPECIFICATION von Philips, VERSION 2.1 JANUARY 2000. Da gibts dann Dinge wie:
[CODE]Code:
1.3 Version 2.1 - 2000
Version 2.1 of the I2C-bus specification includes the following minor modifications:
· After a repeated START condition in Hs-mode, it is possible to stretch the clock signal SCLH
(see Section 13.2 and Figs 22, 25 and 32).[/CODE)

@oberallgeier
Das wird aus zwei Gründen keine wirkliche Bedeutung haben: Hs-mode wird nicht vorkommen, und die Änderung ist "minor".

Aber zusätzlich zum Lesen hilft (nicht nur hier) manchmal: Machen und Messen. Ich hab mal I2C in SW gemacht, ging zuerst garnicht. Dann in fremder SW geschmökert und neu gemacht. Und dabei erkannt, worauf es ankommt. Wenn man dann die Spec noch mal liest, versteht man sie besser. Heute mit den billigen DSOs oder LAs und den eingebauten Protokolldekodern geht das noch leichter.

MfG Klebwax

[RoboHolIC]

Nachtrag:

Ich habe jetzt endlich meine eigene Variante des I2C-Busresets
(SCL-Flanken fallend + steigend per TriState-Register samt Wartezeit; das Ganze so oft, bis SDA high ist)
angewendet und sie funktioniert mit einem Drucksensor MPL3115A2 von Freescale als einzigem Slave am PIC16F886.
Der I2C-Bus ist auch nach zig Warmstarts bis jetzt nie blockiert geblieben.