Salute,
neulich meldete ich bereits einmal auf der Suche nach Einbindung von I2C-Sensoren in einen CAN-Bot. Nun ist dies direkt per I2C aus der seriellen Schnittstelle (sh Linuxfocus-Artikel LF365[1]) geschen und klappt zumindest fuer einfache Kommunikation mit einem PCF8574 ganz wonderbra.
Versuche ich nun jedoch, einen SRF02 anzusprechen, so ACKt der brav alle Befehle, scheint auch das Leseregister zu wechseln und Daten an mich zu uebertragen. Soweit das Positive - leider sind die uebertragenen Daten falsch, und die Befehle werden nicht ausgefuehrt.
Im Folgenden ein kurzes Kommunkationsprotokoll:
Code:
Firmwarepruefung -> [(<id 224 / read 0> reg 0)<id 224 / read 1> wait: 4 ok]
(<id 224 / read 0> reg 0)
<id 224 / read 1> pruefe - done.
I2C -> SRF02 test using firmware 4
Funktionstest -> [(<id 224 / read 0> reg 0)<id 224 / read 1> wait: 4 ok]
(<id 224 / read 0> reg 1)
<id 224 / read 1> chk - done.
Funktionspruefung ergab 22
Messung -> [(<id 224 / read 0> reg 0)<id 224 / read 1> wait: 4 ok]
(<id 224 / read 0> reg 0)
<id 224 / read 0> start - done.
Messung laeuft.
Bereitschaft -> [(<id 224 / read 0> reg 0)<id 224 / read 1> wait: 4 ok] ok.
Ergebnis -> [(<id 224 / read 0> reg 0)<id 224 / read 1> wait: 4 ok]
(<id 224 / read 0> reg 2)
<id 224 / read 1> recv - done.
Ergebnis der Messung: 0
Nicht erschrecken, ist recht strukturiert. Eckige Klammern bedeuten einen Unterblock, in dem er die Empfangsbereitschaft prueft (nach Reg. 0, != 255 falls bereit); runde Klammern waehlen ein Register aus (Zielregister mit reg x angegeben); spitze Klammen sind Startcondition (ID und read bit gibt er aus); die jeweils letzte Zeile in einem Einrueckblock ist der eigentliche Befehl an den Sensor bzw das Lesen; und schliesslich die Bloecke sind logische Einheiten, was er tut, steht ja jeweils dran.
Anzufuegen ist, dass jeweils bei fehlenden ACK N/A bei Verbindungsabbruch, Befehl nACK bei Nichtbestaetigung etc stehen muesste, was ueberall fehlt; es kommt also alles an und wird verstanden.
Nun aber die Probleme: Firmwareversion - passt 4? Funktionspruefung (Inh. Register 1) ist voellig falsch, sollte 128 sein. Zudem keine Wartezeit bei Messung, Distanz egal, LED blinkt nicht; der Befehl wird also geACKt, aber nicht ausgefuehrt. Dann das Ergebnis: Immer 0 - er misst ja auch nicht. Aehnliches bei Addressvergabe. Die Register scheint er aber zu wechseln, die Werte aendern sich ja jeweils und sind auch immer gleich...
Hat jemand nun eine Idee? Habe hier 10 Sensoren liegen, die sollten ALLERSPAETESTENS bis Ende der Woche laufen 
Ach ja, verhalten sich alle gleich...
Danke fuer Hilfe im Voraus,
David
PS: Sry fuer Telegrammstil, aber ist so schon genug Text 
PPS: Schreibe ich zum Beispiel nur 1 und lese dann, kommt auch 22, wo 128 stehen sollte...
Ed: Die ganzen Edits mal geloescht, falsche Faehrten unzo.
ZitierenDank eines genialen Oszis, hab endlich mal geblickt, wie man Speciher und Trigger kombiniert, konnte ich mir die komplette Kommunikation ansehen und hab herausgefunden, dass der Sensor wohl nach einem ACK wieder ein LOW haben will, um STOP anzuerkennen. Das hats jedenfalls bei mir komplett gerichtet. Ach ja, weiterer Fehler: Beim Geben von Befehlen NICHT regSelect -> stop > start > Befehl, sondern Select > Befehl! Wird wohl nicht zwischengespeichert. Deshalb wurden auch Befehle nicht ausgefuehrt. Warum der Pruefwert in Reg 1 nicht stimmt, konnte ich allerdings immer noch nicht herausfinden...
Lesezeichen