Hallo, beim Raspberry PI A und B tritt der i2c-clock-stretching bug auf. http://www.advamation.de/technik/raspberrypi/rpi-i2c-bug.html Grosse Frage: ist der Bug beim Raspberry PI 2 behoben worden? mfg Klaus
Klaus Ra. schrieb: > ist der Bug beim Raspberry PI 2 behoben worden? 1) Nein: http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=13771&start=25 2) Obwohl es ein Hardware-Bug ist scheint der nur unter Linux (Treiber in C) aufzutreten, nicht in Bare-Metal Assembler oder unter RISCOS (das in Assembler programmiert ist): https://www.riscosopen.org/wiki/documentation/show/IIC_Control
Hallo Lothar, also liegt es eher am Betriebssystem. Wie sieht es unter Android aus? mfg Klaus
Lothar schrieb: > 2) Obwohl es ein Hardware-Bug ist scheint der nur unter Linux (Treiber > in C) aufzutreten, nicht in Bare-Metal Assembler oder unter RISCOS (das > in Assembler programmiert ist): Wo ist das belegt? Die verlinkte Seite zeigt zwar den API, aber vermeldet nichts zu Thema.
:
Bearbeitet durch User
Hallo, ich habe mein Clock Stretching Problem mit diesem Link (Option 2) gelöst. http://doc.byvac.com/index.php5?title=RPI_I2C Wobei zu sagen ist, dass ich als I2C- Slaves "langsame" ATTinys nutze. Man muss allerdings aufpassen, wenn man vom Pi B Version 1 auf den Pi B Version 2 wechselt. Da sind noch zusätzlich die GPIO-Adressen anzupassen (mit anschliessender Neukompilierung), sonst laufen die Pi- V1 Programme auf dem Pi B Version 2 nicht (mehr). Viel Erfolg
Der I2C Clock Stretching Bug ist Hardwareseitig und besteht meines Wissens auch beim RP2. Wenn man einen Slave ansprechen will, der Clock Stretching beherrscht, muss man die I2C Takt verringern, so das der Slave nicht dazu genötigt wird Clock Stretching anzuwenden.
Prinzipiell richtig! Und auch beim RP2! ... Nicht aber, wenn man den I2C Bus in Software (zusätzlich) umsetzt ...! Grüße
Christian K. schrieb: > Wenn man einen Slave ansprechen will, der Clock Stretching beherrscht, > muss man die I2C Takt verringern, so das der Slave nicht dazu genötigt > wird Clock Stretching anzuwenden. Es kann manchmal ganz schön lange dauern, bevor ein Slave ein ACK liefert. Die Zeit addiert sich dann auch auf alle anderen Bits, wenn man das mit dem I2C Takt regeln will, auch wenn der Rest eigentlich schnell gehen würde. MfG Klaus
Da ich gerade einen Class-D / DSP mit einem PI Model A verbinden will, ist das extrem interessant. Aber viel Doku und unterschiedliche Ergebnisse (abgesehen, dass alle sagen: Es geht nicht richtig)... Laut I2C Spezifikation gibt es ja zwei Bremsen, auf die ein Slave treten darf: Clock-Stretching, wenn er Zeit benötigt die Bits in eine Queue einzusortieren. Hier bremst er, in dem er nach jedem Bit SCL noch auf Low hält. ACK-Stretching, wenn er Zeit benötigt, das Ziel zu selektieren und das Datum zu schreiben, oder das Ergebnis zu berechnen beim Lesen. Hier bremst er normalerweise vor dem ACK in dem er SCL nach dem letzten gesendeten oder empfangenen Bit, auf das ACK oder NACK folgt, low hält. Die Ausrede, dass ACK/NACK nur nach dem Read ACK/NACK funktioniert ist nur ein sinnloser versuch die Ehre zu retten. Ein Client kann nur zwischen dem letzten Bit und dem darauf folgen ACK oder NACK entscheiden, was von beidem er senden muss. Und daher braucht er genau dann auch Rechenzeit. Und auch genau das definiert die I2C Spezifikation. Die beiden BCM Chips sind dann aus der Erinnerung die Nummer 31 und 32 auf der Liste der vergeigten I2C Interfaces in Hardware oder Software auf meiner Liste... Für jeden der es richtig machen will: http://www.nxp.com/documents/user_manual/UM10204.pdf Es gibt aus der langjährigen Vergangenheit mit I2C folgende zwei Fehler, die von fast allen mir jemals untergekommenen Implementationen gemacht wurden, die nicht oder nur leidlich funktionierten: Fehler 1: Höflichkeit Es gibt das umgangssprachliche "should" im Englischen und das bedeutet kann, darf oder sollte. In Datenblättern ist aber das Intel-should gemeint und es umschreibt höflich: "Wenn du es anders machst, geht es nicht, basta!" Fehler 2: Timing ist relativ! Wenn in der Spec nur ein min Wert angegeben ist, dann hat es kein max! Das ist absichtlich so geschrieben, weil es eben eine Mindest-Zeit gibt die es mindestens sein muss, aber es kann so lange dauern, wie es will! Also bitte die Seiten 48ff im oben verlinkten Datenblatt ausdrucken und unters Kopfkissen legen, damit das Timing komplett durchsickert. Fehler 3: Automobilindustrie Liebe Radio-Bauer... Ehrlich! 4x 100n und 1x 10uF jeweils auf SDA und SCL sind auch für den langsamsten I2C viel zu viel! Gruß Ulrich
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.