Hi zusammen, vorne Weg erstmal ein paar Infos. Ich will eine I2C Verbindung zwischen einem Atmega 168 (Arduino NG Board) und drei Attiny 25 herstellen. Für den Master benutze ich die Wire Library von Arduino und beim Attiny Slave verwende ich den Quellcode des Appnotes 312 von AVR (siehe Anhang). Eingestellt ist eine Bus-Frequenz von 400kHz. Die Kommunikation funktioniert auch grundlegend d.h. ich kann Daten senden und empfangen. Das Problem ist allerdings das sich der Master nach einiger Zeit bei der STOP Condition (in der Wire Library ist das die Funktion Wire.endTransmission()) aufhängt. Meine Frage ist es möglich das der Slave den Master nicht mehr an den Bus "ranlässt"? Oder liegt es eher am Master? Was ich schon versucht habe ist folgendes: - Bus Frequenz auf 100kHz runtersetzen - Delay von 500ms nach jedem Wire.endTransmission() eingebaut - Rückantworten von den Slaves ausgeschaltet - Andere Bibliotheken für den Master benutzt z.B. die von Peter Fleury. (Mit dieser konnte ich allerdings garnichts senden, hing schon bei der START Condidition) - Die beiden while Schleifen in der Funktion twi_writeTo(..) entfernt, leider auch ohne Erfolg - externe Pullup Widerstände benutzt - und sonst noch eher kuriose, sinnlose Versuche (wie garnicht die endTransmission() Funktion ausführen usw. ;) Kann es vielleicht daran liegen das die I2C-Nachrichten schnell hintereinander an die Slaves gesendet werden? (bei mir werden jedem Slave schnell hintereinander ca. fünf I2C Nachrichten von je einen Byte gesendet) Langsam bin ich mit meinen Latein am Ende. Hier würde echt ein Oszilloskop helfen. Leider hab ich kein zur Verfügung, somit kann ich euch kein Timing Diagramm anbieten. :( Gruss, Werner
Jeder Slave darf bei I2C die Clockleitung auf GND ziehen wenn er mit der Verarbeitung nicht hinterher kommt. Sollte er dabei in einer endlos schleife hängen bleiben ist dein Bus Tod. Bei 3 Slaves dürfte es schwierig werden den schuldigen zu finden... Bau an den Slaves doch mal Leds dran die du bei Start ein und bei Stop ausschaltest. Warum schickst du nicht 1x 5 byte? Und warum 400Khz? Kabellänge? Du solltest dir einen I2C-Sniffer zulegen.
Hallo, ein Hochohmiger (kein Vcc, Pins nicht konfiguriert, Reset) Slave kann den I2C lahmlegen. Wie Tim schrieb sieht es für den Master dann nach clock stretching aus.
@Tim Axo jeder Slave hat den selben Quellcode (nur mit andere Slave Adresse natürlich) also wenn einer falsch läuft laufen alle falsch ;) Bei den Slaves laufen auch Watchdog Timer (auf 60ms eingestellt) also wenn die Slaves sich aufängen würden, was sie nicht tuen, würde ich das merken. Was ich natürlich schlecht sehe ist ob sie die Leitungen ständig runterziehen, da werde ich das mal mit den LEDs ausprobieren. Ich schicken die 5Bytes einzeln da es verschiedene Kommandos sind die aber woanders generiert werden d.h. es können auch 2-4 sein, sonst müsste ich alles Zwischenspeichern was schlecht wäre. 400kHz hab ich nur so genommen wie gesagt hab auch schon mit 100kHz versucht. Die gesamte Kabellänge beträgt ca. 30cm. Ja ein I2C Sniffer wäre nicht schlecht. @Gast kein VCC oder Pins falsch konfiguriert oder ein Reset am Slave schliesse ich aus da es ja eine Zeit lang funktioniert, sonst dürfte es ja garnicht funktionieren oder? Hmm.. aber clock streching hört sich verdächtig an. Kann also sein das der Slave die SCL Leitung ständig auf 0 runterzieht und diesen wieder nicht freigibt? Muss ich mir morgen mal genauer anschauen, aufjedenfall schonmal Danke für die Tipps. Gruss, Werner
> Bei den Slaves laufen auch Watchdog Timer (auf 60ms eingestellt) also > wenn die Slaves sich aufängen würden, was sie nicht tuen, würde ich das > merken. Muss sich ja nicht aufhängen, es reicht ja wenn die state maschine des Slaves aus dem tritt kommt. >400kHz hab ich nur so genommen wie gesagt hab auch schon mit 100kHz >versucht. Ok, kommt auf die Anwendung drauf an. Ich fahr hier mit 20Khz. Ich weiss nicht wo die grenze beim USI liegt, das verwende ich nicht mehr. >Die gesamte Kabellänge beträgt ca. 30cm. Das sollte gehen. > Ja ein I2C Sniffer wäre nicht schlecht. Hier im Forum gibt es einige. >Hmm.. aber clock streching hört sich verdächtig an. Kann also sein das >der Slave die SCL Leitung ständig auf 0 runterzieht und diesen wieder >nicht freigibt? clock streching ist ja teil des I2C Protokolls, damit ein schneller Master mit einem langsamen Slave reden kann. Wenn der Slave dabei einen hänger hat und clock nicht wieder freigibt wartet der master bis zum nächsten Reset durch den Anwender..... Ein Timeout im Slave und Master hilft.
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.