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.
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
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.
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.
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.
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.
(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.
