Hallo zusammen
Ich benutze gerade einen TMS320F28388D und müsste mit dem mit einem
TLI493D-W2BW von Infineon kommunizieren. Dazu implementiere ich die
generische Bibliothek die von Infineon bereitgestellt wird.
Das Problem ist, dass meine I2C write Funktion nicht richtig
funktioniert, das angehängte Bild (w2bw_debugging) zeigt das Resultat,
wenn man zwei bytes in den Sensor schreiben möchte (also
"w2bw_i2c_write" mit count=2).
Der uC schreibt die Adresse und die beiden bytes welche auch vom Sensor
bestätigt werde. Danach verhält sich der uC allerdings seltsam und
sendet die Adresse des Sensors erneut (der Protokoll-Analysator
registriert das als einen "Re-Start", habe davon aber im Zusammenhang
mit I2C noch nie gehört).
Das I2C Modul konfiguriere ich mittels:
Das Programm scheint auch immer in der while loop stecken zu bleiben,
e.g. die FIFO scheint nicht leer zu sein. Wenn ich mir die Register des
I2C Moduls anschaue fällt auf, dass diese sich ändern sobald ich das
Programm mit dem Debugger anhalte. Wenn das Programm normal läuft (also
scheinbar in der while-loop stecken bleibt, zeigt die Register-Vorschau
einen Transmit-FIFO status von 0 [also nichts in der Transmit-FIFO],
wenn ich das Programm anhalte jedoch ändert sich die Register-Vorschau
und zeigt einen Transmit-FIFO Status von 2 [also 2 bytes in der Transmit
FIFO], zudem scheint das NACK interrupt bit gesetzt.
Weiss vielleicht jemand, was da los ist?
PittyJ schrieb:> Zeile 18: müßte da nicht etwas von addr enthalten sein?
Diese Zeile setzt die I2C Slave Adresse, addr ist ein pointer auf die
Daten, die gesendet werden sollten.
Mductance schrieb:> addr ist ein pointer auf die> Daten, die gesendet werden sollten.
Nö. Der heißt "data". addr ist kein Pointer, sondern ein uint8_t, und
wird in Deiner Funktion nirgendwo verwendet.
DerEinzigeBernd schrieb:> Mductance schrieb:>> addr ist ein pointer auf die>> Daten, die gesendet werden sollten.>> Nö. Der heißt "data". addr ist kein Pointer, sondern ein uint8_t, und> wird in Deiner Funktion nirgendwo verwendet.
Hmm, ok, das habe ich nun entsprechend geändert, allerdings ändert das
nichts am Verhalten des uCs, die Adresse ist immer noch die gleiche
under uC sendet weiterhin eine weitere Start-Condition nachdem er die
zwei Bytes gesendet hat.
So, mittlerweile konnte ich herausfinden woran das Problem lag. Nachdem
man das Stop-Condition bit mittels I2C_sendStopCondition gesetzt hat
muss man eine Weile warten um sicherzustellen, dass die STOP condition
auch richtig erzeugt wird, das kann man machen indem man das BB
(Bus-Busy) bit pollt:
Zuvor gab es das Problem, dass sie Sensor-Library welche die
w2bw_i2c_write interface Funktion benutzt mehrere I2C writes
hintereinander aufruft. Der eine w2bw_i2c_write Aufruf kam dann bevor
die Stop-Condition des vorigen Aufruds richtig auf den Bus gesetzt
werden konnte. Durch das zusätzliche Warten am Ende der Funktion können
dann mehrere I2C writes hintereinander richtig aufgerufen werden: