¿Traductores de direcciones i2c en cascada?

Estoy tratando de conectar muchos (~ 80) sensores de distancia ToF VL53L0X en un solo bus i2c. Tienen la dirección i2c predeterminada 0x52, que es programable, pero no persistente. Por lo tanto, puedo elegir entre el encendido/apagado selectivo de los sensores (a través de la expansión GPIO en i2c, etc.) y reprogramar cada dirección individual al inicio, o hacer que las direcciones se traduzcan sobre la marcha en el hardware. Se trata de la segunda opción.

Habría el traductor T(algo así como LTC4316, pero preferiblemente uno sin divisores de voltaje) siempre entre el sensor Sy el bus, así, cada traductor configurado para una dirección diferente, por supuesto:

master ---+---+---+---+
          T   T   T   T
          S   S   S   S

Ahora me gustaría poder conectar otros módulos idénticos como este uno tras otro, pero para evitar conflictos de direcciones, cada módulo tendría un traductor Nal principio:

(--  module 1 --)     (--  module 2 --)      (--  module 3 --)

M---+---+---+---+ === M---+---+---+---+  === M---+---+---+---+
    T   T   T   T         T   T   T   T         T   T   T   T
    S   S   S   S         S   S   S   S         S   S   S   S

El módulo 1 se traduciría por M, el módulo 2 por MM, el módulo 3 por MMMy así sucesivamente, por ejemplo así (con la dirección del sensor 0 para simplificar, Tsumando 1, Msumando 4)

global address        4  5  6  7     8  9 10 11   12 13 14 15
module-level address  0  1  2  3     0  1  2  3    0  1  2  3
sensor address        0  0  0  0     0  0  0  0    0  0  0  0

Me gustaría tener un comentario sobre si esta es una buena manera de avanzar lógicamente, si tiene sentido eléctricamente y tal vez incluso una sugerencia para IC similar al LTC4316, con dirección de traducción seleccionable tirando de los pines alto/bajo.

¿Cuál es la velocidad de comunicación planificada para el I2C? ¿Está planeando usar los 400 kHz? ¿Cuál es la velocidad de comunicación mínima que considerará?
Debería transferir volúmenes bajos de datos, como máximo quizás 10 Hz en cada sensor, por lo que las lecturas máximas de cca 1 kHz en todo el bus, se traducen en quizás 10 kbps de velocidad de datos.

Respuestas (1)

Suena costoso y exige muchos recursos tener un traductor de direcciones para cada sensor. Quizás podría usar un interruptor analógico controlado por I2C en su lugar, y simplemente cambiar el SCL a cada uno de los sensores para que no vean ningún comando cuando estén desconectados.

Por ejemplo, Linear Tech LTC1380 es un mux analógico controlado por I2C 8:1 que también se puede desactivar para no tener conexión analógica.

Podría simplemente poner en paralelo dos de los LTC1380 para dividir SCL en 16 rutas diferentes y luego colocar otro LTC1380 en cada una de las 16 rutas para hablar con 8 sensores diferentes en cada una de las 16 rutas de reloj.

Otra posibilidad es mantener 7 canales mux en cada placa y pasar uno a la siguiente placa. Los siguientes tableros también tendrían 7 a bordo y un paso. La resistencia de ~100 ohmios del interruptor analógico eventualmente causaría problemas, pero probablemente podría salirse con la suya a 4 niveles de profundidad con resistencias pull-up de 4.7K. Después de 4 niveles te quedas sin direcciones para los muxes de todos modos.

Si combinó los dos métodos, podría tener un 8: 1 en el nivel superior hablando con 8 3 cadenas profundas con 7 sensores cada una, lo que le da 8 * 21 = 168 sensores.

Para ayudar a mantener la calidad de la señal, tal vez podría combinar los multiplexores analógicos con el LTC-4302 , que es básicamente una conexión programable entre dos buses I2C que pueden tener 32 direcciones de pines diferentes programadas. También tiene aceleración de tiempo de subida, lo que podría ayudar con autobuses largos.

No importa lo que haga, asegúrese de no exceder las especificaciones de carga capacitiva de I2C (~400pf). Dividir los autobuses puede ayudar con eso.

Gracias por la respuesta. El precio de los traductores no es un gran problema, para mí es una forma de facilitar la operación, los sensores simplemente aparecen con diferentes direcciones. ¿Cuál sería la intensidad de los recursos? ¿El consumo de energía?
Si no le importa usar un traductor para cada sensor, entonces lo que propone debería funcionar. Una "característica" es que deberá configurar individualmente cada LTC4316 para traducir una dirección diferente a 0x52. Eso significa una configuración de resistencia diferente para cada sensor. El consumo de energía probablemente no sea un problema porque el LTC4316 solo usa 2ma. Personalmente, me resultaría más fácil dividir el bus I2C con MUXes y/o el LTC3402 y no tener que lidiar con averiguar 80 combinaciones de resistencias para los traductores de direcciones y agregar todas las diferentes resistencias requeridas a la lista de materiales.
Puede evitar el problema de la resistencia utilizando una escalera R-2R ( en.wikipedia.org/wiki/Resistor_ladder ) impulsada por un encabezado de puente para generar el voltaje de configuración. De esa manera, podría establecer la dirección de cada sensor posterior a la fabricación. Eso agregaría un encabezado y resistencias para cada sensor y tendría un puente correcto en cada encabezado. También puede colocar una resistencia de corte en cada traductor y establecer el voltaje correcto. Creo que es menos complicado dividir el bus I2C para que la ruta a cada sensor se pueda habilitar individualmente en tiempo de ejecución.
Gracias, sugerencias muy útiles. La idea (una vez que verificamos el funcionamiento del prototipo, etc.) es tener un volumen modesto (decenas) de PCB fabricados, por eso encuentro que la idea de que cada módulo sea completamente idéntico, pero con direcciones diferentes cuando se encadenan, es tan fascinante. Entonces hacemos las combinaciones de resistencias solo una vez :) Me alegra que personas como usted compartan su experiencia y conocimiento aquí. ¡Salud!
¿Traductores de direcciones i2c en cascada?
RespuestasAquíPolítica de privacidad1y, 0v