I2C-Verzögerung benötigt und c18

Ich verwende I2C und habe hier früher Zweifel an I2C gepostet. Ich verwende PIC-Controller und ihren Compiler C18. Ich habe ihre Bibliotheken verwendet, um eine Funktion zum Schreiben von Daten in EEPROM über I2C zu erstellen, und als ich die SCL-Leitungen überprüft habe, schwankten sie.

Ich habe eine Funktion zum Schreiben in das EEPROM erstellt, aber ich habe Verzögerungen verpasst, da das Datenblatt besagt, dass "mindestens 5 ms Verzögerung für jeden Schreibvorgang in I2C erforderlich sind".

Ich vertraue darauf, dass es die Probleme verursacht. Das Problem ist, dass SCL nicht bei 100 kHz bleibt und zwischen 54 kHz und 100 kHz schwankt, aber nie darüber hinaus. Liegt das daran, dass Steuerbyte, Adresse und Daten zusammen mit der Funktion gesendet werden?

float ee_write_float(unsigned char ee_addr, float f)
{
     void i2c_init(); //initialize I2c
     unsigned char *p = (unsigned char *)&f;
     unsigned char  i;

   for (i = sizeof f; i != 0; --i)
   {
      EEByteWrite(EE_I2C_ADDR, ee_addr++, *p++);
   }

}

Wie wichtig ist das Dela für I2C-Schreiboperationen?

Könnte das die Ursache des Problems sein?

Sollte ich nach der EEByteWrite-Funktion eine Verzögerung setzen, um dies zu kompensieren?

Hinweis: Der SCL wird etwas stabil, nachdem die Baudrate auf 20 kHz reduziert wurde, und schwankt dann zwischen 17 kHz und 19 kHz. Ich würde mich sehr freuen, wenn Sie einen vernünftigen Grund zur Behebung dieses Problems finden würden ... oder wertvolle Vorschläge werden von ganzem Herzen begrüßt.

Ich muss fragen, ob Sie wissen, dass im Datenblatt eine Verzögerung von 5 ms angegeben ist, warum versuchen Sie es nicht? Es ist eine ziemlich lange Verzögerung, und im Moment versuchen Sie wahrscheinlich, über tausend Mal schneller als erlaubt zu schreiben.
Nun, ich versuche, mit 100 kbit/s zu schreiben, aber die scl-Zeile zeigte, wenn sie im Oszilloskop beobachtet wurde, Schwankungen und blieb nie konstant bei 100 kbit/s, wenn ich die obige Funktion in main() ausführte.
Es könnte sich um eine Taktdehnung handeln, wie in einer Antwort auf die andere Frage vorgeschlagen (darüber weiß ich nicht viel), aber Sie benötigen schließlich die Verzögerung von 5 ms, damit sie zuverlässig funktioniert. Sie können immer einen Trigger am Oszilloskop verwenden, um den 100-kbps-Takt auch mit der Verzögerung zu erfassen. Wie misst du die Frequenz? Vielleicht ist es nur Jitter zwischen den übertragenen Bytes.
Ja, ich benutze die Trigger-Taste am Oszilloskop. Nun, die Frequenz wird nur unten angezeigt ... unter dem Oszilloskop. OK..Also kann es ein Jitter zwischen Bytes sein.Nun, ich habe es unter For-Schleife gesetzt..kontinuierlich.
Können Sie die Quelle von EEByteWrite() und vielleicht eine Scope-Trace der Busse posten?
Sie interpretieren Dinge, um zu dem Problem zu gelangen, dass Ihre I2C-Uhr instabil ist. Soweit ich weiß, ist Taktstabilität unter dem I2C-Standard nicht garantiert. Was ist das WIRKLICHE Problem? Unzuverlässige Kommunikation?

Antworten (1)

Bei I2C schaltet die Uhr nur um, wenn es zum Senden oder Empfangen von Daten erforderlich ist. Es besteht keine Notwendigkeit für ein kontinuierliches Taktsignal, daher sollte mit Schwankungen in der beobachteten Frequenz gerechnet werden. Die 100-kHz-Spezifikation ist eher die maximale Taktrate als die durchschnittliche oder kontinuierliche Taktrate.

Nichtflüchtige Speicher wie Flash und EEPROM benötigen eine relativ lange Zeit, um Daten in den Speicher zu schreiben, und 5 ms klingen ungefähr richtig. Sie dürfen nicht versuchen, mehrere Schreibvorgänge auszuführen, ohne diese Verzögerung zwischen ihnen zu berücksichtigen. Aus diesem Grund können Sie unmöglich mehr als 200 Schreibvorgänge pro Sekunde ausführen und trotzdem 5 ms pro Vorgang zulassen.

Sobald alles richtig funktioniert, sollten Sie damit rechnen, alle 5 ms einen Burst von 100-kHz-Taktimpulsen zu sehen.

I2C-Verzögerung benötigt und c18
AntwortenHierDatenschutz-Bestimmungen1y, 0v