Ich habe ein Problem damit, dass LPC2148 mit dem SRF10-Sensor funktioniert. LPC ist ein 3,3-V-Gerät mit 5-V-kompatiblem i2c (das behauptet zumindest die Benutzerdokumentation). Auf der anderen Seite befindet sich das SRF10-Gerät mit 5 V. Ich habe es mit beiden Pegeln als Pull-up-Lvl versucht, die mit einem 4,7-k-Widerstand verbunden sind (ich habe 3 Geräte in derselben Leitung, also habe ich einen Widerstand mit höherem Wert verwendet).
Seltsam ist, dass es manchmal den Wert richtig liest, aber keine Werte aus 2 Registern liest ... Grundsätzlich funktioniert es nicht.
Nun, was an diesem Bild seltsam ist, ist, dass der Logik-Level auf SDA standardmäßig 0 ist und 1 sein sollte. Das bedeutet, dass Pull-up seine Arbeit nicht gut macht? Könnte das mit logischen Lvl-Unterschieden zwischen uc und slave zusammenhängen?
EDIT:01.03
Hier ist meine Implementierung des Zustands 0x50, a_chn ist i2c0 oder i2c1
void slaveDataReceived (uint8_t a_chn)
{
uint8_t k;
volatile unsigned char *i2cConClear;
volatile unsigned char *i2cConSet;
volatile unsigned char *i2cData;
if (a_chn == 1) {
i2cData = (volatile unsigned char *)(0xE005C008);
i2cConClear = (volatile unsigned char *)(0xE005C018);
i2cConSet = (volatile unsigned char *)(0xE005C000);
}
else {
i2cData = (volatile unsigned char *)(0xE001C008);
i2cConClear = (volatile unsigned char *)(0xE001C018);
i2cConSet = (volatile unsigned char *)(0xE001C000);
}
k = *i2cData;
appendToDataBuffer (a_chn, k);
if (i2cDataRcv[a_chn] == i2cDataHead[a_chn]){
I2CMasterState[a_chn] = I2C_IDLE;
*i2cConSet = I2CON_SET_STO;
*i2cConClear = I2CON_CLR_AAC;
}
else {
*i2cConSet = I2CON_SET_AA;
}
*i2cConClear = I2CON_CLR_SIC;
}
Ich sehe gültige Start- und Neustartbedingungen in Ihrer Wellenform, daher glaube ich nicht, dass SDA die "falsche Polarität" ist. Die gültige Startbedingung liegt vor dem Schreiben von 0xC0 (gekennzeichnet durch den ersten grünen Punkt in der Aufnahme) und der gültige Neustart ist der zweite grüne Punkt (vor 0xC1). Die Tatsache, dass SDA niedrig bleibt, nachdem der Master den Slave bestätigt hat, sollte kein Problem sein, solange der Master es vor der nächsten steigenden Flanke von SCL freigibt.
Ein Problem könnte die Größe der Klimmzüge sein. Wenn Sie versuchen, schneller als 100 kHz zu arbeiten, benötigen Sie möglicherweise steifere Klimmzüge, um sicherzustellen, dass die Kanten scharf sind.
Ein weiteres Problem besteht darin, dass der Master das letzte erwartete gelesene Byte NACKEN sollte, selbst wenn es sich um gültige Daten handelt, da viele Slaves ein NACK erwarten, bevor sie zulassen, dass eine gültige Stoppbedingung durchkommt. Für Ihre Einzelbyte-Lesevorgänge sollte der Master das Datenbyte NACKEN. Für die 16-Bit-Register sollte das erste Byte ACK und das zweite NACK sein. Ich habe einige Slave-Geräte gesehen, die den Bus aufgehängt haben oder eine Fehlfunktion hatten, wenn der letzte Lesevorgang nicht durch ein NACK "beendet" wurde.
*i2cConSet = I2CON_SET_STO;
fraglichen Post aus dem Code entfernt. All diese oder einige dieser kürzlichen Änderungen im Code haben dazu geführt, dass i2c jetzt funktioniert. Jetzt muss ich analysieren, was genau die Probleme verursacht hat, indem ich den alten Code Zeile für Zeile neu aktiviert habe.
Passant
Gossamer
Passant
Gossamer
Gustavo Litowski