Ich verwende den C18-Compiler und habe gelernt, dass die Acknowledge-Polling-Funktion erheblich dazu beiträgt, die Schreibzeit zu verkürzen, dh die feste Verzögerung bei herkömmlichen Methoden zu beseitigen. Nun, ich verwende EEPROM 24LC256 und es gibt eine Funktion zum Bestätigungsabruf darin.
Ich habe einen Code für Acknowledge Polling geschrieben.
long eewrite_p( int address,int msg)
{
int my_response;
int i;
i2c_init();
//if(!i2c_initialised) return '\0';
StartI2C(); //Send the Start Bit
Nop();
IdleI2C(); //Wait to complete
Nop();
WriteI2C( 0xA0 );
Nop();
IdleI2C();
//Wait to complete
WriteI2C( address>>8);
Nop();
IdleI2C();
WriteI2C(address&0xFF);
Nop();
IdleI2C();
my_response = WriteI2C(msg);
Nop();
AckI2C();
IdleI2C();
StopI2C(); //Send the Stop condition
Nop();
IdleI2C(); //Wait to complete
}
Nun, das ist ein alter Code ohne Polling-Bestätigung. Ich habe gelesen, dass die Bestätigungsabfrage für jedes Steuerbyte / Daten- / Adressbyte erforderlich ist. Korrigiere mich, wenn ich falsch liege. Müssen wir für jedes in den Chip geschriebene Byte eine Bestätigungsabfrage durchführen?
Ein weiterer Zweifel, den ich habe, ist, ob wir nach einer Bestätigung suchen und wenn diese nicht empfangen wird, dann heißt es in den Datenblatt-/App-Notizen warten, bis die Bestätigung empfangen wird. Andernfalls wird der Code abgefragt, bis eine Bestätigung empfangen wird.
Nun, zuvor habe ich versucht, die EE-Geräteadresse zu schreiben, eine Funktion nach der anderen, ohne Verzögerung dazwischen, und ich vertraue darauf, dass es nicht gut geschrieben worden sein muss. Wie kann ich den aktuellen Code ändern, um die Bestätigungsabfrage zu nutzen?
Wenn ein typisches EEPROM das erste Byte nach einer Startbedingung quittiert, gibt es keine definierte Ereignisfolge, über die es jedes andere Byte, das gemäß den Spezifikationen gesendet wird, nicht quittieren würde. Das Testen auf Bestätigung nach nachfolgenden Bytes kann dem Code helfen, zu erkennen, dass etwas schief gelaufen ist, wenn ein Fehler auftritt und die Dinge "nicht synchron" macht, aber es hilft möglicherweise nichts, es sei denn, der Code kann etwas Nützliches als Antwort tun.
In meinem eigenen Code ist mein normaler Ansatz, I2C mit Routinen zu bitbangen:
bit I2C_StartRead(unsigned char address);
bit I2C_StartWrite(unsigned char address);
void I2C_PutByte(unsigned char dat);
unsigned char I2C_GetByte(void);
void I2C_Stop();
I2C_StartRead und I2C_StartWrite fahren den Takt hoch, geben SDA frei und, wenn die Daten nicht hoch sind, fahren den Takt niedrig und dann hoch, bis er es ist. Sie werden dann das Adressbyte austakten und den Taktdraht für das folgende ACK auf High setzen und den Zustand von SDA prüfen, wobei 1 zurückgegeben wird, wenn SDA aktiviert ist, und 0, wenn dies nicht der Fall ist.
Bit-Bang-I2C mag schwierig erscheinen, aber ich fand es im Allgemeinen einfacher als die Verwendung der Master-I2C-Hardware. Unter anderem enthält die Master-I2C-Hardware "Byte abrufen und ACK" oder "Byte abrufen und NAK"-Funktionen, die effektiv erfordern, dass der Code weiß, bevor er ein Byte liest, ob er ein weiteres Byte danach haben möchte. Mit einer Bit-Bang-I2C-Implementierung kann man die I2C_GetByte-Routine nach dem Lesen des letzten Datenbits verlassen, aber ohne es zu ACKen oder NAKen, und dann den nächsten Aufruf von GetByte das vorherige Byte bestätigen lassen (wenn es keinen nächsten I2C_GetByte-Aufruf gibt vor dem nächsten I2C_StartRead oder I2C_Stop geben die letzten beiden Aufrufe ein NAK aus).
Anfänger91