https://www.st.com/content/ccc/resource/technical/document/reference_manual/2f/b9/c6/34/28/29/42/d2/DM00095744.pdf/files/DM00095744.pdf/jcr:content/translations/en.DM00095744.pdf In der Beispiel-Tabelle ist bei 100 kHz SCL-Low=5µs und SCL-High=4µs. Da hat man bewusst eine µs subtrahiert. Laut Fußnote 2 ist das ein Beispiel unter der Annahme, dass tync1+tysnc2 eben diese 1µs ausmachen. Also wenn der Bus z.B. lange Leitungen (=viel Kapazität =flache Flanken) hat, dann ergeben sich längere Zeiten, als bei kurzen Leitungen. Habe ich das richtig verstanden? Das würde dann ja auch bedeuten, dass die Übertragungsrate nicht alleine von der Konfiguration des Mikrocontrollers abhängt, sondern von außen beeinflusst wird (Clock-Stretching durch den Slave mal außen vor gelassen). Richtig? Dann habe ich noch eine zweite Frage: Das Referenzhandbuch empfiehlt für SDADEL Werte >0, sagt aber auch, dass man CubeMX für die Berechnung benutzen soll. CubeMX setzt hier bei Verwendung der analogen Filter aber immer den Wert 0 ein. Was ist denn nun richtig, und wie berechne ich einen sinnvollen Wert? Dazu habe ich keine klare Vorgabe gefunden. Vermutlich habe ich wie immer einen relevanten Absatz an ganz anderer Stelle im Referenzhandbuch übersehen.
Angehängte Dateien:
Stefanus F. schrieb: > Das würde dann ja auch bedeuten, dass die Übertragungsrate nicht alleine > von der Konfiguration des Mikrocontrollers abhängt, sondern von außen > beeinflusst wird (Clock-Stretching mal außen vor gelassen). Richtig? Ob ein Slave aktiv SCL auf Low hält oder die Leitungskapazität das tut, ist egal. Der Master kann das nicht erkennen. Die Low-Phase ist vorbei, wenn SCL wieder High ist, erst dann fängt die minimale High-Zeit an zu zählen. Das nennt man dann Clock stretching. Bei höheren Frequenzen kann man das leichter erkennen, da hab ich schon mal 600kHz statt der gewünschten/eingestellten 700kHz erlebt. MfG Klaus
Danke Klaus, ich denke, damit ist meine erste Frage geklärt. Die zweite ist noch offen.
Stefanus F. schrieb: > Also wenn der Bus z.B. lange Leitungen (=viel Kapazität =flache Flanken) > hat, dann ergeben sich längere Zeiten, als bei kurzen Leitungen. Habe > ich das richtig verstanden? Ja, richtig, aber viel wichtiger ist die Lage der Flanken zwischen Daten und Clock. Siehe Bildschirmfotos oben. Stefanus F. schrieb: > Das würde dann ja auch bedeuten, dass die Übertragungsrate nicht alleine > von der Konfiguration des Mikrocontrollers abhängt, sondern von außen > beeinflusst wird (Clock-Stretching mal außen vor gelassen). Richtig? Ja, ebenfalls richtig Aber Clock-Stretching muss vom Empfänger aus erfolgen. Ein solches Verfahren gibt bzw. gab es auch bei Mikroprozessoren. Hier gab es einen CS-Mode, bei dem der Speicher die Dauer eines RD/WR Zugriffes bestimmte. Acknowledge Signal vom Speicher, führte zur Fortsetzung des RD/WR Zugriffes. Stefanus F. schrieb: > Das Referenzhandbuch empfiehlt für SDADEL Werte >0 Ich nehme, dass die Daten mit der fallenden Flanke des Clocksignals übernommen werden. Damit haben die Daten die Clock-High-Dauer Zeit sich zu stabilisieren. Mit SDADEL und SCLDEL können Laufzeitunterschiede zwischen Clock und Daten ausgeglichen werden. Kosten natürlich Geschwindigkeit. SCLDEL verzögert den Clock gegenüber den Daten und gibt den Daten damit mehr Zeit für die Stabilisierung. SDADEL lässt die Daten länger für die fallende Clockflanke anstehen und sorgt dafür, dass bei größerer Clocklaufzeit, die richtigen Daten noch erwischt werden. Filtermaßnahmen in Clock und Datenleitungen sollten die zeitliche Relation zwischen Clock und Daten möglichst nicht verändern. SCLDEL und SDADEL helfen diese wieder auszugleichen.
GEKU schrieb: > Ich nehme, dass die Daten mit der fallenden Flanke des Clocksignals > übernommen werden. Ich nehme genau das Gegenteil an. Hmm, was ist nun richtig? Bei meinen eigenen Soft-I2C Implementierungen habe ich das immer so gemacht: Datenbit ausgeben Pause Clock-> High Warte, bis Clock wirklich auf High steht Pause Clock->Low Pause Nächstes Datenbit ausgeben Damit war ich für alle Eventualitäten auf der sicheren Seite - wenn auch langsamer. > Mit SDADEL und SCLDEL können Laufzeitunterschiede zwischen Clock und > Daten ausgeglichen werden. Kosten natürlich Geschwindigkeit. Die Maximierung der Geschwindigkeit ist momentan nicht gefordert. Das heisst dann wohl: Im Zweifelsfall lieber mit kleinen Delays arbeiten, als mit 0. Dann verwende ich mal lieber die Vorgaben aus dem Referenzhandbuch.
Stefanus F. schrieb: > Ich nehme genau das Gegenteil an. Hmm, was ist nun richtig? Das würde bedeuten, dass SCLDEL niemals 0 sein darf, ausser der Clock wird extern stärker verzögert als die Daten. Clock hoch und gleichzeitig Datenwechsel geht sicher schief. Normalerweise bei einer Taktflanke Datenwechsel, bei der anderen Daten lesen.
Angehängte Dateien:
GEKU schrieb: > Das würde bedeuten, dass SCLDEL niemals 0 sein darf Genaaaauuuu, deswegen frage ich ja nach. Nur weil CubeMX da eine 0 verwendet, muss das noch lange nicht richtig sein. CubeMX hat mich schon öfters veräppelt. > Normalerweise bei einer Taktflanke Datenwechsel, > bei der anderen Daten lesen. Du meinst also auch, dass der Empfänger bei der fallenden SCL Flanke die Daten lesen soll. Unglücklicherweise ist sogar die I²C Spezifikation (https://www.nxp.com/docs/en/user-guide/UM10204.pdf) an dieser Stelle nicht eindeutig. Sie beschreibt aus Sicht des Server klar, dass die Daten stabil sein müssen, während SCL=High ist. Aber das sagt noch nicht klar aus, bei welcher Flanke sie der Empfänger übernehmen muss. Wobei mir jetzt gerade etwas eingefallen ist, wo ich "laut" drüber nachdenke: Der Slave darf ja jederzeit die SCL Leitung auf Low ziehen, wenn er mehr zeit braucht. Wenn er das tut, kann er unmöglich wissen, wann der Master die steigende Flanke sendet, weil sie ja eben nicht steigt. Also bleibt da eigentlich nur noch die fallende Flanke als spätester Zeitpunkt, wo er die Daten übernehmen muss. Wenn er will und kann, darf er aber auch die steigende Flanke benutzen, weil die Daten ab da ja stabil bleiben müssen. Scheinbar gibt es da ganz bewusst eine gewisse Flexibilität (Zeitspanne) für die Empfänger, wann genau sie nun die Daten übernehmen sollen. Dann wäre ein Wert 0 für SDADEL ziemlich unsicher. Falls ich da auf dem Holzweg bin, bitte schreien.
Stefanus F. schrieb: > Clock->Low > Pause > Nächstes Datenbit ausgeben Wenn ich die I2C-Spec richtig lese, darf das Datenbit gleichzeitig mit Clock-Low kommen. Die Pause ist also eigentlich überflüssig. Allein schon, daß das Datenbit nicht im selben Befehl wie die Clock ausgegeben wird, garantiert eine Zeit > 0. MfG Klaus
Klaus schrieb: > Wenn ich die I2C-Spec richtig lese, darf das Datenbit gleichzeitig mit > Clock-Low kommen. Die Pause ist also eigentlich überflüssig. Allein > schon, daß das Datenbit nicht im selben Befehl wie die Clock ausgegeben > wird, garantiert eine Zeit > 0. Ja, aber jetzt stelle Dir mal vor, die SCL Leitung wäre kapazitiv ein bisschen höher belastet, als die SDA Leitung. Dann kommt die fallende Flanke eventuell zu spät beim Empfänger an. Das ist vermutlich ein Corner-Case dem man in Echt vielleicht nie begegnet. Andererseits ist mir meistens Zuverlässigkeit wichtiger, als Geschwindigkeit.
Stefanus F. schrieb: > Der Slave darf ja jederzeit die SCL Leitung auf Low ziehen, wenn er mehr > zeit braucht. Wenn er das tut, kann er unmöglich wissen, wann der Master > die steigende Flanke sendet, weil sie ja eben nicht steigt. Also bleibt > da eigentlich nur noch die fallende Flanke als spätester Zeitpunkt, wo > er die Daten übernehmen muss. Wenn er will und kann, darf er aber auch > die steigende Flanke benutzen, weil die Daten ab da ja stabil bleiben > müssen. Der Master muß die Daten 250ns auf SDA legen, bevor er SCL los lässt. Der Slave wartet dann, bis SCL High ist, ganz egal warum. Also bis Master und Slave beide losgelassen haben. Dann hat er je nach Speed 4µs (4,7µs) oder weniger (wenn schneller) Zeit, die Daten zu lesen. MfG Klaus
Ich hätte halt gerne gehabt, im Referenzhandbuch eine Erklärung zu finden anstatt Beispielwerte die extrem vom dort empfohlenen CubeMX abweichen. Das hinterlässt bei mir nämlich den bitteren Nachgeschmack von: Wir wissen mehr als im Referenzhandbuch steht, aber wir verraten es dir nicht. Benutze gefälligst unsere Frameworks.
Das letzte Bildschirmfoto sagt nicht aus, wann die Daten übernommen wird. Der Hinweis, "The Data on the SDA line must be stable during the HIGH Periode of the clock", bedeutet nur, dass sich die Daten während der Clock HIGH ist nicht ändern dürfen. Wobei dies in der Praxis nicht erfüllbar ist. Es schließt nicht aus, dass innerhalb des Clocksignals Daten eingelesen werden. Am Anfang (steigende Clockflanke ) oder am Ende (fallende Clockflanke) ist, nach den Forderungen oben, der ungünstigste Zeitpunkt, gerade wenn sich die Daten ändern dürfen abzutasten. Wenn nur latched wird, also nicht mit einer Flanke, dann würde das bedeuten, daß mit der fallenden Flanke des Clocksignals im Empfangslatch, die Daten eingefroren werden. Das würde bedeuten, dass die Daten auch noch nach der fallenden Flanke eine gewisse Zeit stabil sein müssen. Das wird durch SDADEL gewährleistet. https://www.dict.cc/englisch-deutsch/latched.html https://de.m.wikipedia.org/wiki/Latch
GEKU schrieb: > Das letzte Bildschirmfoto sagt nicht aus, wann die Daten übernommen > wird. Eben, das ist ja der springende Punkt, den ich diskutieren möchte. Weder in der Spec von NXP noch im Referenzhandbuch von STM finde ich eine klare Info dazu. > bedeutet nur, dass sich die Daten während der Clock HIGH > ist nicht ändern dürfen. > Wobei dies in der Praxis nicht erfüllbar ist. > Es schließt nicht aus, dass innerhalb des Clocksignals Daten > eingelesen werden. Danke, ich wusste nicht, wie ich diesen Knackpunkt so deutlich formulieren kann.
Stefanus F. schrieb: > Wir wissen mehr als im Referenzhandbuch steht, aber wir verraten es dir > nicht. Beim genauen Abtastalgorithmus kocht ein jeder Hersteller sein eigenes Süppchen, zumal glaube ich Philips ein Patent auf das Verfahren hat. So hat jeder eine andere Strategie, was den genauen Abtastzeitpunkt und Mehrfachabtastung betrifft.
Bleibt nichts anders übrig, als einen Testauf mit dem Bus durchzuführen, Daten am Salve zurückzuspiegeln und die Bit Fehlerrate zu messen. Diese sollt, wenn Daten ungesichert übertragen werden Null mit einem entsprechenden Sicherheitsabstand, was Störungen und Bauteiltoleranzen betrifft , sein. Dabei sollten Filter am Bus und Timing mit SCLDEL und SDADEL optimiert werden. Mit ein einen Oszilloskop zu messen reicht leider nicht aus, da der reale Abtastzeitpunkt nicht bekannt ist. Die schon erwähnte Mehrfachabtastung hilft bei der Filterung von Störungen, aber nicht bei einem falschen Timing.
GEKU schrieb: > Wobei dies in der Praxis nicht erfüllbar ist. Sehe ich eigentlich nicht so. Wenn ich die Spec richtig lese, darf sich SDA frühestens 0ns nach der LOW-Flanke und spätestens 250ns vor der High-Flanke ändern. Das scheint mir eindeutig. Der Master erzeugt die Low-Flanke von SCL. Die Zeit > 0 kann er mühelos enhalten. Schreibt der Slave, muß er erstmal die Low-Flanke erkennen, das dauert länger als 0ns und auch er kann die Bedingung einhalten. Und am Ende kann, wer auch immer schreibt, SCL noch mindestens 250ns Low halten. Damit jedes Flip-Flop, das eine Setupzeit < 250ns hat, die Daten mit der High-Flanke fangen. Ein µC kann einfach bei High lesen, und solange er die High-Zeit der Geschwindigkeitsklasse einhält, auch mehrfach. MfG Klaus
Angehängte Dateien:
-
421300.jpg
8,4 KB
Klaus schrieb: > Wenn ich die Spec richtig lese, darf sich SDA frühestens 0ns nach der > LOW-Flanke und spätestens 250ns vor der High-Flanke ändern. Das scheint > mir eindeutig. "The Data on the SDA line must be stable during the HIGH Periode of the clock" steht doch im Widerspruch zu "darf sich SDA .... und spätestens 250ns vor der High-Flanke ändern", oder? Die Zeit während der Clock auf HIGH-Pegel ist, ist doch kürzer als die Zeit von spätestens 250ns vor der High-Flanke bis zur Low-Flanke. Es widerspricht auch zum Diagramm im Dateianhang.
Angehängte Dateien:
-
Selection_003.png
6,6 KB
GEKU schrieb: > "The Data on the SDA line must be stable during the > HIGH Periode of the clock" > > steht doch im Widerspruch zu "darf sich SDA .... und spätestens 250ns > vor der High-Flanke ändern", oder? Ein Bild statt Text. Die Zeiten: THD min 0ns, TSU min 250ns SDA wechselt nur, wenn SCL Low. MfG Klaus
GEKU schrieb: > The Data on the SDA line must be stable during the > HIGH Periode of the clock Habe ich bezweifelt. Danke für das Diagramm. Besser: The data on the SDA line must be stable 250ns before the rising to falling clock edge.
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.