Hallo zusammen, ich verzweifele langsam an der I2C-Schnittstelle. Ich habe 2 Mikrcontroller die sich über die I2C-Funktion unterhalten (1xMaster und der andere Slave) Ich habe die Slave Lib von Manni genommen und habe mir sehr viel dazu angelesen. Lesen und Schreiben geht, aber nur einzelnt und nicht über ein Repeatet Start miteinander verbunden. Habe dann noch ecplizit den Status des TWI Status Register überprüft per Software überprüft, um da drauf zu reagieren, doch der setzt nie diesen bestimmten Status. Ich weiß einfach nicht warum?! Hab natürlich ein Oszi rangeschlossen und sehe auch die RS-Bedingung. Auch wenn ich über den MKII debugge, dann erkennt das TWI Status Register nicht den Zustand Repeatet Start. Es setzt den Status "Nothing to Do - Everything ist fine" und scheint anscheinend die Clock dauerhaft herunterzuziehen. Jetzt könnte man denken, dass was an meiner Master Lib nicht stimmt, doch wenn ich da nen I2C Eeprom ranhaue, dann kann ich ohne Probs mit Repeatet Start kommunizieren. Kennt ihr einen funktionierenden SourceCode, wo ihr wisst, dass hier die Repeatet Start Kommunikation klappt? Wenn man sich die Application Note von Atmel herunterlädt, dann ist das dort ja eher durch einen dürftigen Workaround gelöst, indem das erste Byte was gesendet wird dem Controller Lesen oder Schreiben sagt..... Beispiel: Sende einfach als erstes zum Beispiel eine 3 und dann weiß der Slave-Controller dass ich nachdem ich alle xx Daten bekomme habe, antworten soll. Bei 1 will der Master nur schreiben und bei 2 nur lesen..... Nen nicht schöner Workaround wie ich finde - da das ja eigentlich I2C abnimmt. PS: Der Source-Code zu dem Thema von RN-Wissen zeigt übrigens das gleiche Verhalten wie Mannis.... :-( Vielen Dank wenn ihr euch mit der doch schon recht tiefen Frage beschäftigt. Schöne Grüße Maik
Hallo Maik, ich hab auch schon ne Menge mit AVR's und I2C gemacht und habe viele Anwendungen wo mehrere AVR's Daten ueber I2C austauschen. Ich habe auch am Anfang mit den libs rumprobiert die im Netz zu finden sind, aber irgendwie hat da immer was gefehlt um eine Multi Master/Slave com aufzubauen. Ich bin mir nicht sicher ob ich auch mit dem Repeatet Start Problem rumgefieselt habe, es waren so viele Dinge bis es dann endlich lief wie ich es wollte. Ich habe in allem was ich zum I2C gelesen habe (bei allen Herstellern) immer gesehen das Repeatet Start nur dazu genommen wurde um eine Fehlerhafte com erneut anzufragen. Also bei einem Arbitration lost, Timeout etc. Jetzt mache ich es so wie alle I2C IC's, einer hat einen Puffer und der andere liest/schreibt diesen Puffer nachdem er mitgeteilt hat wo er anfangen moechte. Das ganze laeuft Multi Master/Slave Ju
Juergen G. schrieb: > Jetzt mache ich es so wie alle I2C IC's, einer hat einen Puffer und der > andere liest/schreibt diesen Puffer nachdem er mitgeteilt hat wo er > anfangen moechte. > Das ganze laeuft Multi Master/Slave Moin!, das finde ich gut einen Leidensgenossen zu haben :-) Das wollte ich auch am Anfang machen, doch finde ich es wichtig, dass der Bus nicht nach einem Write nicht wiedeer freigegeben wird. Da wenn ich z.B. 3 Avr's habe und 2 gleichzeitig was haben wollen, die nicht die sich gegenseitig die Buffer raisen... :-( Ich denke, dass ich das wie in der Application-Note mache, auch wenn das extrem hässlich ist :-( Danke für deine Antwort Liebe Grüße Maik
Maik schrieb: > z.B. 3 Avr's habe und 2 gleichzeitig was haben wollen, die nicht die > sich gegenseitig die Buffer raisen... :-( Das wird in der Praxis nicht so heiss gegessen wie's gekocht wird. Ich habe ein System in dem 18 uC's permanent grosse Anzahl an Daten austauschen. Jeder uC will mal irgendetwas von einem anderen, zusaetzlich sind noch ein paar I2C Sensoren im selben Bus. Beim beobachten des Bus sieht man, das da kaum Luecken sind. Doch ausser ein paar Arbitration Lost hab ich keinerlei Fehler auf dem Bus. Ich habe nicht ausgerechnet wie hoch die mathematische Warscheinlichkeit ist, das ein anderer Master eine Com in genau dem Moment startet wenn eine "Conversation" zwischen dem schreiben des "Speicher Bytes" und der Start Condition zum lesen ist. Bei meinen Programmen sind da in der Regel max. 6 in der Regel 2 MCU Cycles dazwischen. Ich merke mir auch von welchem Master das "Speicher Byte" gesetzt wurde. Wenn jetzt nach dem Setzen des "Speicher Bytes" ein anderer Master daherkommt und das "Speicher Byte" "umsetzt" und danach der erste Master wieder kommt um den Inhalt von der von "Ihm" gesetzten Speicheradresse zu lesen, bekommt er ein NACK und verwirft die Conversation. Meine State Machine laesst ein Kontinuierliches schreiben zu, das heist will ein Master nur schreiben, dann ist das erste Byte was kommt die Speicheradresse ab der geschrieben werden soll und die darauf folgenden Bytes die Daten die geschrieben werden. Geschrieben wird Ringweise ohne Ueberpruefung. Der Master ist verantwortlich dafuer was er dem Slave gibt. Damit kommt eine Unterbrechung der Com nur zustande wenn erst die Speicheradresse geschrieben und dann gelesen werden soll. Ju
Juergen G. schrieb: > Ich bin mir nicht sicher ob ich auch mit dem Repeatet Start Problem > rumgefieselt habe, es waren so viele Dinge bis es dann endlich lief wie > ich es wollte. Also in der Peter-Fleury-I²C-Lib ist die restart-Funktion (i2c_rep_start) nichts anderes als eine leere Funktion, die die start-Funktion (i2c_start) aufruft. P.S.: Was ist die I2C-Lib von Manni und wo findet man die?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.