ESP8266 Multiplexor I2C

1

EDITAR: Corrí un programa de escaneo de bus i2c y detecté un dispositivo en 0x70 (el mux). Conecté el dispositivo con el que estoy intentando conectar 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 intentando 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 intentado esto en dos tableros distintos con los mismos resultados en ambos.

Hoja de datos del multiplexor

Elreinicio(N$5)sellevaa3.3vatravésdeunaresistenciade10k.

#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 sobre por qué esto no funciona?

    
pregunta Murey Tasroc

2 respuestas

1

Lo primero que hay que verificar es que: el PUNTO DE REINICIACIÓN del mux se retira correctamente con la resistencia y no se mantiene bajo con la MCU maestra. Y quiero decir realmente verificar no solo asumir que está bien porque se supone que debe ser así. El mux todavía podría ACK en 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 haya mencionado. Ya has realizado algunos de los pasos a continuación, por lo que puedes omitirlos. También asegúrese de que los dispositivos con ID seleccionables siempre estén conectados de manera idéntica en las pruebas.

  1. Intente enviar algunas selecciones de canales al azar a Mux y luego leyendo el registro de control. Si no recupera los valores que envía - > algo malo 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 malo 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, debería ver 2 dispositivos.
  5. Si no ve los 3, intente enviar FF a Mux (seleccione todos los canales). Si puedes verlos ahora - > el cableado del canal está desordenado en PCB
  6. Intenta comunicarte 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 demora entre el comando de selección de canal y seguir la comunicación con los dispositivos. No deberías necesitarlo, pero no está mal para comprobarlo.
  8. Si ni A ni B funcionan en las pruebas anteriores cuando están conectados a Mux - > algo malo con el Mux.

Puede realizar un diagnóstico adicional comparando voltajes y flexiones 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 de pull-up requeridos para los canales Mux (dependen de la velocidad y la capacidad del bus).

    
respondido por el Maple
1

Hay algo que necesitas revisar cuidadosamente. En el mundo I2C y SMBus siempre ha habido un 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 para el TCA9548A llama a 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.

En su código, estableció la definición de TCAADDR en 0x70, que será correcta para la instancia en la que haya vinculado los pines A0, A1 y A2 en la parte MUX, todo a GND. Tenga en cuenta que este valor 0x70 es una dirección de esclavo 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 del esclavo y luego simplemente o en un 0x01 al bit bajo para una operación de tipo LECTURA. Si el código de la biblioteca utiliza una entrada de dirección de esclavo de 7 bits, el código debe desplazar ese valor un lugar hacia la izquierda para que el byte se envíe de forma correcta.

Por lo tanto, la comprobación que debe hacer es cómo el código de la biblioteca trata la dirección del esclavo. Si funciona en el modo de 8 bits, tendría que configurar su TCAADDR en 0xE0.

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

    
respondido por el Michael Karas

Lea otras preguntas en las etiquetas