ESP8266 I2C-Multiplexer

BEARBEITEN: Ich habe ein i2c-Bus-Scan-Programm ausgeführt und es hat ein Gerät bei 0x70 (dem Mux) erkannt. Ich habe das Gerät, mit dem ich eine Verbindung herstellen möchte, direkt mit dem i2c-Bus verbunden und diesen Code ausgeführt, und es hat genau wie erwartet funktioniert. Aber immer noch, wenn ich diesen Code mit dem an einen der Mux-Kanäle angeschlossenen Gerät ausführe, funktioniert es nicht. Ich bin ratlos!


Ich versuche, ein I²C-Gerät über einen Multiplexer auf einem ESP8266 zu steuern. Unten ist die Schaltung, die ich verwende, und der Code. Dieser genaue Code funktioniert, wenn ich das direkt an SDA und SCL anzuschließende Gerät ändere (unter Umgehung des Multiplexers). Leider gibt der Code bei einer Verbindung über den Multiplexer "No TCS34725 found" aus. Ich habe dies auf zwei verschiedenen Boards mit den gleichen Ergebnissen auf beiden versucht.

Multiplexer-Datenblatt

PCB-Footprint

Reset (N$5) wird über einen 10k-Widerstand auf 3,3 V hochgezogen.

Datenblatt-Symbol

#include <Wire.h>

#include <Adafruit_TCS34725.h>

#define TCAADDR 0x70

uint16_t clear, red, green, blue;

Adafruit_TCS34725 tcs = Adafruit_TCS34725(TCS34725_INTEGRATIONTIME_2_4MS, TCS34725_GAIN_1X);

void setup() {

  Wire.begin();
  Serial.begin(115200);
  delay(10);
  Serial.println("\r\n");

   tcaselect(6);
  if (tcs.begin()) {
    Serial.println("Found sensor");
  } else {
    Serial.println("No TCS34725 found ... check your connections");
    while (1); // halt!
  }
}

void tcaselect(uint8_t i) {
  if (i > 7) return;

  Wire.beginTransmission(TCAADDR);
  Wire.write(1 << i);
  Wire.endTransmission();  
}

Irgendwelche Ideen, warum das nicht funktioniert?

Was haben Sie getan, um die Aktivität des Downstream-I2C-Busses zu überprüfen? Haben Sie nach einem Oszilloskop- oder Budget-USB-basierten Logikanalysator gesucht? Haben Sie Pullups sowohl auf den Upstream- als auch auf den Downstream-I2C-Bussen? Konnten Sie überprüfen, ob Sie den Mux befehlen? Hast du andere Kanäle probiert?
Ich habe es nicht mit einem Oszilloskop überprüft, aber ich werde es jetzt tun -- Ja, es gibt Pullups sowohl auf dem esp i2c-Bus als auch auf sc6/sd6. Ich habe andere Sender probiert, gleiches Ergebnis. Konnte nicht überprüfen, ob ich den Multiplexer befehle – wie würden Sie mir das empfehlen?
Aus dem Mux-Datenblatt: "Durch das Zurücksetzen beim Einschalten werden alle Kanäle abgewählt". Wenn Sie also nicht mit dem Mux kommuniziert und ihm gesagt haben, dass er den Kanal auswählen soll, an den Sie Ihren TCS34725 angeschlossen haben, wird nichts passieren.
Tut das nicht meine tcaselect-Funktion (den richtigen Kanal auswählen)?
Vielleicht versuchen Sie, alle Kanäle miteinander zu verbinden und das nachgeschaltete Gerät daran anzuschließen, um auszuschließen, dass Sie den falschen Kanal auswählen? (Oder versuchen Sie vorübergehend, tcaselect so zu ändern, dass Wire.write(0xFF) aufgerufen wird, um alle Kanäle auszuwählen?) Tun Sie jedoch nicht beides. :-)

Antworten (2)

Das erste, was zu überprüfen ist, ist, dass der !RESET-Pin des Mux ordnungsgemäß vom Widerstand hochgezogen und nicht von der Master-MCU niedrig gehalten wird. Und ich meine, wirklich prüfen, nicht einfach davon ausgehen, dass es in Ordnung ist, weil es so sein soll. Der Mux bestätigt möglicherweise immer noch im Reset, wenn Sie den Bus scannen, aber er wählt den Ausgangskanal nicht auf Befehl aus.

Wenn dies nicht der Fall ist, finden Sie hier ein einfaches Verfahren zur Diagnose des Problems. Sie benötigen ein weiteres I2C-Gerät "B", zum Beispiel das von Ihnen erwähnte VL53L0X. Sie haben bereits einige der folgenden Schritte ausgeführt, sodass Sie diese überspringen können. Stellen Sie außerdem sicher, dass Geräte mit wählbaren IDs in den Tests immer identisch verdrahtet sind.

  1. Versuchen Sie, einige zufällige Kanalauswahlen an Mux zu senden und dann das Steuerregister zu lesen . Wenn Sie die gesendeten Werte nicht zurückerhalten --> stimmt etwas mit Mux nicht.
  2. Verbinden Sie A (TCS34725) und B direkt mit dem Haupt-I2C-Bus und führen Sie den Scanner aus. Sie sollten 3 Geräte sehen.
  3. Überprüfen Sie, ob A und B ordnungsgemäß funktionieren, indem Sie einige Befehle senden und Antworten lesen. Wenn A nicht funktioniert -> stimmt etwas mit der Bibliothek nicht.
  4. Verbinden Sie A und B mit dem Mux-Kanal und scannen Sie den Bus, nachdem Sie diesen Kanal ausgewählt haben. Sie sollten 3 Geräte sehen. Auch wenn Sie den Mux umgehen und den Kanal selbst scannen können, sollten Sie 2 Geräte sehen.
  5. Wenn Sie nicht alle 3 sehen, versuchen Sie, FF an Mux zu senden (wählen Sie alle Kanäle aus). Wenn Sie sie jetzt sehen können --> die Kanalverdrahtung auf der Platine ist durcheinander
  6. Versuchen Sie, mit A und B zu kommunizieren, nachdem Sie den richtigen Kanal ausgewählt haben. Wenn B funktioniert und A nicht --> gibt es eine Art Inkompatibilität zwischen TCS34725 und Mux.
  7. Versuchen Sie, eine Verzögerung zwischen dem Kanalauswahlbefehl und der folgenden Kommunikation mit Geräten hinzuzufügen. Sie sollten es nicht brauchen, aber es schadet nicht, es zu überprüfen.
  8. Wenn weder A noch B in den obigen Tests funktionieren, wenn sie mit Mux verbunden sind --> etwas stimmt nicht mit dem Mux.

Sie können weiter diagnostizieren, indem Sie Spannungen und Pull-ups auf dem Hauptbus und den Mux-Ausgangskanälen vergleichen. Gehen Sie auch die Datenblätter durch und überprüfen Sie die unterstützten Geschwindigkeiten erneut und berechnen Sie die erforderlichen Pull-up-Widerstandswerte für Mux-Kanäle neu (sie hängen von Geschwindigkeit und Buskapazität ab).

Schritt 1 war bei beiden Geräten ein Fehler - ich habe ein drittes ausprobiert und alles hat funktioniert (zufälligerweise waren beide schlecht oder vielleicht nicht richtig auf der Platine gelötet, obwohl es keine Brücken gab) ... danke für die Diagnosetipps

Es gibt etwas, das Sie sorgfältig prüfen müssen. In der I2C- und SMBus-Welt gab es schon immer die verwirrende Verwendung einer Mischung aus 7-Bit-Adresswerten und 8-Bit-Slave-Adresswerten. Das Datenblatt des TCA9548A nennt die I2C-Slave-Adresse für den MUX-Teil als 7-Bit-Adresse, die sich in den oberen 7 Bits des übertragenen Adressbytes befindet.

Geben Sie hier die Bildbeschreibung ein

Geben Sie hier die Bildbeschreibung ein

In Ihrem Code haben Sie die Definition für TCAADDR auf 0x70 gesetzt, was für die Instanz richtig ist, dass Sie die A0-, A1- und A2-Pins auf dem MUX-Teil alle mit GND verbunden haben. Denken Sie daran, dass dieser 0x70-Wert eine 7-Bit-Slave-Adresse ist.

Viele Softwarebibliotheken für die Kommunikation auf I2C und SMBus verwenden eine 8-Bit-Darstellung für die Slave-Adresse und dann einfach oder in einem 0x01 zum niedrigen Bit für eine Operation vom Typ READ. Wenn der Bibliothekscode einen 7-Bit-Slave-Adresseneingang verwendet, muss der Code diesen Wert um eine Stelle nach links verschieben, damit das auszusendende Byte korrekt ist.

Sie müssen also überprüfen, wie der Bibliothekscode die Slave-Adresse behandelt. Wenn es im 8-Bit-Modus funktioniert, müssen Sie Ihre TCAADDR auf 0xE0 setzen.

Fühlen Sie sich nicht schlecht, wenn dies das Problem ist, das Sie hier eingeholt hat. Unzählige Personen wurden von diesem Problem gebissen.

Vielen Dank für die Antwort - leider habe ich es überprüft und die TCS34725-Bibliothek, die ich verwende, verwendet eine 7-Bit-Darstellung.
Es ist möglich, dass die rudimentären Funktionen in der Bibliothek einige hartcodierte Merkmale aufweisen, die vollständig auf den TCS34725 ausgerichtet sind und dazu führen, dass die bis-Transaktionen nicht mit dem TCA9548A kompatibel sind.
Hmm ok, also habe ich es mit einem anderen Gerät (vl53l0x) versucht und es funktioniert auch nicht mit diesem, obwohl es mit diesem Gerät kommunizieren kann, wenn es an den i2c-Bus angeschlossen ist und es den Mux erkennt ...