Hallo, bin grad dabei, mich in den I2C-Bus einzuarbeiten. Hab da mal ne Frage, und zwar zur Stop-Condition. Wirkt die wie ein ein Reset auf dem Bus, wenn ich sie als erstes auf den Bus gebe? Ich möchte sicherstellen, dass ich den Bus komplett rücksetzen kann, falls irgendwas während der Kommunikation schieflief. Soweit ich das verstanden habe, bewirkt dies eine Stop-Condition, die zudem zu jedem beliebigen Zeitpunkt erfolgen darf, richtig? Thx Ralf
Das ist richtig. Eine Übliche Vorgehensweise ist beim Start und bei "Pannen" (Was auch immer) 2x Stop zu geben um jeglichen Ärger zu vermeiden.
Zusatz: Laut Definition reicht ein "Stop" aber es hat sich aus Erfahrung gezeigt das es manchmal nicht ganz ankommt bzw. einige Bausteine beim ersten "Stop" nach einem "Unfall" nicht komplett rücksetzen.
"... 2x Stop zu geben um jeglichen Ärger zu vermeiden." Wenn schon, dann aber mindestens 9* versuchen, Stop zu senden. Der Slave-Transmitter kann ja beim 1.Bit von einem 0x00-Byte hängen und dann hält er 8 Takte lang die SDA-Leitung auf low. Peter
Hi Peter, danke für den Hinweis, den werd ich im Auge behalten, ist gut zu wissen. Jetzt kommt mir aber doch noch eine Frage auf: Ich habe für jeden der vier möglichen Aktionen auf dem Bus eigene Routinen geschrieben. Also für START, STOP, READ und WRITE. 1. Wie sollte der Zustand der SCL- und SDA-Leitung nach jeder einzelnen dieser Aktionen sein? Auf keinen Fall beide 1, ausser nach einer Stop-Bedingung, oder? Sonst könnte ein weiterer Master ja auf die Idee kommen, dass der Bus frei ist, oder? 2. Ich möchte diese Routinen so einfach wie möglich halten, aber gibt es irgendwas, was ich auf alle Fälle beachten sollte? Z.B. werden in den aktuellen Routinen keinerlei Prüfungen auf den Bus-Zustand vorgenommen. 3. Ich kanns in der Spezifikation nicht finden, oder bin grad zu doof: Wann werden Datenbits übernommen? Soweit ich verstanden habe, bei fallender Flanke der SCL-Leitung, oder? Ralf
Ich habe meine SW-I2C-Funktionen (außer Stop) so geschrieben, daß SCL danach immer low ist. Dadurch lassen sich die Routinen gefahrlos kombinieren und es ist egal, wo SDA steht. Außer bei Stop, danach ist natürlich SDA und SCl = 1. Read und Write machen gleichzetig das ACK mit, d.h. Read bekommt übergeben, ob es mit einem ACK oder NACK enden soll und Write gibt zurück, ob es ein ACK oder NACK empfangen hat. http://home.tiscali.de/peterd/appl/hard/i2c/si2c_drv.inc http://home.tiscali.de/peterd/appl/hard/i2c/index.htm Peter
Danke, Peter. Werd mal gucken, ob ich es auch so hinbekomme mit dem ACK/NACK. Wie ist das mit der Datenübernahme? Bei fallender SCL-Flanke, oder? Ralf
Ich nehme an, den Zeitpunkt der Datenübernahme kann der Designer festlegen (solange SCL=High+Flanken), aber fallende Flanke scheint üblich zu sein. siehe: http://forums.semiconductors.philips.com/forums/viewtopic.php?p=9552#9552
Meine Erfahrung hat gezeigt, dass man den Error-Routinen etwas Aufmerksamkeit entgegenbringen sollte. Eine mögliche Error-Routine könnte so aussehen: TWI_ERROR: ; TWI STOP ldi r16, (1<<TWINT)|(1<<TWEN)|(1<<TWSTO) out TWCR, r16 ; TWI aus ldi r16, (0<<TWEN) out TWCR, r16 ; Initialisierung rcall TWI_INITIALISIERUNG ret
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.