INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.

Antwort schreiben 
 
Themabewertung:
  • 0 Bewertungen - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
TWI Kommunikation überprüfen
29.11.2015, 18:09
Beitrag #9
RE: TWI Kommunikation überprüfen
Moin,

ohne in den Code zu gucken:
Zitat:Die KOmmunikation bricht nur in dem Fall ab, das der Anwender einen Slave im laufenden Betrieb entfernt oder ein defekt vorliegt.
Das er auf eine Antwort wartet könnte ein Problem sein. Da muss ich nochmal den Quellcode nachbesern.
Ein weiteren Problem was auftritt, wenn ich den Master vom PC entferne (COM PORT) dann erkennt er danach keinen Slaves mehr, erst wenn ich alle Slaves zurück setzte und anschließend den Master erkennt er sie wieder.
Die Slave Erkennung habe ich in der void Setup durchgeführt: Von daher sollte ja zumindest ein Master reset ausreuchen oder irre ich da?
Dieses Verhalten entspricht eigentlich genau der Protokollbeschreibung von hier:
https://de.wikipedia.org/wiki/I%C2%B2C
Zitat:Eine Dateneinheit besteht aus 8 Datenbits = 1 Oktett ... und einem ACK-Bit. Dieses Bestätigungsbit (Acknowledge) wird vom Slave durch einen Low-Pegel auf der Datenleitung während der neunten Takt-High-Phase (welche nach wie vor vom Master generiert wird) und als NACK durch einen High-Pegel signalisiert. Der Slave muss den Low-Pegel an der Datenleitung anlegen, bevor SCL auf high geht, andernfalls lesen weitere eventuelle Teilnehmer ein Start-Signal.
...
Ein großes Problem innerhalb der I²C Spezifikation ist das Fehlen eines Timeouts, was gelegentlich zu blockierten Chips führen kann. Falls ein Slave-Chip gerade die Datenleitung auf 0 drückt und ein Reset den Master zurücksetzt, bleibt diese Datenleitung für unbestimmte Zeit auf 0. Somit bleibt der gesamte I²C Bus mit allen angeschlossenen Chips blockiert. Sofern der Slave-Chip keinen eigenen Reset hat, lässt sich die Blockade nur durch "manuelles" Generieren von Taktimpulsen bzw. Aus- und Wiedereinschalten der Stromversorgung lösen.
Also ziemlich sicher eher ein typisches Verhalten und kein Fehler (im Code).

Grüße Ricardo

Nüchtern betrachtet...ist besoffen besser Big Grin
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Möglicherweise verwandte Themen...
Thema: Verfasser Antworten: Ansichten: Letzter Beitrag
  Kommunikation über das WiFi-Shield Flap 3 230 07.11.2016 20:20
Letzter Beitrag: hotsystems
  Kommunikation Serial Monitor --> Arduino BennIY 7 352 24.05.2016 07:48
Letzter Beitrag: hotsystems
  USB-Kommunikation ADK hr3 0 278 12.04.2016 16:43
Letzter Beitrag: hr3
  I²C Kommunikation bricht ab chhec 1 344 19.01.2016 11:10
Letzter Beitrag: ardu_arne
  Zahlenformat bei Kommunikation mit zwei Arduinos Matthias_Arduino 5 632 07.01.2016 22:40
Letzter Beitrag: Bitklopfer
  Grundlagen zur UART Kommunikation gesucht... torsten_156 10 874 16.12.2015 22:26
Letzter Beitrag: Bitklopfer
  Serielle Kommunikation arduino147147 1 665 15.10.2015 08:22
Letzter Beitrag: Binatone
  Serielle Kommunikation zw. zwei Arduino UNOs Marduino_UNO 2 1.105 20.08.2015 07:13
Letzter Beitrag: Marduino_UNO
  Serielle Kommunikation neben Programmablauf "parallel" ausführen bits10 1 797 16.03.2015 22:32
Letzter Beitrag: Bitklopfer
  Serielle Kommunikation verschluckt Buchstaben bushi 0 513 17.02.2015 14:36
Letzter Beitrag: bushi

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste