Einen schönen guten Morgen zusammen:
ich habe eine Frage zum I2C Bus.
Da ja viele Sensoren mit diesem Bus ausgestattet sind, habe ich hier gepostet.
Meine Idee war folgende:
Da sich mehrere Chips auf dem Bus befinden können, wollte ich nach einem Reset
den Bus mit "allen" Adressen scannen, um festzustellen welche Adressen bzw. Chips ansprechbar sind.
1.Dazu sende ich lediglich eine Startcondition
2.dann das Adressbyte mit dem R/W Bit (READ=High)
3.und dann wieder die Stop Condition
Das 9te Bit nach dem Adressbyte ist das Ack oder Nack vom Slave.
Bekomme ich ein Ack, weis ich, dass sich die Adresse bzw. der Chip auf dem Bus
befindet und ansprechbar ist.
Das habe ich dann gleich mal ausprobiert und das klappte wunderbar.
Dann habe ich einen Barometer Chip vom Type BMP180 an den Bus gehangen
Er reagierte auch korrekt mit einem ACK, aber dann hielt er die SDA Leitung auf Low.
Auch nachdem ich die Stop Condition gesetzt habe, blieb die Datenleitung Low.
Der Bus ist damit komplett blockiert.
Dann habe ich im Adressbyte das R/W Bit auf WRITE=Low gesetzt
und den Versuch wiederholt.
Nun funktioniert es korrekt: Slave sendet sein Ack und
die Datenleitung geht wieder auf High, der Bus ist wieder frei.
Also zurück und wieder mit Read probiert.
So hatte ich endlich mal die Gelegenheit "gezielt" zu testen
wie ich bei Fehlern den Bus zurücksetzten kann.
Ich habe bei einem Fehler (Datenleitung bleibt Low)
nun auf Portmode umgeschaltet und einzelne Clocks erzeugt.
Nach 3 oder 8 Clocks gaben die Chips den Bus wieder frei.
Diese Problem wunderte mich jetzt und ich habe diverse I2C Chips
ausprobiert wie sie sich verhalten.
#define ADXL345_ADDRESS 0x53 // OKAY Accelerometer Beschleunigung
#define L3G4200_ADDRESS 0x69 // OKAY Gyroskop Drehraten
#define HMC5883_ADDRESS 0x1E // OKAY Kompas/Magnetometer
#define BMP180_ADDRESS 0x77 // Problem Barometer problem bei Read dann 8 clocks
#define BMP280_ADDRESS 0x76 // Problem Barometer problem bei raed dann 8 clocks
#define ADS1110_ADDRESS 0x48 // Problem AD Converter problem bei raed dann 8 clocks
#define MPU9250_ADDRESS 0x68 // OKAY wenn AD= auf Masse liegt, sonst 0x69
#define MPU6050_ADDRESS 0x68 // OKAY wenn AD0 = Low sonst 0x69
#define PCA9685_LED_ALL 0x70 // Problem bei read dann 3 Clock
Jetzt kommt meine Frage:
Muss nach einer Stop Condition nicht der Bus generell vom Slave freigegeben werden ?
Und warum verhalten sich nur einige Chips derart und dann auch nur im Read Modus ?
Ich hatte die Idee, dass es eventuell durch den 10 Bit Adressmodus wäre
und manche Chips halt ein 2tes Byte benötigen für die Adresse
aber das müsste dann bei Read und bei Write identisch sein,
der Fehler tritt aber nur bei Read auf.
Achja, zur Info:
Ich habe bei den Versuch generell nur EINEN Chip am Bus gehabt um das Verhalten zu prüfen.
Die beiden Pullups sind natürlich dran. 3K3 an 3,3V
Also solange man mit Write arbeitet scheint es ein gute Methode zu sein
um den Bus bzw. die angeschlossenen Slaves zu prüfen.
Sollte der Bus tatsächlich mal blockiert werden, wird ja generell empfolen
9 Clocks zu erzeugen.
Ich könnte natürlichh auch generell noch ein Byte einlesen, dann müsste es auch immer funktionieren bei Read
das probiere ich grade.....
Jo, das scheint sich zu bestätigen.
Fazit: Erst mich anquatschen und dann nix von mir wollen mögen einige Chips nicht und reagieren erbost mit Blockade
Vielleicht habt Ihr dazu etwas Information für mich.
Siro
Zitieren
Lesezeichen