-
-
Neuer Benutzer
Öfters hier
Problem mit dem I2C-BUS Protokoll
Moin moin,
vielleicht kann mir jemand zu diesem Thema weiter helfen???
Im Moment habe ich ein RS232 zu I2C-Bus Interface an meiner COM1 sitzen, eine kleine Schaltung mit dem I/O-Expander PCF8574P ist an dieses Interface angeschlossen. Dazu habe ich ein kleines Programm in Delphi geschrieben.
Soweit funktioniert ja alles, ich kann die SDA- bzw. SCL-Leitung auf High bzw. auf low setzen sowie die Leitungen abfragen.
Beim PCF8574 habe ich die A0 - A2 auf GND gesetzt -> also auf "0".
somit ist die Adresse für den PCF8574 (dez)64 wenn ich auf diesem schreiben möchte.
Und so sieht mein Protokoll aus (welches laut Philips im Datenblatt des PCF8574 drin steht)
Init -> SDA und SCL auf "1"(= High)
Start -> SDA auf 0 -> 5µs warten -> SCL auf 0
Adresse dez.64 = 40h wird übermittelt
Takt 01 SCL high -> SCL low
Takt 02 SDA high -> SCL high -> SCL low -> SDA low
Takt 03 SCL high -> SCL low
Takt 04 SCL high -> SCL low
Takt 05 SCL high -> SCL low
Takt 06 SCL high -> SCL low
Takt 07 SCL high -> SCL low
Takt 08 SCL high -> SCL low -> achte Bite wurde übertragen
Takt 09 SCL high -> SCL low -> Acknowledge vom PCF8574
Information an den Slave PCF8574 wird übermittelt - alle Ports auf High
Takt 10 SDA high -> SCL high -> SCL low
Takt 11 SCL high -> SCL low
Takt 12 SCL high -> SCL low
Takt 13 SCL high -> SCL low
Takt 14 SCL high -> SCL low
Takt 15 SCL high -> SCL low
Takt 16 SCL high -> SCL low
Takt 17 SCL high -> SCL low -> achte Bite wurde übermittelt
und mit der low-Flanke vom SCL kommt ein Acknowledge vom Slave zurück -> SDA wird low
Takt 18 SCL high -> SCL low -> Acknowledge wird angenommen
jedoch passiert hier das komische Verhalten, welches ich nicht verstehe.
wenn beim Takt 18 die Taktflanke auf High geht leuchten alle LED's am I/0 Expander - ein Zeichen das dieser die übertragenen Informationen "gefressen" hat. Bei der fallenden Flanke SCL auf low gehen dann die "Lichter" (Led's) aus.
Bei dem Takt 18 muss ich aber SCL auf low bringen weil der PCF8574 den SDA auf low (wegen dem ACK) hält und ich erst danach mit der Stopp-Prozedur beginnen kann.
Nun die Frage an euch: Hat jemand soetwas auch schon mal erlebt oder habe ich einen denkfelher im Protokoll???
Danke schon eimal im voraus.
-
Erfahrener Benutzer
Roboter-Spezialist
Hallo,
ich habe mal meinen Code eingesehen.
Ein Vermerk: SDA Change nur bei SCL = 0 erlaubt.
Ich setze zuerst SCL auf 0.
Dann setze ich SDA. (Bit 0)
Und dann setze ich SCL auf 1 und danach auf 0.
Dann setze ich SDA. (Bit 1)
Und dann setze ich SCL auf 1 und danach auf 0.
....
Zuschluss setze ich SDA = 1 und SCL = 1 und warte den Acknowledge ab.
Die Lichter dürfen nicht aufleuchten und danach wieder verlöschen. Der Status muss bleiben.
Gruss Klaus.
-
Neuer Benutzer
Öfters hier
Hallo Klaus,
setzt du schon vor dem Acknowledge die Stop-Bedingung?
Übrigens habe ich den Fehler gefunden ... jaja, man höre und staune
Wenn die Informationen übermittelt werden und der Slave dem Master sein Ack aufdrückt beginnt dieser seine Ausgänge zu boosten -> LED's leuchten schon hell.
Nach dem Ack wird der Strom auf "normal" reduziert - schließ man noch eine Treiberstufe (transistor o.s.ä.) an die Ausgänge an, so leuchten auch die LED's wieder - ***Freu****
Mein Protokoll sieht nun so aus:
...
Informationen werden übermittelt
Acknowledge wird abgefragt
Beide Leitungen liegen auf 0
und zum Schluss wird die Stop-Bedingung eingeleitet - und fertsch!!
Einen schönen Tag noch
Peter
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- Anhänge hochladen: Nein
- Beiträge bearbeiten: Nein
-
Foren-Regeln
Lesezeichen