Multiplexor ESP8266 I2C

EDITAR: ejecuté un programa de escaneo de bus i2c y detectó un dispositivo en 0x70 (el mux). Conecté el dispositivo con el que intento conectarme directamente al bus i2c, ejecuté este código y funcionó exactamente como se esperaba. Pero aún cuando ejecuto este código con el dispositivo conectado a uno de los canales mux, no funciona. ¡Estoy perplejo!


Estoy tratando de controlar un dispositivo I²C a través de un multiplexor en un ESP8266. A continuación se muestra el circuito que estoy usando y el código. Este código exacto funciona si cambio el dispositivo para que se conecte directamente a SDA y SCL (sin pasar por el multiplexor). Desafortunadamente, si se conecta a través del multiplexor, el código muestra "No se encontró TCS34725". He probado esto en dos tableros distintos con los mismos resultados en ambos.

Hoja de datos del multiplexor

Huella de PCB

El reinicio (N $ 5) se eleva a 3.3v a través de una resistencia de 10k.

símbolo de hoja de especificaciones

#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();  
}

¿Alguna idea de por qué esto no funciona?

¿Qué ha hecho para verificar la actividad del bus I2C aguas abajo? ¿Ha mirado con un analizador lógico basado en USB de alcance o presupuesto? ¿Tiene pullups en los buses I2C ascendentes y descendentes? ¿Has podido verificar que estás comandando el mux? ¿Has probado con otros canales?
No lo he comprobado con un alcance, pero lo haré ahora. Sí, hay pullups tanto en el bus esp i2c como en sc6/sd6. He probado otros canales, mismo resultado. No he podido verificar que estoy comandando el multiplexor. ¿Cómo me recomendaría que hiciera eso?
De la hoja de datos mux: "el reinicio de encendido anula la selección de todos los canales". Entonces, a menos que se haya comunicado con el mux y le haya dicho que seleccione el canal al que conectó su TCS34725, no sucederá nada.
¿Mi función tcaselect no hace eso (seleccionar el canal apropiado)?
¿Quizás intente conectar todos los canales juntos y conecte el dispositivo descendente a eso, para descartar la posibilidad de que esté seleccionando el canal incorrecto? (¿O intente cambiar temporalmente tcaselect para llamar a Wire.write (0xFF) para seleccionar todos los canales?) Sin embargo, no haga ambas cosas. :-)

Respuestas (2)

Lo primero que debe verificar es que el pin !RESET del mux se levante correctamente por la resistencia y no se mantenga bajo por la MCU maestra. Y me refiero a verificar realmente no solo asumir que está bien porque se supone que debe ser así. El mux aún puede ACK en el reinicio cuando escanea el bus, pero no seleccionará el canal de salida en el comando.

Si ese no es el caso, aquí hay un procedimiento simple para diagnosticar el problema. Necesitaría otro dispositivo I2C "B", por ejemplo VL53L0X que ha mencionado. Ya ha realizado algunos de los pasos a continuación, por lo que puede omitirlos. También asegúrese de que los dispositivos con identificaciones seleccionables siempre estén cableados de manera idéntica en las pruebas.

  1. Intente enviar algunas selecciones aleatorias de canales a Mux y luego lea el registro de control. Si no está recuperando los valores que envió --> algo anda mal con Mux.
  2. Conecte A (TCS34725) y B directamente al bus I2C principal y ejecute el escáner. Deberías ver 3 dispositivos.
  3. Verifique que A y B funcionen correctamente enviando algunos comandos y leyendo las respuestas. Si A no funciona --> algo anda mal con la biblioteca.
  4. Conecte A y B al canal Mux y escanee el bus después de seleccionar este canal. Deberías ver 3 dispositivos. Además, si puede omitir el Mux y escanear el canal en sí, debería ver 2 dispositivos.
  5. Si no ve los 3, intente enviar FF a Mux (seleccione todos los canales). Si puede verlos ahora --> el cableado del canal está desordenado en la PCB
  6. Intente comunicarse con A y B después de seleccionar el canal correcto. Si B funciona y A no --> hay algún tipo de incompatibilidad entre TCS34725 y Mux.
  7. Intente agregar un retraso entre el comando de selección de canal y la siguiente comunicación con los dispositivos. No debería necesitarlo, pero no está de más comprobarlo.
  8. Si ni A ni B funcionan en las pruebas anteriores cuando están conectados a Mux --> algo anda mal con Mux.

Puede diagnosticar aún más comparando voltajes y pull-ups en el bus principal y en los canales Mux de salida. También revise las hojas de datos y vuelva a verificar las velocidades admitidas y vuelva a calcular los valores de resistencia pull-up requeridos para los canales Mux (dependen de la velocidad y la capacitancia del bus).

el paso 1 fue un error en ambos dispositivos: probé un tercero y todo funcionó (por casualidad, ambos estaban dañados o tal vez no se soldaron correctamente en la placa, aunque no había puentes)... gracias por los consejos de diagnóstico

Hay algo que debes revisar cuidadosamente. En el mundo I2C y SMBus siempre ha existido el uso confuso de una combinación de valores de dirección de 7 bits y valores de dirección de esclavo de 8 bits. La hoja de datos del TCA9548A indica la dirección del esclavo I2C para la parte MUX como una dirección de 7 bits que reside en los 7 bits superiores del byte de dirección transmitido.

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí

En su código, ha establecido la definición de TCAADDR en 0x70, lo que será correcto para la instancia en la que ha vinculado los pines A0, A1 y A2 en la parte MUX a GND. Tenga en cuenta que este valor 0x70 es una dirección esclava de 7 bits.

Muchas bibliotecas de software para comunicarse en I2C y SMBus usarán una representación de 8 bits para la dirección esclava y luego simplemente o en un 0x01 al bit bajo para una operación de tipo LECTURA. Si el código de la biblioteca usa una entrada de dirección esclava de 7 bits, el código debe cambiar ese valor un lugar a la izquierda para que el byte que se envíe sea correcto.

Entonces, la verificación que debe hacer es cómo el código de la biblioteca trata la dirección esclava. Si funciona en el modo de 8 bits, deberá configurar su TCAADDR en 0xE0.

No te sientas mal si este es el problema que te ha atrapado aquí. Innumerables personas han sido mordidas por este problema.

Gracias por la respuesta; lamentablemente, sin embargo, verifiqué y la biblioteca TCS34725 que estoy usando usa una representación de 7 bits.
Es posible que las funciones rudimentarias de la biblioteca tengan algunas características codificadas que estén totalmente adaptadas al TCS34725 y estén provocando que las transacciones bis no sean compatibles con el TCA9548A.
Hmm, ok, lo probé con un dispositivo diferente (vl53l0x) y tampoco funciona con ese, aunque puede comunicarse con ese dispositivo cuando está conectado al bus i2c y reconoce el mux ...