Necesito usar un búfer de tres estados en un bus I2C y tengo un montón de 74125 (búferes de tres estados unidireccionales), así que me pregunto si es posible conectar dos búferes uno tras otro a hacer un búfer bidireccional.
Algo como esto: esquema http://www.tiago.eti.br/storage/buffer.png
¿Funciona?
En general, es posible y bastante común utilizar buffers de tres estados consecutivos para puentes bidireccionales. Tales puentes, sin embargo, necesitan algo que les diga cuándo deben conducir en cada dirección. Por ejemplo, en muchos sistemas de microprocesadores, el procesador se sentará en un bus de datos local junto con su memoria, y se conectará a un bus de datos del sistema a través de un puente bidireccional de este tipo que consta de búferes de tres estados consecutivos (el los chips más comúnmente utilizados para tal fin tendrían 8 pares seguidos de controladores de 3 estados, pero sería posible usar chips con controladores unidireccionales de 3 estados y conectarlos de espaldas). Cuando el procesador desea escribir datos en el bus externo, los controladores se habilitan en una dirección. Cuando quiere leer datos, están habilitados en la otra dirección.
Tales dispositivos funcionan muy bien en situaciones como buses de microprocesadores donde hay señales preexistentes que especifican en qué dirección deben operar. No serán suficientes para algo como una implementación completa de I2C, en la que la dirección del cable del reloj puede invertir sin ninguna transición en él. Para aclarar, un ciclo de lectura de datos o de reconocimiento de esclavo en I2C se comporta de la siguiente manera:
Es imperativo que el cable SCK del esclavo no se libere hasta que el maestro decida liberarlo, y también que el cable SCK del maestro no se libere hasta que el esclavo decida soltarlo. No es posible lograr esto con la lógica convencional, ya que no habría manera de saber si cualquiera de las partes había lanzado SCK sin liberar SCK a ese lado. Philips en sus chips de puente I2C soluciona esto al usar chips que procesan múltiples niveles lógicos. Esencialmente, lo que sucede es que cuando el cable SCK en cualquiera de los lados se empuja "duro" hacia abajo, el cable SCK en el otro lado se empuja hacia abajo, pero algo menos fuertemente. Lo suficientemente fuerte como para que los dispositivos conectados vean la señal como baja, pero lo suficientemente débil como para distinguirla de una fuerte baja controlada externamente.
Tenga en cuenta que en los escenarios que involucran un solo maestro y que no utilizan el protocolo de intercambio basado en el reloj, puede ser posible construir un puente I2C utilizando solo niveles lógicos convencionales, ya que la dirección del cable SDA estaría bien definida en todo momento, pero realizar un seguimiento del estado de la comunicación I2C sería lo suficientemente complicado como para que el uso de un chip puente I2C sea probablemente más fácil.
I2C es un bus de colector abierto / drenaje abierto. Sus controladores son push-pull, por lo que no se combinarían bien.
Pero lo más importante: ¿de dónde obtendría la señal de habilitación? ¡Tendría que cambiar en el momento exacto posiblemente (alargamiento del reloj) incluso mientras se transfiere un solo bit!
En la práctica: no, esto no funcionará.
Es posible en general. Sin embargo
Su problema real es que sus sensores fallan y cuelgan SCL y / o SDA, lo que hace que el bus deje de funcionar. Por lo general, esto se maneja a través de chips de repetidor o multiplexor dedicados como el LTC4307 que tienen lógica de tiempo de espera interno para detecte el estado del bus atascado y desconecte el dispositivo recalcitrante, lo que permite al maestro recuperar el control del bus.
