Frage bezüglich TWI bzw. I2C-Pegel

[Ceos]

warte warte warte ... der Raspi kann kein Clock Stretching? ... das ist schwach, da les ich mich nochmal genauer zu ein wenn ich Zeit habe

[HaWe]

Genau, sag ich doch, zumindest nicht mit dem damaligen Kernel (bis Anfang April dieses Jahres). Dazu gibt es sogar hier im Forum ein Topic.
Das clock stretching wurde wohl durch den AVR Arduino verursacht (was viele auch im raspi Forum für die Ursache der I2C Datenübertragungsfehler hielten), und eben das vertrug der Raspi nicht, daher konnten mal keine großen Datenblöcke auf einmal übertragen werden und ein anderes Mal schmiss der Raspi sogar den Arduino aus seinem I2C Bus und erkannte ihn gar nicht mehr als I2C device unter seiner Busadresse.
Seit dem 10.4. gibt es allerdings einen neuen Kernel, vlt kann der mehr als der vorhergehende, seitdem habe ich die AVRs aber nicht mehr am Raspi-i2c-Bus getestet..
Mit dem Aruino DUE (andere berichteten, glaube ich, auch mit demZero) funkionierte aber vorher schon I2C immer außerordentlich zuverlässig.

ich bezog mich auch auf den "echten" I2C Modus, wie er unter C/C++ mit pigpio und wiringPi benutzt wird (mit Arduino per 100kHz, ansonsten mind. bis 400kHz), der wohl langsamere smbus-Modus als auch Software-Bitbanging waren in dieser Hinsicht toleranter. Auch zum letzteren gab es im besagten Topic Beispiele.

[Ceos]

das smbus Protokoll definiert ja clock stretching, logisch dass es da verwendet wird.
Aber ich bin mir ziemlich sicher dass jedwede Hardware I2C Logik (also das peripheral im raspi SoC) auch dazu in der Lage ist aber die I2C-Libs das notwendigeFflag nicht einschalten .... einer der Gründe warum ich meistens doch lieber Bare Metal programmiere wenns ordentlich werden soll, Bibliotheken scheitern immer an DEtails die der Erfinder nicht bedacht hat.

[HaWe]

...was erklärt, dass damals schon viele Raspi-"Fachleute" (Gordon Henderson, joan u.a.) das Problem schon kannten, samt möglicher Workarounds, und auch davon sprachen, dass ebenfalls die .org Entwickler das auch schon auf dem Schirm hatten und in "einer der nächsten" Kernel-Upgrades mit ändern wollten. Ich selber verstehe die hardwaremäßigen oder Programmier-technischen Einzelheiten nicht, ich kam nur drauf, dass ich es versuchte PI + Arduino zu verbinden, es aber nicht störungsfrei mit den AVRs funktionierte.

[Klebwax]

...was erklärt, dass damals schon viele Raspi-"Fachleute" (Gordon Henderson, joan u.a.) das Problem schon kannten, samt möglicher Workarounds, und auch davon sprachen, dass ebenfalls die .org Entwickler das auch schon auf dem Schirm hatten und in "einer der nächsten" Kernel-Upgrades mit ändern wollten. Ich selber verstehe die hardwaremäßigen oder Programmier-technischen Einzelheiten nicht, ich kam nur drauf, dass ich es versuchte PI + Arduino zu verbinden, es aber nicht störungsfrei mit den AVRs funktionierte.

Wenn ich mich recht erinnere ist bzw. war das so:
Der Prozessor im Raspi unterstützt schon Clock stretching, der Treiber ebenfalls. Es gab aber einen Bug im Chip der dazu führt, daß in einem bestimmten Zeitfenster nach dem ACK-Bit das Clock stretching nicht erkannt wurde. Das ist aber nun genau die Stelle, die am kritischsten ist, nach dem ACK-Bit passiert das am häufigsten.

Da der Raspi nicht mein Ding ist, hab ich keinen Link aufgehoben und kann das nicht mehr nachvollziehen. Ob inzwischen der Chip gefixt ist oder eine Reparatur in Software möglich ist, hab ich nicht verfolgt.

MfG Klebwax

[HaWe]

das führt uns jetzt zwar von dem 5V/3.3V I2C Problem mit/ohne Pullups u/o Levelshiftern weg, würde aber dann sicher bedeuten, dass es bei einem Chip-Hardware-Bug nicht allein durch ein Jessie-Kernel-Upgrade gelöst werden kann, oder?
Außerdem wäre interessant zu wissen, welche Chips von diesem Bug betroffen waren - da ich den Pi2 habe, mit dem es diese Probleme gab, wäre zu vermuten, dass es dann möglicherweise nicht unbedingt auch mit dem B+ oder Pi3 der Fall ist/war oder sein muss?

[Klebwax]

das führt uns jetzt zwar von dem 5V/3.3V I2C Problem mit Pullups u/o Levelshiftern weg, würde aber dann sicher bedeuten, dass es bei einem Chip-Hardware-Bug nicht allein durch ein Jessie-Kernel-Upgrade gelöst werden kann, oder?
Außerdem wäre interessant zu wissen, welche Chips von diesem Bug betroffen waren - da ich den Pi2 habe, mitt dem es diese Perobleme gab, wre zu vermuten, dass es dann möglicherweise nicht unebsingt auch mit dem B+ oder Pi3 der Fall ist/war oder sein muss?

Ob das in SW gefixt werden kann, weiß ich nicht. Der Floating Point Bug in einer Version der Pentiums ließ sich in SW umgehen, bis die Chips OK waren. Da ich mich nicht besonders um den Pi und seinen Prozessor gekümmert habe, kann ich nicht mehr sagen.

MfG Klebwax