www.mikrocontroller.net

Forum: Compiler & IDEs I2C hängt bei Stop Condition


Autor: Werner (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Bascomfehler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.