XMega: Auswirkung der Systemtaktgenauigkeit auf i2c-Taktrate

[noips (Gast)]

Hallo,

ich arbeite zum ersten Mal mit I²C (XMega 128) und stoße auf das 
Problem, dass der Clock SCL bei ca. 320 kHz liegt obwohl ich ihn für 
400kHz konfiguriert habe.

Zuerst mal eine Frage zur Taktrate bei I²C:
Verstehe ich es richtig, dass mit der I²C-Taktrate die Frequenz von SCL 
gemeint ist? Also man misst die Periode des SCL und bildet den Kehrwert 
davon.


Und nun die eigentliche Frage:
Der XMega läuft mit dem internen 32MHz Oszillator und der Takt (auf 
einen Pin herausgeführt) liegt (mit einem Frequenzzähler gemessen) bei 
ca. 32,6 MHz. Kann es sein, dass diese Abweichung des Systemtakts (0,6 
MHz) zu einem SCL-Takt von 320kHz statt 400kHz führt?

Danke schon mal für jede Antwort!!!

[Peter D. (peda)]

Der Takt ist bei I2C immer eine Maximalangabe.
Er kann verlangsamt werden durch die Slaves, Leitungskapazität und 
Programmlaufzeit.


Peter

[noips (Gast)]

Danke für die schnelle Antwort!!!

Ist es (mal abgesehen von Clock Stretching durch Slaves) nicht so, dass 
das TWI-Modul zur Erzeugung von SCL den Systemtakt einfach runterteilt 
und dass der SCL-Takt sozusagen fest an den Systemtakt gekoppelt ist (im 
bestimmten Verhältnis natürlich)? Wenn das so ist, wie kann dann die 
Leitungskapazität den Takt verlangsammen? Ich würde dann erwarten, dass 
durch Leitungskapazität der Pegel der Pulse nicht ganz an Vdd kommt.

Wie kann Programmlaufzeit den Takt beeinflussen? Ich könnte mir 
vorstellen dass der Abstand zwischen den einzelnen I2C-Transaktionen 
durch Programmlaufzeit beeinflusst wird, aber nicht der SCL-Takt selbst. 
Sehe ich da was falsch?

[Εrnst B. (ernst)]

Wie hast du den Takt gemessen? Einfach Frequenzzähler an SCL?

Bedenke, das SCL immer nur während der Übertragung getaktet ist, 
"zwischen den Bytes" liegt SCL wieder auf High.
=> der Frequenzzähler zeigt zuwenig an.

[noips (Gast)]

>Wie hast du den Takt gemessen? Einfach Frequenzzähler an SCL?

Nein! Mit Frequenzzähler habe ich den Systemtakt gemessen. Den SCL-Takt 
natürlich mit einem Oszi wie oben beschrieben, die Periode abgelesen und 
den Kehrwert dazu gemacht.

[Mike R. (thesealion)]

Messen kannst du den Takt nur mit einem Skope, die Programmlaufzeit 
beeinflußt den Takt eines Bytes überhaupt nicht und wenn du dir das 
Datenblatt ansiehst, wirst du sehen, das die Frequnez durch einen 
simplen Vorteiler gewonnen wird. Es kann also sein, das du die 400kHz 
nie treffen kannst, je nachdem welchen Systemtakt du hast

[noips (Gast)]

Weiß noch jemand, woran das Problem liegen könnte?

[Εrnst B. (ernst)]

Auf welchen Wert setzt du TWMBR?

[noips (Gast)]

Ich berechne den Wert mit der Formel im Datenblatt im Abschnitt "BAUD - 
TWI Baud Rate Register":

32 000 000  / (2 * 400 000) - 5  = 35

Habe auch im Debug-Mode geschaut, wird tatsächlich auf den Wert gesetzt.

[Εrnst B. (ernst)]

Jo, auf die 35 bin ich auch gekommen, für die von dir gemessenen 320kHz 
müsste der Wert schon auf so 45 stehen...

Messfehler oder Chip/Datenblatt-Fehler?
Sagen die Atmel-Erratas da was zu?

[Thomas Kindler (Gast)]

> Ist es (mal abgesehen von Clock Stretching durch Slaves) nicht so, dass
> das TWI-Modul zur Erzeugung von SCL den Systemtakt einfach runterteilt
> und dass der SCL-Takt sozusagen fest an den Systemtakt gekoppelt ist (im
> bestimmten Verhältnis natürlich)?

Ja, 400kHz wird durch runterteilen erzeugt, und gibt den I2C-Maximaltakt 
vor.

> Wenn das so ist, wie kann dann die Leitungskapazität den Takt
> verlangsammen?

Beim Wechsel SCL low->high muss der Controller warten, bis der 
high-pegel erreicht ist. Je nach Leitungskapazität und Pull-Up kann das 
mehr oder weniger lange dauern.