Schwankungen der I2C-Taktfrequenz

Ich verwende ein I2C-Peripheriegerät in der PIC18-Serie, das mit 100 kHz läuft, und ich habe Pull-up-Widerstände von 4,7 k verwendet Ω dabei. Ich habe dann einen Code mit kontinuierlichem Schreibvorgang von EEPROM geladen und die SCL-Zeile im Bereich angesehen. Die SCL-Leitung bleibt nicht immer bei 100 kHz. Es variiert von 100 kHz und springt manchmal von 24 kHz auf 50 kHz und erreicht bis zu 100 kHz ... geht nie darüber hinaus.

Was sollte getan werden, um die SCL-Leitung bei 100 kHz stabil zu machen? Wird der Pullup-Widerstand den Verlust ausgleichen?

Was macht das Mikro sonst noch? Ist der I2C Interrupt-gesteuert? Gibt es andere Interrupts, die es überschreiben können? Wenn nicht, gibt es Funktionen, die zu einer Verzögerung der I2C-Funktion führen könnten (z. B. einige Funktionen, deren Rückkehr manchmal lange dauert)?
Welches I2C-Peripheriegerät? Welche Probleme werden durch die "Instabilität" verursacht?
Sie schreiben ständig ins EEPROM? Überprüfen Sie das EEPROM-Datenblatt und sehen Sie, dass es eine begrenzte Anzahl von lebenslangen Schreibvorgängen hat. Wenn Sie es kontinuierlich schreiben, nutzt es sich schnell ab.
Nun, der Slave ist gerade getrennt und ich habe nur die Sendesignale von SCL überprüft, ob die Uhr stabil ist oder nicht.
Ich verwende den Controller pic18f26j50.
Wie misst du die Taktfrequenz? Wird die gemessene Frequenz über mehrere Bytes gemittelt? Oder können Sie auf dem Oszilloskop sehen, dass einige Bytes mit einem Takt von 100 kHz gesendet werden, während andere Bytes mit niedrigeren Taktfrequenzen übertragen werden?
Ja..ich benutze Techtronix-Oszilloskop.Ich betrachte den Puls in diesem Instrument.Wird die Taktdehnung Probleme verursachen? Anstatt langsamer zu werden.
Kommt darauf an, was man beobachtet. Die Taktdehnung sollte nur die Übertragung des nächsten Bytes verzögern. Aber jedes Byte sollte mit der normalen Taktfrequenz übertragen werden, also sollten Sie dann 100kHz einhalten. Vielleicht können Sie ein Bild des Zielfernrohrs hinzufügen, damit wir sehen, was Sie beobachten?
Legen Sie eine Verzögerung nach der I2C-Initialisierung fest. besonders nach dem Zuweisen des Werts von SSPADD.

Antworten (1)

Clock-Stretching ist bei I2C erlaubt.

Dies könnte der Grund für das Verhalten sein. Was passiert, wenn Sie Daten mit beispielsweise 20 kHz übertragen - sehen Sie auch solche verlängerten Impulse oder verschwinden sie?

Nun, ich habe das nicht versucht, ich habe nur versucht, Pull-Up-Widerstände anzuschließen und die SCL-Leitung überprüft. Ich habe auch nicht den Eeprom-Chip angeschlossen.
Läuft noch ein anderer Code oder nur der I2C-Code? Könnte es sein, dass Sie etwas an UART ausgeben oder einige Berechnungen im Hintergrund durchführen?
Nein. Nur I2c-Schreiben ist im Fluss
L.Hi..ich habe einige Experimente mit dem Oszilloskop gemacht und der Chip funktioniert gut im Bereich, als ich 20 kHz gab. Ich sehe kleine Abweichungen zwischen 19 und 17 kHz dazwischen. Als ich 50 kHz gab, zeigt es Sprünge zwischen 34 kHz und 49 kHz. Und wenn ich auf 100 kHz zurückkomme, springt es zwischen 54 und 100 kHz.
Nun, nur ein Gerät (Slave) ist jetzt am Bus angeschlossen. Könnte das an der Taktdehnung liegen.
Setzen Sie es auf Reset, Sie sollten die Ergebnisse sofort sehen. Sie können auch Folgendes tun, wenn Sie denken, dass es Ihr Code ist: Schalten Sie einen Pin um, unmittelbar bevor Sie den I2C-Schreibvorgang starten. Wenn es fertig ist, schalten Sie diesen Pin erneut um. Stellen Sie sicher, dass Interrupts deaktiviert sind (mit Ausnahme derjenigen, die Sie für I2C benötigen, falls vorhanden).
Verwenden Sie das Hardware-I2C-Modul oder eine Softwareimplementierung?
Es ist eine Hardware-Implementierung