problema de multiplexación de bus I2C

2

Estoy viendo un efecto secundario inesperado, y podría usar algunos indicadores. Estoy trabajando en un proyecto que utiliza cinco TCS34725 . Estos sensores se están interconectando a través de I2C en un Plataforma de lanzamiento DSP F28069M de TI . El primer problema que enfrenté fue que todos los sensores de color tienen la misma dirección (y no se pueden volver a escribir). Me dieron un DG407 mux analógico de 8 canales para intentar una solución. Al principio, pensé que esta solución era bastante sencilla: usaría el mux para SDA y SCL. Sin embargo, lo que estoy viendo es que la primera dirección mux que establezco funciona perfectamente bien, puedo leer la identificación del sensor de color y los registros de configuración de lectura / escritura, etc. La siguiente dirección mux que establezco hace que el bus I2C se registre como ocupado en la TI DSP.

Mi teoría es que el mux hace una transición temporal a alta impedancia entre los cambios de dirección, y que el estado de alta impedancia se ve de alguna manera como una condición de inicio por parte del DSP, por lo tanto siempre ocupando el bus hasta que se reinicie.

Según el manual de referencia técnica de DSP , puedo establecer el bit I2CMDR.IRS en 1 , que efectivamente desactiva el periférico, restablece sus bits de estado y retiene su configuración. Intenté configurar este bit, retrasar 10uS, cambiar el mux, esperar 10uS, luego borrar el bit, pero aún veo el problema.

¿Alguna idea de cómo puedo solucionar este problema?

Diagrama de circuito a continuación.

simular este circuito : esquema creado usando CircuitLab

    
pregunta Jacob Calvert

2 respuestas

1

Intente colocar resistencias pull-up en el bus I2C en los lados de entrada y salida del mux. Si ya tiene resistencias pequeñas (1 a 2k) en el lado de salida, entonces sería razonable agregar los más grandes (10k) al lado de entrada, ya que solo servirían para mantener el nivel alto mientras el mux está activado y no impulsan el autobús de bajo a alto.

    
respondido por el alex.forencich
0

El problema es muy probablemente la falta de resistencias. Básicamente, cuando cambia el multiplexor de un canal al siguiente, la salida del que acaba de desconectar ahora está flotando. Con toda probabilidad, probablemente flotará a tierra, lo que podría causar algunas condiciones de arranque / parada impares en los dispositivos esclavos, dependiendo de qué mux caiga a cero primero.

Como resultado de la conmutación, el esclavo probablemente ahora se encuentre en un estado extraño y cuando vuelva a conectar el mux, seguirá confundido y es probable que deje de responder. Tengo la sospecha de que si lo intentas y accedes por segunda vez después de que haya fallado sin cambiar el mux, el segundo acceso puede tener éxito, ya que la condición de detención habrá restablecido la lógica del esclavo desde el primer acceso fallido.

La solución es agregar resistencias pull-up en todas ramas del mux para garantizar que, cuando están desconectados, los canales flotan a gran altura, lo que evita las condiciones espurias de inicio / parada.

Usted dice que su lado DSP tiene resistencias internas, lo cual está bien, que mantiene alta la rama principal del bus. Pero todavía necesitarás resistencias en las otras ramas. Estos solo necesitan ser pull-ups de baja resistencia, ya que no intentan controlar los bordes SDA / SCL, solo están ahí para mantener el nivel cuando están desconectados.

El 180R que probaste es demasiado fuerte para I²C, e incluso 2.7k será demasiado fuerte si el lado maestro ya tiene pull-ups razonablemente fuertes. Como sugiere @ alex.forencich, 10k es probablemente un valor mucho más razonable. Esto debería tener una fuerza de accionamiento suficientemente baja para no causar problemas a sus esclavos. Es probable que incluso puedas ir más alto con la resistencia si tus esclavos están luchando, tal vez prueba 22k o 47k.

    
respondido por el Tom Carpenter

Lea otras preguntas en las etiquetas