Hacks I2C: Cómo prohibir relojes en chips

Llega un momento en el que es necesario conectar tres, cuatro o más dispositivos i2c idénticos a un microcontrolador común. Tal vez esté pensando en manejar 128 pantallas de siete segmentos con ocho de esos controladores digitales direccionales MAX-6955-16, o tal vez tenga un robot lleno de articulaciones, cada una de las cuales necesita un inercial BNO055 para la evaluación del ángulo. (Vea arriba.) ¡Grite! En cualquier caso, su mejor opción podría ser un dispositivo I²C elegante que pueda hacer la mayor parte del trabajo por usted. ¿El problema? Con un solo bus I²C, no existe una forma estándar definida en el protocolo para conectar dos o más dispositivos con la misma dirección. ¡Pafu! Sería útil conectar tres IMU BNO055 u ocho MAX6955 y terminar el día. Afortunadamente, hay una solución.

Hemos visto algunos trucos ingeniosos en el pasado para resolver este problema. [Marv G‘s] El método implica alternar entre la dirección a priori y alternativa de un dispositivo con un pin externo. Este método, aunque inteligente, asume que el dispositivo (a) tiene una dirección I²C alternativa y (B) tiene un pin externo para cambiar esa dirección.

Presentaré dos métodos adicionales para iniciar la conversación entre su micro 'y su serie de sensores idénticos. El primero es un "buen truco", pero poco práctico para un uso extensivo. El segundo es mucho más productivo, ¡algo que podrías animar y mostrarle a tu jefe! Sin más preámbulos, comencemos con MMétodo 1.

Por último, si desea seguir, verifique el código fuente en Github.

La configuración de prueba:

En ambos métodos, utilizo el mismo diseño de sensor para comprobar que cada circuito se comporta correctamente. Tenía muchos BMA180 adicionales en el banco, así que lancé un ejemplo basado en estos chips. Anteriormente, el BMA180 era un acelerómetro digital de tres ejes bastante común. Tiene una interfaz I²C con dos direcciones opcionales. Para este ejemplo, soluciono todos con la misma dirección. Monté a tres de estos tipos en ejes mutuamente perpendiculares de mi "cubo de prueba" acrílico y leí el eje Z de cada chip. En esta configuración, puedo seleccionar fácilmente el vector gravitacional del sensor correspondiente mientras los datos vuelan a través de la ventana de mi puerta en serie. Si puedo tratar cada sensor de forma única y leer los datos, tengo un circuito funcional.

Método 1: insertar relojes en chips

Este método dirige su sombrero a SPI porque se comporta de una manera extrañamente similar. Si se siente oxidado por SPI, aquí hay un resumen rápido.

Actualización rápida de SPI:

SPI, como I²C, es otro protocolo que comparte tanto su reloj como sus líneas de datos con varios dispositivos esclavos. La diferencia, sin embargo, radica en el tratamiento de hablar con estos dispositivos, que comparten el mismo bus. Con SPI, mientras que el reloj y las líneas de datos se comparten, los dispositivos se tratan por separado selección de chips (CS) líneas.

Fuente de la imagen: Wikipedia

El microcontrolador maestro dedica un pin de salida único a cada dispositivo (~SS1, ~SS2y ~SS3 en esta ilustración). Cuando el micro maestro 'quiere hablar con un dispositivo, reclama ese dispositivo selección de chips pin de entrada tirando de él a lógica BAJA, y la conversación comienza con el bus de datos. Con el selección de chips BAJO, el esclavo correspondiente escucha los datos en el bus. Mientras tanto, todos los demás dispositivos ignoran la conversación entre el maestro y el esclavo elegido, sosteniendo sus pines de bus en un alta impedancia Expresar.

Dándole a IUC sus propias opciones de chips:

Con I²C, las líneas de Reloj (SCL) y Datos (SDA) todavía se comparten entre todos los dispositivos esclavos I2C, pero el esquema de direccionamiento se produce mediante el envío de un mensaje que se escucha desde todos los dispositivos del bus. Para distinguir un dispositivo en el bus común, el maestro primero transmite la dirección del dispositivo esclavo con el que quiere hablar, después de lo cual ese esclavo responde con ACKnowledge, y todos los demás esclavos ignoran los siguientes datos hasta que la transmisión de datos se completa y el el autobús está "liberado".

Porque tenemos el problema de varios dispositivos con direcciones comunes, teóricamente, todos de estos dispositivos responderían cuando el maestro transmite su dirección común, y el propietario no puede mostrar un solo dispositivo. De hecho, este comportamiento es indefinido en el protocolo I²C.

¡Jikes! Todo funciona cuando nos desviamos de un comportamiento definido, por eso tratamos de evitar estas cosas en la práctica.

¿La solución?

Dependiendo del tipo I²C, sucede que un dispositivo esclavo I²C se convertirá ignorar cambios en el datos línea (SDA) siempre que la línea de reloj (SCL) se mantenga alta. En este método, "dividiré" la línea SCL en varias líneas SCL para que cada dispositivo I²C común reciba su propio SCL. Redirigiendo selectivamente el reloj a cada dispositivo I²C individualmente, básicamente transformé la línea SCL en una “selección de chip”.

Para cortar esa línea de reloj, necesitaré un demultiplexor. Un demultiplexor (o decodificador) toma una entrada lógica y la redirige a una de varias salidas según las líneas binarias seleccionadas.

Dejé caer el multiplexor de ocho vías 74AC11138 para esta tarea. Es rápido, capaz de cambiar a velocidades de megahercios y sus salidas parecen lógicas ALTA. Esta segunda nota es útil porque las líneas SCL inactivas también están predeterminadas en ALTO.

El diseño se muestra en un diagrama simplificado arriba. En él, utilizo Teensy 3.0 haciéndose pasar por el bus maestro I²C. A la derecha del Teensy está la colección de chips idénticos, en este caso acelerómetros BMA180. En el medio está el multiplexor de ocho vías 74AC11138.

Desventajas de este método:

Sin embargo, hay una pequeña desventaja con esta técnica, ya que no es compatible con IUC aparato de relojería característica. Dando un paso atrás, este método asume que la línea SCL es esencialmente unidireccional, controlada solo por el bus maestro I²C. En otras palabras, asumimos que los datos sobre la línea SCL se envían solo de maestro a esclavo y nunca al revés. Sin embargo, si sus dispositivos esclavos I²C funcionan como un reloj, esta suposición se rompe.

¿Qué es un mecanismo de relojería?

Tensión del reloj es un método definido por el protocolo I²C, donde el chip necesita "comprar más tiempo" y mantiene baja la línea SCL, lo que le indica al propietario que no está listo para los siguientes datos. En este escenario, el esclavo domina activamente la línea SCL, y es el único caso en el que los datos ascienden por la línea SCL del esclavo al maestro. En un arreglo con nuestro demultiplexor entre el maestro y nuestro conjunto de esclavos idénticos, estos esclavos no podrán devolver la señal de ajuste del reloj al maestro para indicar que no están listos para los datos si realmente se ejecutan. tictac del reloj. Dirite, tictac del reloj es una característica bastante rara entre los dispositivos compatibles con I²C, por lo que este método probablemente funcionará ahora con unos pocos chips.

Más la próxima semana

Eso es todo por Método 1. Gracias por configurar y revisar la próxima semana para obtener un método un poco más profesional para lidiar con este mismo problema.

  • almiar dice:

    Podrías usar una programación de dos y medio y una tensión de reloj funcionaría.

    • dassheep dice:

      Solo cuando simplemente escuchas el dispositivo en particular que lo hace.

      • Stefan_Z dice:

        I2C mux + líneas IRQ en otro mux I2C para el manejo de interrupciones.
        También @PinheadBE: ¡MAX7219 no es un dispositivo I2C!

      • deshonrado dice:

        Cuando no lo estás escuchando, no registra el reloj en absoluto, por lo que algo está bastante mal si intenta ajustar el reloj.

        • Michael Jensen (@ BrainSlugs83) dice:

          Así es. El esclavo solo habla en el bus en respuesta al maestro, por lo que el maestro retendrá al esclavo elegido hasta que lo escuche. (¿Por qué querrías dejar que un dispositivo que no escuchas encienda los relojes de todos modos?)

  • PinheadBE dice:

    ¿Por qué estás hablando de MAX7219 en un bus I2C? AFAIK, estos no son dispositivos I2C ...

    • Michael Jensen (@ BrainSlugs83) dice:

      Es un SPI ... probablemente un error. Pero me sucede a mí, si usa un conjunto de piezas selects / mux / demuxers de todos modos ... podría conectarlas al mismo bus (en el hardware) y alternar entre el uso de los pines de reloj / datos para el SPI y el protocolo I2C indistintamente (dependiendo del dispositivo que eligió y con el que habló en algún momento).

      Sin embargo, parece que sería más sencillo simplemente dedicar otro par de pines ...

    • Joshua Vasquez dice:

      ¡Tienes toda la razón! Ciertamente busqué la hoja de datos incorrecta más tarde sin pensar. Lo reemplacé con su variante I2C. Dicho esto, dado que hay cuatro direcciones opcionales para elegir en el hardware, este sigue siendo un ejemplo un poco listo. Mi ejemplo de reemplazo favorito es probablemente manejar algunos sensores cercanos VL6180X de ST. Cada uno de estos tiene una dirección I2C fija, y puedo imaginar algunos sistemas que querrían múltiples sensores cercanos.

  • Strauburn dice:

    Por desgracia, esas deben ser algunas de las imágenes I2C más hermosas que he visto en mi vida.

    • J dice:

      Oye, solo mis pensamientos.

    • ESTOLA dice:

      El microcontrolador es demasiado serio y gruñón. Tal vez si se relajara un poco, entonces todo saldría bien.

      • Greenaum dice:

        Tiene mucho trabajo por hacer.

  • Jason dice:

    https://www.sparkfun.com/products/9056
    Funcionó bastante bien. Espero que el siguiente método presentado sea algo mejor

  • Chispeante dice:

    Ahora, por el camino sucio: en lugar del demux, puede conectar una resistencia en serie con la línea de reloj por separado para cada dispositivo y tirar del pin del dispositivo real (es decir, el otro lado de la resistencia) hacia arriba con otro pin de E / S . Esto hace que la “elección del chip” emita un pin del microcontrolador como dominante, de modo que siempre pueda conducir la línea de reloj del dispositivo hacia arriba o hacia abajo. Solo cuando este pin adicional se cambia a un modo de alta impedancia (modo de entrada) pasa la señal de reloj real.

    El valor de las resistencias está algo comprometido; demasiado alto y la señal del reloj cambiará y las pendientes serán malas a altas velocidades, demasiado bajo y la salida del reloj real del microcontrolador podría estar demasiado cargada. Esto no debería ser un gran problema a menos que desee conectar una gran cantidad de dispositivos y necesite una alta velocidad de datos.

  • AK47RFa dice:

    Bela!

    Casi tan hermoso como la tabla “Productos multicomputadora I2C” de http://www.ti.com/lsds/ti/interface/i2c-multiplexer-switch-products.page.

    literalmente, 40 años de investigación en Google 🙂

    ¡Todavía me encanta tu artículo porque es una buena explicación de CS y su carácter ilustrativo!

  • russdill dice:

    Alternativamente, puede intercambiar la línea de datos si tiene un multiplexor de dos directorios. Si ambos gimen, las cosas se ponen interesantes. Supongamos que tiene 2 moscas bidireccionales y 4 dispositivos. Para hablar con cualquier dispositivo, mueva el reloj y los datos a ese dispositivo. Uno de los otros 4 dispositivos recibirá un reloj pero sin datos, otro datos pero sin reloj, y el último, ni reloj ni datos. Esto realmente comienza cuando dices 64 dispositivos. Puedes gestionarlo con 2 ratones de 8 vías.

  • Michael Jensen (@ BrainSlugs83) dice:

    En la sección sobre SPI, "Mientras tanto, todos los demás dispositivos ignoran la conversación entre el maestro y el esclavo elegido, manteniendo sus pines de bus en un estado de alta impedancia". - ¿Es realmente "alta impedancia" y no "alta lógica"? (Los dos son muy diferentes. - No estoy seguro acerca de SPI, pero generalmente las opciones de chip son solo lógicamente altas, no de alta impedancia. La alta impedancia generalmente da como resultado un comportamiento indefinido / aleatorio de dejar que la puerta flote ...)

    • Strauburn dice:

      Por "sus pines de bus" se refiere a los pines de bus MISO, no a las líneas de selección de chips.

    • Búfalo dice:

      Todas las líneas de datos están en el mismo bus, por lo que si pones inactivo en lógica alta, estás arruinando una línea de datos y un dispositivo activo no puede hablar con un patrón. Si los pone en un estado hi-Z, entonces es como si no existieran, por lo que el maestro y el esclavo pueden hablar normalmente.

  • David Anders dice:

    ¡Me encantan las imágenes de selección de i2c! ¿cuál es la licencia para esos?

    • Joshua Vasquez dice:

      ¡Muchas gracias David Anders! Los originales aparecieron en Github con una licencia CC-A:
      https://github.com/Poofjunior/i2c_demultiplexing_demo/tree/master/pics

  • Tomás dice:

    He utilizado con éxito esta placa en el pasado para evitar el problema de muchos dispositivos idénticos en un bus I2C: http://www.bitwizard.nl/shop/expansion-boards/i2c-splitter-PCA9548A
    Es solo una pequeña tabla de escape, pero te ahorra muchos problemas.

  • Teukka dice:

    Una forma de hacer que este truco funcione, permitiendo que SCL sea bidireccional, podría ser el viejo y confiable interruptor analógico 1 de 8 (74HC (T)) 4051, lo único dudoso que veo es el Ron que está en 50 -100. oh estadio y las diversas capacidades de ese dispositivo.

  • roedor de la noche dice:

    Creo que hay otro problema al usar algo como 74AC11138. No solo no funcionará el mecanismo de relojería, sino que dará como resultado un cortocircuito porque el esclavo (intentará) tirar hacia abajo de una línea activada activamente (mientras que normalmente solo tiene una resistencia de voltaje).

    • CRImier dice:

      + Esto. Me pregunto si hay un dispositivo de drenaje abierto adecuado para esto (o tal vez un dispositivo para convertir múltiples señales push-pull en un drenaje abierto, algo parecido a ULN2803)

      • roedor de la noche dice:

        ¿Quizás solo un diodo en serie con la salida (cátodo dirigido al chip) para que el 1138 pueda simplemente extraer corriente pero no empujarla? El problema es el 0.7V cuando la salida es baja.

        • roedor de la noche dice:

          Ah, y por supuesto retírate detrás del diodo ...

        • roedor de la noche dice:

          > El problema es el 0.7V cuando la salida es baja.
          Lo miré, máx. El voltaje de entrada bajo para el BNO055 es 0.25 o 0.3V dependiendo del suministro -> olvídese del problema del diodo, no funcionará. 🙁

  • haddyhad dice:

    La próxima semana ?! Esta es la era de las temporadas llenas de Netflix, ¿cómo voy a tener éxito?

    • davedarko dice:

      para ver algo en netflix entonces?

  • Vejestorio dice:

    También hay circuitos integrados especiales para esto, generalmente controlados por I2C. Por ejemplo: http://www.nxp.com/documents/data_sheet/PCA9547.pdf

    • Qermit dice:

      PCA9547 es una buena opción, como dijiste.

  • MrTrick dice:

    Las multicomputadoras I2C son realmente bastante versátiles y escalables.
    Escribí una publicación hace algún tiempo para ver cuántos dispositivos unidireccionales puedes * insertar * en un bus:
    http://mindbleach.com/words/i2c-and-device-limits/

    • tekkieneet dice:

      Hay beneficios adicionales al usar un multiplexor I2C en lugar de perder el tiempo con una "solución".
      - segmenta físicamente el autobús en un segmento más pequeño. Entonces tendrás menos capacidad en el autobús. La capacitancia es una gran limitación sobre la velocidad y la cantidad de dispositivos que puede subir al bus.
      - En un sistema tolerante a fallas, p. Ej. Rack, puede aislar un mal funcionamiento de tarjeta a tarjeta para que no cuelgue el bus I2C.
      - estos chips ofrecen una traducción de nivel, tolerante a 5V. ¿Necesito decir mas?

  • ulvi dice:

    Lo siento, mi mal inglés, pero ¿qué significa "apostas mejor"?

    • Greenaum dice:

      Debería ser "tu mejor apuesta". Como en tu mejor oportunidad. La mejor elección entre varias alternativas.

      Si esas alternativas fueran caballos de carreras, elegiría su mejor opción.

  • Gogu dice:

    Solo una nota: "demultiplexor (o decodificador)" es de alguna manera incorrecto. El demultiplexor y el decodificador son 2 circuitos digitales diferentes. El detector contiene un decodificador para seleccionar la salida correcta A puerta OR.

  • einball dice:

    Gramática nazi aquí: "tu mejor apuesta" -> "Tu mejor apuesta"

  • Kaz dice:

    Lamento hacer estallar su burbuja, pero hay una manera MUCHO más fácil de hacerlo, asumiendo que ningún dispositivo tiene una dirección 0x7F en el bus I2C (que creo que está explícitamente prohibido): muerda el SDA / SCL y tenga múltiples pines SDA. Luego, si deja SDA en lo alto de los autobuses con los que no está hablando, verán un mensaje que va a 0x7F y no hay ACK en esos autobuses. Esto es menos pines (4 en el caso que se muestra, en lugar de 5), y tiene la ventaja adicional de que si realmente desea leer varios de los dispositivos en una explosión, puede enviar la misma dirección / compensación a cada bus. y obtenga todas las respuestas a la vez;)

    • Miroslav dice:

      Si. También funcionarán muchas líneas SCL (1 para cada dispositivo) con una línea SDA (conectada a todos los dispositivos).

  • Vincent Himpe dice:

    hay multicomputadoras i2c dedicadas que son ellas mismas direccionables i2c. incluso pueden enviar pines de interrupción

    Serie PCA95xx

  • Shon Radell dice:

    He incluido un archivo de Excel que es interactivo con estos "atajos" para mostrarle cómo se verán cuando se envíen al cubo. La tabla de la izquierda está decodificando el valor del eje en LED, la tabla del medio es donde ingresa sus valores para probarlo, y las tablas de la derecha son la salida.

Gloria Vega
Gloria Vega

Deja una respuesta

Tu dirección de correo electrónico no será publicada.