Hi, ich versuche mittels Raspi (Master) einem STM32F031 (Slave) ein Bild zu senden, welches er dann auf einem Display, dass am SPI hängt, anzeigt. Dazu muss ich vorher prüfen, ob das Display bereit ist Daten zu empfangen. Dafür habe ich ein Kommando eingerichtet (0x04). Sendet der Raspi jetzt 0x04 an den STM, so prüft dieser die Bereitschaft des Displays und meldet dann entweder ready (0x05) oder eben busy (0x06) zurück. So weit die Theorie. Jetzt habe ich aber das Problem, das der STM durch Clockstretching den Bus blockiert wenn er nicht rechtzeitig antworten kann. Und da der Raspi kein stretching unterstützt bricht er die Übertragung ab. Also habe ich das Stretching deaktiviert. Und siehe da die Übertragung geht nicht mehr. Der Raspi fragt den Status ab und bekommt als Antwort immer 0xFF. Diese Antwort habe ich aber in keinem Fall festgelegt. Wieso kann der STM ohne Clockstretching scheinbar den Datenpin nicht mehr auf low ziehen?? Die wirklich einzige Änderung die ich vorgenommen habe ist folgende: hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE; -> hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_ENABLE;
DisplayFreak schrieb: > Und da der Raspi kein stretching unterstützt Der unterstützt schon stretching. Aber es gibt einen Harwarebug (im Chip), durch den er unter ganz bestimmten Umständen, nicht erkennt, daß der Slave die Clock verlängert. Das wiederum führt zu merkwürdigen Fehlern in den Programmen der höheren Schichten, die das nicht erkennen können. Ein Workaround ist, stretching nicht zuzulassen. MfG Klaus
Klaus schrieb: > Ein Workaround ist, stretching nicht zuzulassen. Eben das versuche ich ja. Nur ist der STM aus irgendeinem Grund nicht in der Lage mittels Slave Transmit daten zu senden. Er sendet immer 0xFF, was für mich so aussieht, als könne er SDA nicht auf low ziehen. Mit aktiviertem Clockstretching kann er korrekt senden, der Raspi mag das aber nicht immer und so kommt es ab und an zu Fehlern.
Dann bleibt wohl keine andere Option, als den STM32 Code so weit zu tunen, dass er ohne Clockstretching läuft. IIC-Interrupt auf höchste Priorität setzen und dann schlanken Code generieren. Die HAL-Library ist dazu nicht geeignet…
Oder I²C-Master auf dem Raspi mit Bitbanging selber implementieren.
Hast Du mal mit dem Oszi oder Logicanalyzer geschaut wie lang das Clock stretching in der Praxis überhaupt ist?
Es gibt ein clockstretching beim ersten Takt nachdem die I2C Adresse übertragen wurde. Das ist aber wirklich minimal. Statt 8µs low - 8µs high ist es hier 10µs low und 6µs high. Ich dachte der STM ist an der Stelle evt. zu langsam für das was zwischendrin in der HAL routine läuft. Also hab ich den Systemtakt von 8MHz auf 48MHz angehoben. Das bringt aber gar keinen Effekt.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.