Forum: Mikrocontroller und Digitale Elektronik Raspberry PI i2c-clock-stretching bug


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Klaus R. (klara)


Lesenswert?

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

von Lothar (Gast)


Lesenswert?

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

von Klaus R. (klara)


Lesenswert?

Hallo Lothar,
also liegt es eher am Betriebssystem. Wie sieht es unter Android aus?
mfg Klaus

von (prx) A. K. (prx)


Lesenswert?

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
von drama (Gast)


Lesenswert?

Sonst einfach I2C per Bitbanging machen.

von Hendrik L. (lbd)


Lesenswert?

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

von Christian K. (the_kirsch)


Lesenswert?

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.

von Hendrik L. (lbd)


Lesenswert?

Prinzipiell richtig! Und auch beim RP2!

... Nicht aber, wenn man den I2C Bus in Software (zusätzlich) umsetzt 
...!

Grüße

von Klaus (Gast)


Lesenswert?

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

von Ulrich P. (uprinz)


Lesenswert?

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.