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!!!
Der Takt ist bei I2C immer eine Maximalangabe. Er kann verlangsamt werden durch die Slaves, Leitungskapazität und Programmlaufzeit. Peter
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?
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.
>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.
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
Weiß noch jemand, woran das Problem liegen könnte?
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.
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?
> 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.
Bitte 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.