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.
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
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.
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.htmlhttps://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
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.
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.
