Hallo! Habe ein Gerät mit mehreren Chips gebaut, welches mit dem Raspberry Pi Zero W angesteuert wird. Der Pi sollte mit den Chips über I2C kommunizieren. Ich wusste leider nicht, dass der Pi kein Clock-Stretching unterstützt. Nun habe ich Probleme mit den Glitches auf der Clock-Leitung. Habe gehört, dass das Problem in Hardware liegt und ein Software-I2C davon nicht betroffen wäre. Aber wie mache ich es, dass an den selben Pins wie jetzt, statt des Hardware-I2C ein Software-I2C werkelt? Danke im Voraus!
> Aber wie mache ich es, dass an den selben Pins wie jetzt, statt des > Hardware-I2C ein Software-I2C werkelt? Ganz einfach, du programmierst es dir weil es ja Software ist. .-) Olaf
Ich habe ein Dutzend verschiedene I2C Chips am Raspi laufen. Nur ein Chip (DLP von TI) macht Probleme. Der will laut Datenblatt auch Clockstrechting machen. Die Vielzahl der anderen Chips (Temperatur, Beschleunigung, Cryptochip, TOF-Sensor) läuft problemlos. Bevor du jetzt glaubst, dass das Kommunikationsproblem mit Clockstretching zu tun hat, lies doch einfach mal das Datenblatt, oder der Chip das auch wirklich machen will. Und bevor du einen Soft-I2C implementierst oder aktivierst, schau dich nach Alternativen bei Chips um. Andere Hersteller haben auch schöne Chips, die kein Clockstretching benötigen. Das kann einfacher sein, also dieses Software-Dinges zu betreiben. Als erstes würde ich aber ein Scope anschliessen, und schauen, was da wirklich los ist.
Hallo! Der Chip ist leider vorgegeben und der Grund für das ganze Projekt. Es ist bereits sehr viel Arbeit und auch Geld eingeflossen, weshalb es definitiv besser ist, den Chip beizubehalten und die Kommunikation zu verbessern. Ich habe bereits mit einem Logic-Analyzerr mir alles angesehen. Immer dort, wo ein zu kleiner Teil des Clock-Pulses übrig bleibt, gibt es Probleme. Das Bit wird dann falsch gelesen. Die Einzige Alternative, die ich mir noch vorstellen könnte, wäre eine Art "Taktschrittmacher", wo ein zweiter Chip den Puls unterdrückt, bis er voll durchgelassen werden würde vom anderen Chip. Lieber wäre mir eine fertige Lösung in Form einer Bibliothek, die es erlaubt, ein beliebiges GPIO als SCL bzw SDA zu definieren. Dann könnte ich die I2C-Hardwareschnittstelle abschalten und das Soft-I2C auf die gleichen Pins mappen.
Moin, - Clock-stretching kann schon ein PITA sein. Einige Sensoren (z.b. die sht21 Serie von Sensirion) haben halt die Clock angehalten. Damit war die deterministische Auslesung des Sensors schwierig geworden. - Eine Loesung war die Taktfrequenz so herunterzufahren, dass der Sensor so oder so fertig ist mit der Wandlung. Ob das fuer Deinen Sensor passt: weiss ich nicht. - Du hast ja einen Raspberry Pi (Linux-System), wo Du so oder so eine Latenz bei den Reaktion des Systemes hast. Du schrubst, dass Du noch weitere Sensoren am Bus haettest, die bisher einwandfrei funktionieren. Dann koenntest Du die anderen Sensoren an dem vorhandenen Bus lassen und SoftSerial nur auf zwei GPIO-Pins einsetzt fuer diesen einen Sensor. - Eventuell bietet der unbekannte Sensor auch die Moeglichkeit des Pollens der Daten (z.B. neue Sensirions Geraete haben ein Art Busy-Flag, genau wegen dieser Problematik [ja, Hersteller hoeren manchmal zu]). - Wenn das alles nicht geht: Ein Mikrocontroller der Clock-Stretch dazubauen. Leider hat man eine weitere Baustelle, aber wenn Du mit Sensor festgelegt bist waere das noch eine Moeglichkeit. Gruesse Th.
Eine Sache noch: Ich weiss ja Deinen Aufbau nicht, aber i2c bedeutet "Inter-Integrated Circuit" und ist nicht fuer die Langstrecke gedacht. Ich weiss ja auch nicht, wieviele Sensoren mit an dem Bus lauschen. Du schrubst: > Ich habe bereits mit einem Logic-Analyzer mir alles angesehen. Immer > dort, wo ein zu kleiner Teil des Clock-Pulses übrig bleibt, gibt es > Probleme. Das Bit wird dann falsch gelesen. Bist Du sicher, dass das Clockstretching ist? Normalerweise bleibt bei fehlerhaften Clockstretching der Bus stehen. Anyway, ich wuerde sagen: Send Pics Gruesse Th.
Thomas W. schrieb: > - Eventuell bietet der unbekannte Sensor auch die Moeglichkeit des > Pollens der Daten (z.B. neue Sensirions Geraete haben ein Art Busy-Flag, > genau wegen dieser Problematik). > > - Wenn das alles nicht geht: Ein Mikrocontroller der Clock-Stretch > dazubauen. Leider hat man eine weitere Baustelle, aber wenn Du mit > Sensor festgelegt bist waere das noch eine Moeglichkeit. Clock Stretching ist typisch für Slaves, die einen eigenen Microcontroller drauf haben. Dann nützt auch kein Busy-Flag, weil der µC an bestimmten Stellen im Protokoll per Interrupt reagieren muss und der Takt bis dahin automatisch geklemmt wird. Das muss er bei der Busy-Abfrage dann auch.
:
Bearbeitet durch User
Thomas W. schrieb: >> Ich habe bereits mit einem Logic-Analyzer mir alles angesehen. Immer >> dort, wo ein zu kleiner Teil des Clock-Pulses übrig bleibt, gibt es >> Probleme. Das Bit wird dann falsch gelesen. > > Bist Du sicher, dass das Clockstretching ist? Normalerweise bleibt bei > fehlerhaften Clockstretching der Bus stehen. Seine Beschreibung entspricht dem dokumentierten Verhalten des Raspberry Pi I2C Masters bei Clock Stretching. http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html
:
Bearbeitet durch User
Raspi-Nutzer schrieb: > Nun habe ich Probleme mit den Glitches auf der Clock-Leitung. Was haben glitches mit Clock Strechting zu tun ? Raspi-Nutzer schrieb: > wo ein zu kleiner Teil des Clock-Pulses übrig bleibt Wie meinst du 'zu kleiner Teil' Wie bereits von anderen genennt, : - Bist du sicher das Problem wird von (Nicht)-clock stretching verursacht ? - Geschwindigkeit der I2C zurueckbringen Patrick aus die Niederlaende
(prx) A. K. schrieb: > Thomas W. schrieb: >>> Ich habe bereits mit einem Logic-Analyzer mir alles angesehen. Immer >>> dort, wo ein zu kleiner Teil des Clock-Pulses übrig bleibt, gibt es >>> Probleme. Das Bit wird dann falsch gelesen. >> >> Bist Du sicher, dass das Clockstretching ist? Normalerweise bleibt bei >> fehlerhaften Clockstretching der Bus stehen. > > Seine Beschreibung entspricht dem dokumentierten Verhalten des Raspberry > Pi I2C Masters bei Clock Stretching. > > http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html OK.
Bei Slaves mit Clock Stretching steht typisch im Datenblatt, daß SCL bidirektional ist, d.h. kein reiner Eingang.
Patrick C. schrieb: > Was haben glitches mit Clock Strechting zu tun ? Clock Stretching bedeutet, der Slave hält SCL weiter auf Low, nachdem der Master die High-Phase eingeleitet hat. Wenn nun der Master das nicht bemerkt (weil SCL nicht bidirektional ausgeführt ist) und einfach sein Tempo beibehält, dann verkürzt sich die High-Phase des Taktes, oder sie wird sogar übersprungen.
Soul E. schrieb: > Wenn nun der Master das nicht bemerkt Oder wenn Clock Stretching zwar vorgesehen aber falsch implementiert ist, wie beim Raspberry Pi Prozessor.
:
Bearbeitet durch User
Raspi-Nutzer schrieb: > Aber wie mache ich es, dass an den selben Pins wie jetzt, statt des > Hardware-I2C ein Software-I2C werkelt? https://github.com/fivdi/i2c-bus/blob/master/doc/raspberry-pi-software-i2c.md LG, Sebastian
Es gibt ja SPI / I2C Konverter z.B. SC18IS600 da steht aber nicht im Datenblatt ob der Clockstretching kann. Alternativ geht natürlich noch ein kleiner uC der zwischen Pi I2C und I2C Clockstretching Slave übersetzt z.B. EFM8BB3 hat I2C Master und Slave in Hardware.
Angehängte Dateien:
-
Bild_2022-07-25_161831026.png
1,1 KB -
Bild_2022-07-25_162025722.png
1,9 KB
Lothar schrieb: > Es gibt ja SPI / I2C Konverter z.B. SC18IS600 da steht aber nicht im > Datenblatt ob der Clockstretching kann. Doch, das steht drin. SCL müsste dafür I/O sein.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Doch, das steht drin. SCL müsste dafür I/O sein. Vielleicht kann der SC18IS600 doch Clockstretching?? Im Datenblatt steht: I2C-bus serial interface Serial clock synchronization can be used as a handshake mechanism to suspend and resume serial transfer ... when an I2C-bus slave is (continuously) pulling the SCL clock LOW. An interrupt is generated on INT.
Raspi-Nutzer schrieb: > mit dem Raspberry Pi Zero W Den kenne ich nicht... Aber beim 3B hatte ich vergleichbare Probleme. Erkenntnis daraus: Stretching innerhalb eines Bytes mag es gar nicht! Stretching zwischen Bytes, kein Problem, bzw. in Grenzen Einstellbar.
Bei einem Raspi haben wir Software I2C aktiviert, um die Probleme mit Clockstretching zu umgehen. Ging irgendwie in der config.txt dtoverlay=i2c-gpio dtparam=i2c_gpio_sda=44,i2c_gpio_scl=45
Halo!
Danke für eure Hilfe!
Die Lösung ist, den entsprechenden Block in /boot/config.txt anzupassen:
# Uncomment some or all of these to enable the optional hardware
interfaces
#dtparam=i2c_arm=on
dtoverlay=i2c-gpio,bus=3,i2c_gpio_delay_us=1,i2c_gpio_sda=2,i2c_gpio_scl
=3
#dtparam=i2s=on
#dtparam=spi=on
Damit schaltet man das Hardware-I2C ab und mappt das Software-I2C auf
die Pins, wo normalerweise die das Software-I2C läuft. Dadurch rettet
man auch die schon fertige Hardware, die an diesen Pins I2C erwartet.
Im C++ Code (falls man WiringPi verwendet) dann einfach:
i2c_dev=wiringPiI2CSetupInterface("/dev/i2c-3", 0x42);
Die restlichen Funktionen müssen nicht verändert werden.
Soweit ich informiert bin, kann man auch mehrere I2Cs in Software
implementieren, wobei man dann mit den höheren Nummern beginnen muss. 3
muss die kleinste Nummer sein.
Seinen Erfolg kann man mit "i2cdetect -l" überprüfen, wenn man die
i2c-tools installiert hat. (sudo apt update && sudo apt install
i2c-tools)
Hoffe mit dieser Zusammenfassung konnte ich zukünftigen Lesern das Leben
etwas vereinfachen!
Hallo, ich habe auch mit dem Clock-Stretching Bug des Raspi gekämpft. Letztlich habe ich die I2C Datenrate runtergesetzt. Die externen Chips stretchen immernoch, aber dadurch, dass der Clock langsamer läuft wirkt es sich nicht mehr negativ aus.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.