Hallo,
ich habe einen STM32F103 Controller (Master) und möchte über den I2C-Bus
mit einem Sensor (Slave) kommunizieren.
Unter anderem ist es notwendig ein einzelnes Byte von dem Sensor zu
empfangen. Meine Funktion dafür sieht so aus:
// Wait until data has been received in DR register (RXNE = 1) -> EV7
43
while(!I2C_GetFlagStatus(I2Cx,I2C_FLAG_RXNE));
44
45
// Read the data
46
buffer=I2C_ReceiveData(I2Cx);
47
48
// Make sure that the STOP bit is cleared by Hardware before CR1 write access
49
while(I2Cx->CR1&I2C_CR1_STOP);
50
51
// Enable Acknowledgement to be ready for another reception
52
I2Cx->CR1|=I2C_CR1_ACK;
53
returnbuffer;
54
}
Das Problem ist jedoch, dass das Senden der Stop Condition quasi
wirkungslos ist. Das STOP-Bit wird von der Hardware nicht gecleared, das
BUSY und MSL Flag bleiben auch gesetzt. Im Endeffekt bleibt das Programm
in der letzten while-Schleife hängen.
Weiß jemand was der Fehler sein könnte?
Grüße
Nur bei der 40x-Serie benutze ich die Hardware-I2C. Bei allen anderen
bin ich dazu übergegangen, I2C zu Fuss zu programmieren.
Soll nicht heissen, dass es nicht geht. Ich zumindest hab's aber nicht
geschafft.
Danke :)
Ich habe mir die Beispiele mal angeschaut, finde die aber nicht wirklich
verständlich ... gibt es irgendwo ein Beispiel wo einfach nur ein I2C
Slave vom Microcontroller gesteuert wird?
Ja hab es mittlerweile wieder zum "laufen" bekommen mit der CPAL
Library.
Aber: Es tritt immer noch genau das gleiche Problem auf! STOP Bit
gesetzt sowie MSL und BUSY. Das Programm hängt sich immer noch bei der
(einer neuen) while-Schleife auf.
Das Problem tritt nicht auf, wenn ich einen Breakpoint bei der
while-Schleife setze oder ein Oszilloskop anschließe, weiß jmd. woran
das liegen könnte?
Die lokale Instanz von CPAL_TransferTypeDef ist einigermaßen ungünstig
für die Arbeit mit der CPAL-Lib, weil dadurch der I2C-Controller
andauernd neu initialisiert wird. Das solltest du vermeiden.
Ansonsten sind 1-Byte-Geschichten mit dem I2C-Controller des STM32 immer
so eine Sache... Kann gehen, muss aber nicht. Gerade in Verbindung mit
I2C-Slaves, die nicht 100% dem Standard folgen, gibt es immer wieder
massive Probleme.
Ehrlich, wenn ich vorher geahnt hätte, WIE fehlerbehaftet die
I2C-Peripherie von dem Teil ist, und wie oft ich das gerade brauche,
hätte ich gleich einen anderen Controller ausgewählt.
Die CPAL-Lib hat ihre Grenzen spätestens da, wo nur ein Befehl
übertragen wird und keine Daten, damit kommt das Teil dann meiner
Erfahrung nach gar nicht mehr zurecht.
Dass das unperformant ist ist mir klar, mir ging es erstmal darum, ein
funktionsfähiges Programm zu erstellen.
Aber das kanns ja nicht sein, es muss doch eine Möglichkeit geben ein
einzelnes Byte über den I2C Bus zu empfangen. Soll ich jetzt dummy reads
machen und das ist die Lösung oder wie?
Wo findet man diese Prio Liste denn,
oder ist es so, dass ST erst dann einen intern schon bekannten Bug
zugibt, wenn man dafür genug Beweise lifert?
mfg