Hallo,
ich spiele gerade mit einem AVR128DB64 rum und probiere Formeln aus wie
man den optimalen BAUD Wert für den I2C Takt berechnet für
unterschiedliche Gegebenheiten. Dabei fiel mir auf, dass der Takt stark
vom Pullup abhängig ist. Nur wie kann das sein? Für die Messung sollte
doch die Form der Flanke keine Rolle spielen. Es zählt doch rein die
Periodendauer. Egal ob Rechteck oder Sägezahn. Ist der Taktgenerator im
Controller Last abhängig? Es gibt teilweise Unterschiede von 50kHz. Mir
geht es um eine Erklärung für die Taktunterschiede je nach Pullup. Kann
das jemand bitte erklären?
"The low (TLOW) and high (THIGH) times are determined by the Master Baud
Rate (TWIn.MBAUD) register, while the
rise (TR) and fall (TOF) times are determined by the bus topology."
Im entsprechenden Bild sind die Zeiten eingezeichnet.
Daher, wenn sich die TR und TOF Zeiten ändern durch hohe PULL UP
Widerstande dann läuft TLOW und THIGH erst später los.
Dadurch ergeben sich halt andere Periodenzeiten.
Hallo,
genau das ist ja das Problem bzw. Frage. Ich denke ich muss die Frage
anders formulieren. Wie wird denn der SCL erzeugt? Wenn ich mir
vorstelle ich programmiere einen Timer, dann macht der seinen Takt egal
was für Last dranhängt. Maximal bricht die Spannung ein mit zu hoher
Last aber der Takt bleibt konstant. Warum ist das bei SCL anders?
Veit D. schrieb:> Warum ist das bei SCL anders?
Nur Bedingt, aber diverse I2C Bauteile unterstützen "Clock Stretching".
Dies bedeutet das die angesprochene Device den Clock auf "Low" hält bis
er das letzte Bit verarbeitet hat.
Wen der Master dies unterstützt wartet er bis der Clock wieder auf
"High" geht.
Veit D. schrieb:> Warum ist das bei SCL anders?
SCL ist bidirektional, d.h. der Master liest mit, ob vielleicht ein
Slave noch anderweitig beschäftigt ist und den Clock streckt.
Die Leitungskapazität wird dadurch auch berücksichtigt.
Ein Slave zieht SCL auf low, bis er seinen Interrupt abgearbeitet hat.
I2C benötigt daher kein Handshake.
Hallo,
ich schicke für meine Messungen derzeit nur sturr eine Adresse raus und
frage nichts ab. Da ich keine Antwort auswerte und auch keine Daten vom
Device anfordere dachte ich das sich dadurch nichts beeinflusst. Maximal
würde ein ACK/NACK zurückkommen was ich wie gesagt nicht abfrage bzw.
auswerte.
Wenn ich euch richtig verstehe kann auch dabei schon der Slave Einfluss
auf SCL nehmen? Oder sollte hierbei noch nichts passieren?
Nochmal einen Schritt zurück. Ich habe eine Takt-Abhängigkeit vom Pullup
festgestellt. Demnach muss diese Last die SCL Erzeugung beeinflussen.
Oder bin ich auf dem Holzweg?
So recht glauben kann ich deine Bilder mit 400kHz nicht ganz. Das mit
2k2 PU erscheint mir die Steilheit der fallenden Flanke nicht ganz
passend. Waren das jeweils die selben Bedingungen?
Messen müsstest du vom Beginn der fallenden Flanke bis zum Beginn der
nächsten fallenden Flanke. Und da scheint mir bei 400KHz die Periode bei
allen drei Bildern gleich zu sein.
Für die automatische Messung mit dem Skope spielt die Steilheit der
Flanke u.U. schon eine Rolle auf Grund des flachen Verlaufs der
ansteigenden Flanke. Ich würde selber die Zeiten jeweils zu Beginn der
Flanken ermitteln und dann umrechnen.
Nebenbei: 1k PU an 5V ist meiner Erinnerung nach etwas zu viel Strom für
die meisten I2C-Interfaces. Ich habe maximal 3mA in Erinnerung nach
I2C-Spec.
Hallo,
das Oszi ist auf fallende Flanke eingestellt. Bildvertauschungen
schließe ich eigentlich aus. Sollte es dem Oszi nicht egal sein wo der
Trigger für seine Messung liegt? Es wird doch immer an der gleichen
Stelle gemessen, damit sollte es egal sein wo wer wie misst.
Wegen 1k und 3mA. Es gibt noch den FastModePlus mit 20mA. Die 1k sind
auch nur zum testen/messen, eigentlich hatte ich mich auf 3,3k und
400kHz festgelegt.
Veit D. schrieb:> Wenn ich euch richtig verstehe kann auch dabei schon der Slave Einfluss> auf SCL nehmen? Oder sollte hierbei noch nichts passieren?
In deinem Fall nimmt der Slave keinen Einfluss sondern die langsam
steigende Flanke.
Das streching geschieht indem es auf 0 gehalten wird vom Slave.
Und im Datenblatt steht THigh geht erst los wenn ein High erkannt wurde.
Je flacher deine Flanke desto später ein High.
Veit D. schrieb:> Wenn ich euch richtig verstehe kann auch dabei schon der Slave Einfluss> auf SCL nehmen?
Ja, das ist sogar die kritischste Stelle, weil genau an dieser Stelle
der Slave die meisten Entscheidungen auf einmal treffen muss. D.h.: hier
denkt er am längsten darüber nach, was er zu tun hat.
Allerdings betrifft das praktisch wohl ausschließlich den Takt des
ACK-Bits. Theoretisch ist es allerdings jedem Slave möglich, jeden Takt
zu stretchen.
> Nochmal einen Schritt zurück. Ich habe eine Takt-Abhängigkeit vom Pullup> festgestellt.
Ja, kann passieren. Wenn der Pullup zu groß ist, kann das aus Pullup und
Leitungskapazität gebildete RC-Glied genauso wirksam werden wie
Clock-Stretching. Weil halt der Master nicht sehen kann, warum noch
nicht wieder der H-Pegel erreicht ist, der kann nur sehen, dass das
nicht der Fall ist und wird dann warten, bis es der Fall ist, weil das
der Standard halt so vorsieht.
c-hater schrieb:> Theoretisch ist es allerdings jedem Slave möglich, jeden Takt> zu stretchen.
Der Philips P87C751 hatte ein I2C-Bitinterface, d.h. je Bit gibt es
einen Interrupt mit Clock Stretching. Der Vorteil des Bitinterfaces war,
daß es einwandfrei funktionierte, wenn man es sauber programmiert hat.
Im Datenbuch gab es dazu ausführlich erklärten Assemblercode. Solche
exzellenten Datenbücher wünschte ich mir heute auch noch.
Viele AT89C51 und AVR haben zwar ein komplexes I2C-Byteinterface, aber
mit heftigen Bugs. Auf die buggy Statemaschine hat man keinen Zugriff.
Wenn die abstürzt kann man es nur disablen, wieder enablen und
hinterläßt alle Teilnehmer in einem undefinierten Zustand. Man muß
danach also erstmal ein I2C-Recovery machen, mit bis zu 9 SCL-Pulsen,
bis SDA = 1 ist und dann ein STOP senden.
https://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html
Hallo,
ich denke ich habe die Zusammenhänge jetzt verstanden. Alles hängt von
allen ab. Gerade das mit dem High Pegel musste mir erst bewusst werden.
Manchmal dauerts länger. ;-)
Danke an alle.
Peter D. schrieb:> Auf die buggy Statemaschine hat man keinen Zugriff.
Wie kommt es, dass die häufigen Bugs des Siliziums durch die
Simulationen und Testcases der Hersteller schlüpfen? Man sollte meinen
das I2C Protokoll ist mittlerweile nach 40 Jahren so stabil und total
dokumentiert, so dass die notwendigen internen State-Machines und HW
dann genauso wie gewollt funktionieren.
Es ist gar nicht meine Absicht hier böswillig zu kritisieren. Ich
wundere mich nur, dass das alles beim Chip Design immer so schwierig zu
bewältigen ist. Mit Simulation muss das doch überschaubar bar sei - oder
nicht? Die STM32F103 I2C FSM war ja auch voller Bugs. Man sollte meinen,
dass viele uC-Bugs nach zig Jahren Entwicklung mittlerweile nahezu
ausgestampft sind und dass dann auf erwiesene fehlerfreie Subsystems
zurück gegriffen werden könnte. Die kopieren doch auch Vieles von
benachbarten Designs - Oder Nicht?
Gerhard O. schrieb:> Ich> wundere mich nur, dass das alles beim Chip Design immer so schwierig zu> bewältigen ist.
Die alten Hasen gehen in Rente und die jungen Hüpfer von der Uni haben
nicht mehr gelernt, wie man sorgfältig entwickelt und prüft. Bzw. sie
überlassen alles der CAD-Software, wenn der Designcheck durchläuft, wird
wohl alles stimmen. Die alten Hasen hatten diese Supertools noch nicht
und mußten noch viel Papier, Stift und Brain1.0 benutzen.
Auch müssen heutzutage immer komplexere MCs in immer kürzerer Zeit auf
den Markt geschmissen werden. Daher muß die Zuverlässigkeit darunter
leiden.
Hallo,
das Problem kennt eigentlich jeder in klein wenn man eigene Boards
entwickelt. Ich glaube nicht das bei jedem jedes erste Boarddesign
perfekt ist. Und das ist Meilenweit entfernt von Chipdesign. In der
Industrie auf Chipdesign bezogen ist es das Gleiche. Dann lautet die
Frage wie schlimm sind die Fehler und wieviel Zeit kostet es diese
auszumerzen. Lohnt sich das jetzt oder hat das Zeit.
Ich würde aber nicht soweit gehen und behaupten das die alten Hasen
immer Fehlerfrei entwickelt haben. Je komplexer umso komplizierter. Das
kann man gar nicht alles immer überblicken. Weil wenn die "alten Hasen"
perfekt gearbeitet hätten, dann müßten alte CPUs und MCUs fehlerfrei
sein. Dann müßte auch die I2C Einheit fehlerfrei sein. Das widerspricht
sich dann doch irgendwie. Und ich glaube nicht das in den Designzentren
die Dümmsten sitzen. Man denkt nur immer das früher alles besser war.
Ich glaube der Eindruck täuscht.
Gerhard O. schrieb:> Die STM32F103 I2C FSM war ja auch voller Bugs.
An diesem Beispiel kannst du den 'Fortschritt' sehen: Frühere Designs
hatten eine wahre Flut von Interrupts erzeugt, aber damit konnte man so
lala leben. Es war bloß lästig.
Die neuen Entwickler-Hasen meinen, so etwas viel eleganter lösen zu
können, aber sie sehen viele Dinge eben nicht, weil ihnen sowohl
Erfahrung als auch Vorstellungskraft fehlt. Und dabei kommt ein I2C-Core
bei heraus, der schlußendlich alles selbst erledigen will, aber dabei so
gut wie unbenutzbar ist.
W.S.
W.S. schrieb:> so gut wie unbenutzbar ist
Finde ich (für den STM32F103) doch arg übertrieben. Es gibt eine
application Note, die beschriebt wie man dessen I²C Port nutzen kann,
und genau so funktioniert er auch tadellos.
Thread beobachten
Seitenaufteilung abschalten