Hallo zusammen. Kurz zu mir: bin neu hier im Forum und grad dabei, ein altes Hobby wieder aufleben zu lassen. Aktuell macht mir ein TWI/I2C Interface Kopfschmerzen. An sich sollte alles ganz einach sein: Beispielcode aus der AppNote AVR312 (TWI-Slave mit USI) auf einen Tiny2313, Beispielcode aus der AppNote AVR315 auf einem Mega8, beide in ein Breadboard, zwei Drähte und zwei Pullups (2k2) und schon kann es losgehen. Für die ersten Versuche natürlcih erstmal kleine Testroutinen: Auf dem Mega8 sendet eine Endlosschleife immer dieselben 1, 2, 4 oder 8 Bytes. Der Slave gibt jedes Byte einfach in Hex auf einem LCDisplay aus. Für die Experimente habe ich die Schleifen immer mal modifiziert, Wartezeiten nach jedem String, Wartezeiten nach jedem Byte etc. eingebaut. Aber der Bus hängt immer wieder. Soweit ich das beurteilen kann, hängt sich der Master auf und sendet einfach nicht weiter. Bei so einem Hänger beobachte ich, dass die SDA auf low-Pegel stehen bleibt. Aber wie sollte das bei der Hardware-TWI sein können? Leider habe ich kein DSO, das lang genug aufzeichnen kann und mir das Ende der Kommunikation speichert (nur ein Vellemann APS230). Hobby-Equipment halt. Auch das Absenken des Bustakt bis TWBR=0xFF (kein Prescaler) ändert nichts an dem Problem. Für weitere Tests habe ich für den Master dann die Procyon AVR Lib benutzt und mit den non-Interrupt Senderoutine meine Daten gesendet. Hier tritt dasselbe Problem auf, allerdings sendet dieser Master bei 100kHz Takt single-Byte Übertragungen sehr zuverlässig. Aber schon bei 8-Zeichen Strings bleibt das Ganze immer wieder stehen. Was mache ich hier falsch? hat jemand sowas schon mal erlebt? Ich habe in der Codesammlung und in den Foren irgendwie nichts zu i2c in C gefunden (wieso eigentlich?). Macht denn nciht so ziemlich jeder i2c? mercie bein für jeden Tip. Hartmut "hase" Semken
Noch eine Ergänzung. Ich denke, das Problem sind fehlende ACKs vom Slave. der USI-Slave scheint nicht so zu funktionieren, wie man sich das vorstellet, und da bleiben dann ACKs hie und da aus. Wenn der Slave die Adresse NACKed, dann erkennt der Master einen Error, das Programm läuft aber weiter. Wieso bleibt das Programm aber stehen, wenn bei den Daten mit ACK/NACK was schiefgeht? merci hase
Und noch eine Ergänzung. Nimmt man zwei Mega8 mit ihrem slew-rate-limited Hardware-TWI, dann gehts. Klar eigentlich. Aber warum geht es mit der USI des T2313 nicht? hase
> Aber wie sollte das bei der Hardware-TWI sein können?
Bei USI führt eine verzögerte Reaktion des Slaves zu einer Verlängerung
vom I2C-Bitzyklus, indem der Slave SCL auf GND legt (2 Varianten: nur
beim Startbit oder auch zwischen den Bytes). Hintergund ist, dem Slave
etwas Luft für seinen Interrupt-Reaktion zu lassen - immerhin ist die
durchaus kritisch.
Wenn der Slave natürlich garnichts mehr tut, wird genau dieses
Clock-Stretching die SCL-Leitung permanent festnageln.
daran hatte ich auch gedacht. Allerdings habe ich im Oszillogramm keine clock-stretches erkennen können - vielleicht ist genau das der Fehler? In dem Fall sollte also das Low auf SCL aus dem T2313-Slave kommen, ergo also verschwinden, wenn man den vom Bus abtrennt. das sah bei meinen letzten Versuchen allerdings nicht so aus, hier schien mir das beim Hängen verbleibende Low aus dem Master zu stammen: wenn ich den Slave abgetrnnt habe, mass ich noch immer low. Vielen Dank erstmal für Deinen Code, ich probiere es mal damit - und bleibe vorläufig mein Mega8-only, damit das Projekt endlcih mal fertich wird :-) merci bien hase
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.