Soo schwer ist I2C nicht. Ich benutze dazu keine Libraries, die "paar" Zeilen mach ich selber (dann sind auch Fehler im Code meine eigenen).Zitat von oberallgeier
Ich versuch mal eine Erklärung:
Für jedes Byte werden 9 Bit übertragen. Wenn der Master schreibt, schickt er die ersten 8 Bit (die Daten) und der Slave quitiert beim 9. Takt mit ACK, bzw. quitiert nicht also NAK.
Wenn der Master liest, taktet er 8 Bit ein (der Master gibt immer den Takt vor) und liefert mit dem 9. Takt entweder ACK oder NAK.
Dann kann der Master auf dem Bus noch eine Startkondition oder eine Stopkondition anlegen. Das sind feste Zustände. Und als letztes: treibt der Master den Bus nicht und sind SCL und SDA high, ist der Bus idle.
Die passenden Timingdiagramme gibt es zuhauf in den diversen Datenblättern von I2C Chips oder hier. Das ist eigentlich schon alles über den Datentransfer auf dem I2C Bus.
Und jetzt zu dem Ablauf von oben:
Busy Test geht so:
1. Start senden
Eigentlich sollte man zuerst prüfen, ob der Bus idle ist, also SDA und SCL == 1. Wenn ja, eine Startkondition erzeugen. Ist häufig einfach ein Bit im Controler setzen.
2. Adresse + W senden
Das erste Byte nach dem Start muß das Adressbyte sein, oberste 7 Bit die I2C-Adresse des Slave, unterste Bit das R/W bit. Das wird typisch ins Datenregister des Chips geschrieben, der erzeugt dann die erforderlichen 9 Takte und liefert das ACK bzw. NAK in einem Bit zurück. Bei einem NAK muß die Übertragung mit Stop abgebrochen werden
3. ACK lesen
4. if ACK gehe zu 7.
5. Stop senden
Das ist hier passiert
6. gehe zu 1.
Slave not ready, weiter probieren. Es könnte aber auch bedeuten, Slave garnicht da, hat sich ausgelötet, Adresse ist falsch etc
7. Stop senden
Das müßte man nicht machen, der Slave ist da und bereit, man könnte jetzt die Registeradresse schreiben und dann erst Stop anlegen.
Ein "I2C read" ist hier nicht vorgekommen, daher halte ich die Verwendung einer Funktion mit "read" im Namen für falsch (ich kenne die Library nicht). Ich vermute aber mal so ins Blaue: die Funktion i2c_start() liefert als Returnwert den Status des ACK-Bits.
Ich hoffe, das hilft etwas weiter.
@Sternthaler
Ein "Dauerfeuer" wie du es nennst, ist selbstverständlich erlaubt. Man muß sich nur an die Setup und Holdzeiten der Chips halten und das sind ganz wenige µs eher Nanosekunden. So schnell kann dein Programm garnicht laufen. Und Chips, die eine lange Leitung haben, quitieren nicht (was dann ein NAK ist) solange sie nicht fertig sind.In deiner while(1)-Schleife ist KEIN wait enthalten.
In dem Beispiel ist ein 'Wait' mit Bascom als "Waitms 1" angegeben.
Ich bin nicht sicher, aber ein "Dauerfeuer" auf dem Bus ist nicht erlaubt.
MfG Klebwax
Zitieren
Lesezeichen