stringtranslate.com

Yo²C

I2C ( Inter-Integrated Circuit ; pronunciado como “ eye-squared-see ” o “ eye-two-see ”), conocido alternativamente como I2C o IIC , es un bus de comunicación serial sincrónico , multicontrolador/multiobjetivo (históricamente denominado maestro/esclavo ), de un solo extremo , inventado en 1982 por Philips Semiconductors . Se usa ampliamente para conectar circuitos integrados periféricos ( CI ) de menor velocidad a procesadores y microcontroladores en comunicaciones intraplaca de corta distancia.

Varios competidores, como Siemens , NEC , Texas Instruments , STMicroelectronics , Motorola , [1] Nordic Semiconductor e Intersil , han introducido productos compatibles con I2C en el mercado desde mediados de la década de 1990.

El bus I2C se puede encontrar en una amplia gama de aplicaciones electrónicas donde la simplicidad y el bajo costo de fabricación son más importantes que la velocidad. Los componentes y sistemas de PC que involucran I2C son EEPROM de detección de presencia en serie (SPD) en módulos de memoria dual en línea (DIMM), datos de identificación de pantalla extendida (EDID) para monitores a través de conectores VGA , DVI y HDMI , acceso a chips NVRAM , etc. Las aplicaciones I2C comunes incluyen la lectura de monitores de hardware, sensores, relojes en tiempo real , control de actuadores, acceso a DAC y ADC de baja velocidad , control de pantallas LCD u OLED simples , cambio de configuraciones de pantalla de computadora (por ejemplo, luz de fondo, contraste, tono, balance de color) a través del canal de datos de pantalla y cambio de volumen del altavoz.

Una de las ventajas de I2C es la capacidad de un microcontrolador para controlar una red de chips de dispositivos con solo dos pines de E/S de uso general y software. Muchas otras tecnologías de bus utilizadas en aplicaciones similares, como el bus de interfaz periférica en serie (SPI), requieren más pines y señales para conectar varios dispositivos.

El bus de administración del sistema (SMBus), definido por Intel y Duracell en 1994, es un subconjunto de I2C que define un uso más estricto. Uno de los propósitos de SMBus es promover la solidez y la interoperabilidad. En consecuencia, los sistemas I2C modernos incorporan algunas políticas y reglas de SMBus, a veces compatibles con I2C y SMBus, y requieren solo una reconfiguración mínima, ya sea mediante comandos o mediante el uso de pines de salida. La administración del sistema para sistemas de PC utiliza SMBus, cuyos pines están asignados tanto en conectores PCI convencionales como PCI Express .

Expansor de E/S I2C de 8 bits Microchip MCP23008 en encapsulado DIP- 18 [ 2 ]

Diseño

Un esquema de ejemplo con un controlador (un microcontrolador ), tres nodos de destino (un ADC , un DAC y un microcontrolador) y resistencias pull-up R p

I 2 C utiliza sólo dos señales : línea de datos en serie (SDA) y línea de reloj en serie (SCL). Ambas son bidireccionales y se activan con resistencias . [3] Los voltajes típicos utilizados son +5  V o +3,3 V, aunque se permiten sistemas con otros voltajes.

El diseño de referencia I 2 C tiene un espacio de direcciones de 7 bits , con una extensión de 10 bits raramente utilizada. [4] Las velocidades de bus  I 2 C comunes son el modo estándar de 100 kbit/s y el modo rápido de 400 kbit/s . También hay un modo de baja velocidad de 10 kbit/s , pero también se permiten frecuencias de reloj arbitrariamente bajas. Las revisiones posteriores de I 2 C pueden albergar más nodos y funcionar a velocidades más rápidas ( modo rápido de 400 kbit/s, modo rápido plus de 1 Mbit/s ,  modo de alta velocidad de 3,4 Mbit/smodo ultrarrápido de 5 Mbit/s ). Estas velocidades se utilizan más ampliamente en sistemas integrados que en PC.

Tenga en cuenta que las tasas de bits se indican para las transferencias entre el controlador (maestro) y el dispositivo de destino (esclavo) sin estiramiento del reloj ni otros gastos generales de hardware. Los gastos generales de protocolo incluyen una dirección de destino y quizás una dirección de registro dentro del dispositivo de destino, así como bits ACK/NACK por byte. Por lo tanto, la tasa de transferencia real de datos de usuario es menor que lo que implicarían esas tasas de bits pico por sí solas. Por ejemplo, si cada interacción con un destino permite de manera ineficiente que se transfiera solo 1 byte de datos, la tasa de datos será menor que la mitad de la tasa de bits pico.

La cantidad de nodos que pueden existir en un bus I2C determinado está limitada por el espacio de direcciones y también por la capacitancia total del bus de 400 pF  , lo que restringe las distancias de comunicación prácticas a unos pocos metros. La impedancia relativamente alta y la baja inmunidad al ruido requieren un potencial de tierra común, lo que nuevamente restringe el uso práctico a la comunicación dentro de la misma placa de PC o un pequeño sistema de placas.

Diseño de referencia

El diseño de referencia mencionado anteriormente es un bus con líneas de reloj (SCL) y de datos (SDA) con direccionamiento de 7 bits. El bus tiene dos funciones para los nodos, ya sea controlador (maestro) o destino (esclavo):

El bus es un bus multicontrolador, lo que significa que puede haber cualquier cantidad de nodos controladores. Además, los roles de controlador y destino pueden cambiarse entre mensajes (después de enviar un STOP).

Puede haber cuatro modos de funcionamiento potenciales para un dispositivo de bus determinado, aunque la mayoría de los dispositivos solo utilizan una única función y sus dos modos:

Además de los bits de datos 0 y 1, el bus I2C permite señales especiales de INICIO y DETENCIÓN que actúan como delimitadores de mensajes y son distintas de los bits de datos. (Esto contrasta con los bits de inicio y detención utilizados en la comunicación serial asíncrona , que se distinguen de los bits de datos solo por su sincronización).

El controlador está inicialmente en modo de transmisión de controlador enviando un START seguido de la dirección de 7 bits del objetivo con el que desea comunicarse, que finalmente es seguido por un solo bit que representa si desea escribir (0) o leer (1) del objetivo.

Si el objetivo existe en el bus, responderá con un bit ACK (activo bajo para reconocimiento) para esa dirección. El controlador continúa entonces en modo de transmisión o recepción (según el bit de lectura/escritura que envió) y el objetivo continúa en el modo complementario (recepción o transmisión, respectivamente).

Los bytes de dirección y datos se envían con el bit más significativo primero. La condición de inicio se indica mediante una transición de alto a bajo de SDA con SCL alto; la condición de detención se indica mediante una transición de bajo a alto de SDA con SCL alto. Todas las demás transiciones de SDA se realizan con SCL bajo.

Si el controlador desea escribir en el destino, envía repetidamente un byte y el destino envía un bit ACK. (En esta situación, el controlador está en modo de transmisión de controlador y el destino está en modo de recepción de destino).

Si el controlador desea leer desde el destino, recibe repetidamente un byte de este último y envía un bit ACK después de cada byte, excepto el último. (En esta situación, el controlador está en modo de recepción de controlador y el destino está en modo de transmisión de destino).

Una transacción I2C puede constar de varios mensajes. El controlador finaliza un mensaje con una condición STOP si este es el final de la transacción o puede enviar otra condición START para conservar el control del bus para otro mensaje (una transacción de "formato combinado").

Protocolos de mensajes

I 2 C define tipos básicos de transacciones, cada una de las cuales comienza con un INICIO y termina con un DETENER:

En una transacción combinada, cada lectura o escritura comienza con un START y la dirección del destino. Las condiciones START después de la primera también se denominan bits START repetidos . Los START repetidos no están precedidos por condiciones STOP, que es la forma en que los destinos saben que el siguiente mensaje es parte de la misma transacción.

Cada objetivo determinado solo responderá a ciertos mensajes, como se especifica en la documentación de su producto.

Los sistemas I2C puros admiten estructuras de mensajes arbitrarias. SMBus está restringido a nueve de esas estructuras, como leer palabra N y escribir palabra N , que involucran un solo destino. PMBus extiende SMBus con un protocolo de grupo , lo que permite que se envíen múltiples transacciones SMBus de ese tipo en un mensaje combinado. El STOP de terminación indica cuándo deben surtir efecto esas acciones agrupadas. Por ejemplo, una operación PMBus podría reconfigurar tres fuentes de alimentación (utilizando tres direcciones de destino I2C diferentes ) , y sus nuevas configuraciones surtirían efecto al mismo tiempo: cuando reciben ese STOP.

Con solo unas pocas excepciones, ni I 2 C ni SMBus definen la semántica de los mensajes, como el significado de los bytes de datos en los mensajes. Por lo demás, la semántica de los mensajes es específica de cada producto. Esas excepciones incluyen los mensajes dirigidos a la dirección de llamada general de I 2 C (0x00) o a la dirección de respuesta de alerta de SMBus ; y los mensajes relacionados con el protocolo de resolución de direcciones (ARP) de SMBus para la asignación y gestión dinámica de direcciones.

En la práctica, la mayoría de los destinos adoptan modelos de control de solicitud-respuesta, donde uno o más bytes después de un comando de escritura se tratan como un comando o una dirección. Esos bytes determinan cómo se tratan los bytes escritos posteriores o cómo responde el destino en las lecturas posteriores. La mayoría de las operaciones de SMBus implican comandos de un solo byte.

Ejemplo de mensaje: EEPROM 24C32

STMicroelectronics M24C08-BN6: EEPROM en serie con bus I 2 C [5]

Un ejemplo específico es la EEPROM de tipo 24C32 , que utiliza dos bytes de solicitud que se denominan Dirección alta y Dirección baja. (En consecuencia, estas EEPROM no son utilizables por hosts SMBus puros, que solo admiten comandos o direcciones de un solo byte). Estos bytes se utilizan para direccionar bytes dentro del espacio de dirección de la EEPROM de 32  kbits (o 4  kB ). El mismo direccionamiento de dos bytes también lo utilizan las EEPROM más grandes, como la 24C512 que almacena 512 kbits (o 64 kB). La escritura y lectura de datos en estas EEPROM utiliza un protocolo simple: se escribe la dirección y luego se transfieren los datos hasta el final del mensaje. La parte de transferencia de datos del protocolo puede causar problemas en el SMBus, ya que los bytes de datos no están precedidos por un recuento y se pueden transferir más de 32 bytes a la vez. Las EEPROM I2C más pequeñas que 32 kbit, como la 24C02 de 2 kbit, se utilizan a menudo en el SMBus con transferencias de datos de un solo byte ineficientes para superar este problema.

Un único mensaje escribe en la EEPROM. Después del START, el controlador envía la dirección de bus del chip con el bit de dirección en blanco ( write ), luego envía la dirección de dos bytes de datos dentro de la EEPROM y luego envía bytes de datos que se escribirán comenzando en esa dirección, seguido de un STOP. Al escribir varios bytes, todos los bytes deben estar en la misma página de 32 bytes. Mientras está ocupada guardando esos bytes en la memoria, la EEPROM no responderá a más solicitudes I 2 C. (Esa es otra incompatibilidad con SMBus: los dispositivos SMBus siempre deben responder a sus direcciones de bus).

Para leer a partir de una dirección particular en la EEPROM, se utiliza un mensaje combinado. Después de un START, el controlador primero escribe la dirección de bus de ese chip con el bit de dirección en blanco ( write ) y luego los dos bytes de la dirección de datos de la EEPROM. Luego envía un START (repetido) y la dirección de bus de la EEPROM con el bit de dirección establecido ( read ). La EEPROM responderá entonces con los bytes de datos comenzando en la dirección de datos de la EEPROM especificada: un mensaje combinado: primero una escritura, luego una lectura. El controlador emite un ACK después de cada byte leído excepto el último byte, y luego emite un STOP. La EEPROM incrementa la dirección después de cada byte de datos transferido; las lecturas de múltiples bytes pueden recuperar todo el contenido de la EEPROM utilizando un mensaje combinado.

Capa física

Bus I 2 C: R p son resistencias pull-up, R s son resistencias en serie opcionales. [3]

En la capa física , tanto las líneas SCL como las SDA son un diseño de bus de drenaje abierto ( MOSFET ) o colector abierto ( BJT ), por lo que se necesita una resistencia pull-up para cada línea. Se genera un "0" lógico al conectar la línea a tierra, y se genera un "1" lógico al dejar que la línea flote ( alta impedancia de salida ) de modo que la resistencia pull-up la eleve. Una línea nunca se activa activamente. Este cableado permite que varios nodos se conecten al bus sin cortocircuitos por contención de la señal. Los sistemas de alta velocidad (y algunos otros) pueden usar una fuente de corriente en lugar de una resistencia para conectar solo SCL o tanto SCL como SDA, para acomodar una mayor capacitancia del bus y permitir tiempos de subida más rápidos.

Una consecuencia importante de esto es que varios nodos pueden estar activando las líneas simultáneamente. Si algún nodo está activando la línea en nivel bajo, esta se mantendrá en nivel bajo. Los nodos que intentan transmitir un nivel lógico (es decir, dejar que la línea flote en nivel alto) pueden detectar esto y concluir que otro nodo está activo al mismo tiempo.

Cuando se utiliza en SCL, esto se denomina estiramiento del reloj y es un mecanismo de control de flujo para los objetivos. Cuando se utiliza en SDA, esto se denomina arbitraje y garantiza que solo haya un transmisor a la vez.

Cuando está inactiva, ambas líneas están en nivel alto. Para iniciar una transacción, SDA se pone en nivel bajo mientras SCL permanece en nivel alto. Es ilegal [3] : 14  transmitir un marcador de parada liberando SDA para que flote en nivel alto nuevamente (aunque un "mensaje nulo" de este tipo suele ser inofensivo), por lo que el siguiente paso es poner SCL en nivel bajo.

A excepción de las señales de inicio y detención, la línea SDA solo cambia cuando el reloj está bajo; la transmisión de un bit de datos consiste en pulsar la línea del reloj en alto mientras se mantiene la línea de datos estable en el nivel deseado.

Mientras el SCL está bajo, el transmisor (inicialmente el controlador) establece el SDA en el valor deseado y (después de un pequeño retraso para permitir que el valor se propague) deja que el SCL flote alto. Luego, el controlador espera a que el SCL realmente suba; esto se retrasará por el tiempo de subida finito de la señal SCL (la constante de tiempo RC de la resistencia pull-up y la capacitancia parásita del bus) y puede retrasarse adicionalmente por el estiramiento del reloj de un objetivo.

Una vez que el SCL está alto, el controlador espera un tiempo mínimo (4 μs para I 2 C de velocidad estándar ) para asegurarse de que el receptor haya visto el bit y luego lo vuelve a bajar. Esto completa la transmisión de un bit.

Después de cada 8 bits de datos en una dirección, se transmite un bit de "reconocimiento" en la otra dirección. El transmisor y el receptor intercambian funciones para un bit y el receptor original transmite un solo bit "0" (ACK) de vuelta. Si el transmisor ve un bit "1" (NACK) en su lugar, aprende que:

Sólo la línea SDA cambia de dirección durante los bits de reconocimiento; el SCL siempre está controlado por el controlador.

Después del bit de reconocimiento, la línea de reloj está baja y el controlador puede hacer una de tres cosas:

Estiramiento del reloj con SCL

Una de las características más significativas del protocolo I2C es el estiramiento del reloj. Un dispositivo de destino direccionado puede mantener la línea de reloj (SCL) baja después de recibir (o enviar) un byte, lo que indica que aún no está listo para procesar más datos. El controlador que se está comunicando con el destino puede no terminar la transmisión del bit actual, sino que debe esperar hasta que la línea de reloj realmente se vuelva alta. Si el destino está estirando el reloj, la línea de reloj seguirá siendo baja (porque las conexiones son de drenaje abierto ). Lo mismo es cierto si un segundo controlador, más lento, intenta controlar el reloj al mismo tiempo. (Si hay más de un controlador, todos menos uno de ellos normalmente perderán el arbitraje).

El controlador debe esperar hasta que observe que la línea del reloj sube, y un tiempo mínimo adicional (4 μs para I2C estándar de 100 kbit/s ) antes de bajar el reloj nuevamente.

Aunque el controlador también puede mantener la línea SCL baja durante el tiempo que desee (esto no está permitido desde la Rev. 6 del protocolo – subsección 3.1.1), el término "estiramiento del reloj" normalmente se utiliza sólo cuando los objetivos lo hacen. Aunque en teoría cualquier pulso de reloj puede estirarse, generalmente son los intervalos antes o después del bit de reconocimiento los que se utilizan. Por ejemplo, si el objetivo es un microcontrolador , su interfaz I 2 C podría estirar el reloj después de cada byte, hasta que el software decida si enviar un reconocimiento positivo o un NACK.

La ampliación del reloj es el único momento en I 2 C en el que el objetivo controla SCL. Muchos objetivos no necesitan ampliar el reloj y, por lo tanto, tratan a SCL estrictamente como una entrada sin circuitos que la controlen. Algunos controladores, como los que se encuentran dentro de los ASIC personalizados, pueden no admitir la ampliación del reloj; a menudo, estos dispositivos se etiquetarán como una "interfaz de dos cables" y no como I 2 C.

Para garantizar un rendimiento mínimo del bus , SMBus establece límites sobre hasta qué punto se pueden estirar los relojes. Los hosts y los destinos que se adhieren a esos límites no pueden bloquear el acceso al bus durante más de un breve período de tiempo, lo que no es una garantía que ofrezcan los sistemas I2C puros .

Arbitraje mediante SDA

Cada controlador monitorea el bus en busca de bits de inicio y detención y no inicia un mensaje mientras otro controlador mantiene el bus ocupado. Sin embargo, dos controladores pueden iniciar la transmisión aproximadamente al mismo tiempo; en este caso, ocurre el arbitraje. El modo de transmisión de destino también puede ser arbitrado, cuando un controlador se dirige a múltiples destinos, pero esto es menos común. A diferencia de los protocolos (como Ethernet ) que utilizan demoras de retroceso aleatorias antes de emitir un reintento, I 2 C tiene una política de arbitraje determinista. Cada transmisor verifica el nivel de la línea de datos (SDA) y lo compara con los niveles que espera; si no coinciden, ese transmisor ha perdido el arbitraje y abandona esta interacción de protocolo.

Si un transmisor establece el nivel de SDA en 1 (no activa ninguna señal) y un segundo transmisor lo establece en 0 (tira a tierra), el resultado es que la línea está baja. El primer transmisor observa entonces que el nivel de la línea es diferente del esperado y concluye que otro nodo está transmitiendo. El primer nodo que nota dicha diferencia es el que pierde el arbitraje: deja de activar SDA. Si es un controlador, también deja de activar SCL y espera un STOP; luego puede intentar volver a emitir su mensaje completo. Mientras tanto, el otro nodo no ha notado ninguna diferencia entre los niveles esperados y reales en SDA y, por lo tanto, continúa la transmisión. Puede hacerlo sin problemas porque hasta ahora la señal ha sido exactamente como esperaba; ningún otro transmisor ha alterado su mensaje.

Si los dos controladores envían un mensaje a dos destinos diferentes, el que envía la dirección de destino más baja siempre "gana" el arbitraje en la etapa de dirección. Dado que los dos controladores pueden enviar mensajes a la misma dirección de destino y las direcciones a veces hacen referencia a múltiples destinos, el arbitraje a veces debe continuar en las etapas de datos.

El arbitraje se produce muy raramente, pero es necesario para una compatibilidad adecuada con varios controladores. Al igual que con la ampliación del reloj, no todos los dispositivos admiten el arbitraje. Los que sí lo hacen, generalmente se etiquetan como compatibles con la comunicación "con varios controladores".

Un caso que debe manejarse con cuidado en las implementaciones de I2C con múltiples controladores es el de los controladores que se comunican entre sí. Un controlador puede perder el arbitraje ante un mensaje entrante y debe cambiar su rol de controlador a destino a tiempo para reconocer su propia dirección.

En el caso extremadamente raro de que dos controladores envíen mensajes idénticos simultáneamente, ambos considerarán que la comunicación se ha realizado correctamente, pero el objetivo solo verá un mensaje. Por este motivo, cuando varios controladores pueden acceder a un objetivo, cada comando reconocido por el objetivo debe ser idempotente o debe garantizarse que nunca será emitido por dos controladores al mismo tiempo. (Por ejemplo, un comando emitido por un solo controlador no necesita ser idempotente, ni es necesario que un comando específico sea idempotente cuando algún mecanismo de exclusión mutua garantiza que solo un controlador puede emitir ese comando en un momento dado).

Arbitraje en SMBus

Si bien I 2 C solo arbitra entre controladores, SMBus utiliza el arbitraje en tres contextos adicionales, donde múltiples objetivos responden al controlador y uno transmite su mensaje.

Arbitraje en PMBus

La versión 1.3 de PMBus amplía el protocolo de respuesta de alerta de SMBus en su protocolo de "lectura de zona". [6] Los objetivos se pueden agrupar en "zonas", y se puede solicitar a todos los objetivos de una zona que respondan, con sus respuestas enmascaradas (omitiendo información no deseada), invertidas (de modo que la información deseada se envíe como bits 0, que ganan el arbitraje) o reordenadas (de modo que la información más significativa se envíe primero). El arbitraje garantiza que la respuesta de mayor prioridad sea la que se devuelva primero al controlador.

PMBus reserva las direcciones I2C 0x28 y 0x37 para lecturas y escrituras de zona, respectivamente.

Diferencias entre modos

Existen varios modos de funcionamiento posibles para la comunicación I2C . Todos son compatibles en el sentido de que siempre se puede utilizar el modo estándar de 100 kbit/s , pero la combinación de dispositivos de diferentes capacidades en el mismo bus puede causar problemas, como los siguientes:

Algunos proveedores ofrecen un modo Turbo no estándar con una velocidad de hasta 1,4 Mbit/s.

En todos los modos, la frecuencia del reloj está controlada por el o los controladores, y un bus más largo de lo normal puede funcionar a una velocidad más lenta que la nominal mediante subclocking .

Interconexiones de circuitos

Una placa ADC de 16 bits con interfaz I2C

El conector I2C es popular para interconectar circuitos periféricos con sistemas de creación de prototipos, como Arduino y Raspberry Pi . El conector I2C no utiliza un conector estandarizado, sin embargo, los diseñadores de placas han creado varios esquemas de cableado para interconexiones I2C . Para minimizar el posible daño debido a la conexión de cabezales de 0,1 pulgadas al revés, algunos desarrolladores han sugerido utilizar conexiones de señal y alimentación alternas de los siguientes esquemas de cableado: (GND, SCL, VCC, SDA) o (VCC, SDA, GND, SCL). [7]

La gran mayoría de las aplicaciones utilizan el I2C en la forma en que fue diseñado originalmente: circuitos integrados periféricos conectados directamente a un procesador en la misma placa de circuito impreso y, por lo tanto, a distancias relativamente cortas de menos de 30 cm (1 pie), sin un conector. Sin embargo, utilizando un controlador diferencial, una versión alternativa del I2C puede comunicarse hasta 20 metros (posiblemente más de 100 metros) a través de un cable CAT5 u otro cable. [8] [9]

Varios conectores estándar transportan señales I2C . Por ejemplo, el conector UEXT transporta I2C ; el conector iPack de 10 pines transporta I2C ; [ 10] el conector 6P6C Lego Mindstorms NXT transporta I2C ; [ 11] [12] [13] [14] algunas personas utilizan los conectores 8P8C y el cable CAT5 que normalmente se utiliza para la capa física de Ethernet para transportar en su lugar señales I2C con codificación diferencial [15] o señales I2C de un solo extremo potenciadas ; [16] y todos los conectores HDMI y la mayoría de los conectores DVI y VGA transportan datos DDC2 sobre I2C .

Buffering y multiplexación

Cuando hay muchos dispositivos I2C en un sistema, puede ser necesario incluir buffers de bus o multiplexores para dividir segmentos de bus grandes en otros más pequeños. Esto puede ser necesario para mantener la capacitancia de un segmento de bus por debajo del valor permitido o para permitir que varios dispositivos con la misma dirección estén separados por un multiplexor. Existen muchos tipos de multiplexores y buffers y todos deben tener en cuenta el hecho de que las líneas I2C están especificadas para ser bidireccionales. Los multiplexores se pueden implementar con conmutadores analógicos, que pueden unir un segmento a otro. Los conmutadores analógicos mantienen la naturaleza bidireccional de las líneas, pero no aíslan la capacitancia de un segmento de otro ni proporcionan capacidad de buffer.

Los buffers se pueden utilizar para aislar la capacitancia de un segmento de otro y/o permitir que I 2 C se envíe a través de cables o trazas más largos. Los buffers para líneas bidireccionales como I 2 C deben utilizar uno de varios esquemas para evitar el bloqueo. I 2 C es de drenaje abierto, por lo que los buffers deben controlar un nivel bajo en un lado cuando detectan un nivel bajo en el otro. Un método para evitar el bloqueo es que un buffer tenga niveles de entrada y salida cuidadosamente seleccionados de modo que el nivel de salida de su controlador sea más alto que su umbral de entrada, lo que evita que se active a sí mismo. Por ejemplo, un buffer puede tener un umbral de entrada de 0,4 V para detectar un nivel bajo, pero un nivel bajo de salida de 0,5 V. Este método requiere que todos los demás dispositivos en el bus tengan umbrales que sean compatibles y, a menudo, significa que no se pueden poner en serie varios buffers que implementen este esquema.

Alternativamente, existen otros tipos de buffers que implementan amplificadores de corriente o mantienen un registro del estado (es decir, qué lado llevó el bus a un nivel bajo) para evitar el bloqueo. El método de estado generalmente significa que se crea un pulso no deseado durante una transferencia cuando un lado lleva el bus a un nivel bajo, luego el otro lo lleva a un nivel bajo y luego el primer lado se libera (esto es común durante un reconocimiento de I 2 C).

Compartir SCL entre varios buses

Cuando se tiene un único controlador, es posible que varios buses I2C compartan la misma línea SCL. [17] [18] Los paquetes en cada bus se envían uno después del otro o al mismo tiempo. Esto es posible porque la comunicación en cada bus se puede subdividir en períodos cortos alternados con SCL alto seguidos de períodos cortos con SCL bajo. Y el reloj se puede estirar, si un bus necesita más tiempo en un estado.

Las ventajas son utilizar dispositivos de destino con la misma dirección al mismo tiempo y ahorrar conexiones o un rendimiento más rápido al utilizar varias líneas de datos al mismo tiempo.

Tabla de estados de línea

Estas tablas muestran los distintos estados atómicos y operaciones de bits que pueden ocurrir durante un mensaje I2C .

Estructura de direccionamiento

Direccionamiento de 7 bits

Direccionamiento de 10 bits

Direcciones reservadas en un espacio de direcciones de 7 bits

Dos grupos de 8 direcciones cada uno están reservados para funciones especiales:

Además, las 112 direcciones restantes están designadas para clases específicas de dispositivos, y algunas de ellas están reservadas además por estándares relacionados o por uso común.

SMBus reserva algunas direcciones adicionales. En particular, 0001 000está reservada para el host SMBus, que puede ser utilizada por dispositivos con capacidad de controlador. 0001 100Es la "dirección de respuesta de alerta SMBus" que es consultada por el host después de una interrupción fuera de banda y 1100 001es la dirección predeterminada que utilizan inicialmente los dispositivos con capacidad de asignación de direcciones dinámicas.


Direcciones no reservadas en un espacio de direcciones de 7 bits

Aunque MSB 1111 está reservado para la identificación del dispositivo y el direccionamiento de destino (esclavo) de 10 bits, también lo utilizan los dispositivos dependientes de la pantalla VESA DDC , como los dispositivos señaladores . [22]

Formato de transacción

Una transacción I2C consta de uno o más mensajes . Cada mensaje comienza con un símbolo de inicio y la transacción termina con un símbolo de fin. Los símbolos de inicio posteriores al primero, que dan inicio a un mensaje pero no a una transacción, se denominan símbolos de inicio repetidos .

Cada mensaje es una lectura o una escritura. Una transacción que consta de un solo mensaje se denomina transacción de lectura o de escritura. Una transacción que consta de varios mensajes se denomina transacción combinada. La forma más común de esta última es un mensaje de escritura que proporciona información de dirección dentro del dispositivo, seguido de un mensaje de lectura.

Muchos dispositivos I2C no distinguen entre una transacción combinada y los mismos mensajes enviados como transacciones separadas, pero no todos. El protocolo de identificación del dispositivo requiere una sola transacción; los objetivos tienen prohibido responder si observan un símbolo de detención. Los modos de configuración, calibración o autoprueba que hacen que el objetivo responda de manera inusual también suelen finalizar automáticamente al final de una transacción.

Diagrama de tiempos

Secuencia de transferencia de datos
Secuencia de transferencia de datos
  1. La transferencia de datos se inicia con una condición de inicio (S) señalada por SDA que se pone bajo mientras SCL permanece alto.
  2. Se baja el SCL y SDA establece el nivel del primer bit de datos mientras mantiene el SCL bajo (durante el tiempo de la barra azul).
  3. Los datos se muestrean (se reciben) cuando SCL aumenta para el primer bit (B1). Para que un bit sea válido, SDA no debe cambiar entre un flanco ascendente de SCL y el flanco descendente posterior (todo el tiempo de la barra verde).
  4. Este proceso se repite: SDA realiza la transición mientras SCL está bajo y los datos se leen mientras SCL está alto (B2 a Bn).
  5. El bit final es seguido por un pulso de reloj, durante el cual SDA se reduce en preparación para el bit de detención .
  6. Una condición de parada (P) se señala cuando SCL aumenta, seguido por un aumento de SDA.

Para evitar la detección de marcadores falsos, hay un retraso mínimo entre el flanco descendente de SCL y el cambio de SDA, y entre el cambio de SDA y el flanco ascendente de SCL. Tenga en cuenta que un mensaje I 2 C que contiene n bits de datos (incluidos los reconocimientos) contiene n + 1 pulsos de reloj.

Diseño de software

I 2 C se presta a un diseño de software de "controlador de bus". El software para dispositivos conectados se escribe para llamar a un "controlador de bus" que maneja el hardware I 2 C de bajo nivel real. Esto permite que el código del controlador para dispositivos conectados se transfiera fácilmente a otro hardware, incluido un diseño de bit-banging.

Ejemplo de golpear con un bit la I2Protocolo C

A continuación se muestra un ejemplo de bit banging del protocolo I2C como un controlador I2C ( maestro). El ejemplo está escrito en pseudo C. Ilustra todas las características I2C descritas anteriormente (extensión de reloj, arbitraje, bit de inicio/parada, ack/nack). [24]

// Funciones de soporte específicas del hardware que DEBEN personalizarse:#define I2CSPEED 100vacío I2C_delay ( vacío ); bool read_SCL ( void ); // Devuelve el nivel actual de la línea SCL, 0 o 1  bool read_SDA ( void ); // Devuelve el nivel actual de la línea SDA, 0 o 1  void set_SCL ( void ); // No controlar SCL (establecer pin de alta impedancia)  void clear_SCL ( void ); // Conducir activamente a nivel bajo la señal SCL  void set_SDA ( void ); // No controlar SDA (establecer pin de alta impedancia)  void clear_SDA ( void ); // Conducir activamente a nivel bajo la señal SDA  arbitraje nulo_perdido ( void ) ; bool iniciado = falso ; // datos globales    vacío i2c_start_cond ( vacío ) { si ( comenzó ) {    // si se inicia, realiza una condición de reinicio // Establezca SDA en 1 establecer_SDA (); Retraso I2C (); establecer_SCL (); mientras ( read_SCL () == 0 ) { // Estiramiento del reloj      // Deberías agregar tiempo de espera a este bucle } // Tiempo de configuración de inicio repetido, mínimo 4,7 us Retraso I2C (); } si ( leer_SDA () == 0 ) {     arbitraje_perdido (); } // SCL es alto, establezca SDA de 1 a 0. borrar_SDA (); Retraso I2C (); borrar_SCL (); iniciado = verdadero ;  }vacío i2c_stop_cond ( vacío ) { // Establezca SDA en 0 borrar_SDA (); Retraso I2C (); establecer_SCL (); // Estiramiento del reloj mientras ( leer_SCL () == 0 ) {     // agrega tiempo de espera a este bucle. } // Tiempo de configuración del bit de parada, mínimo 4us Retraso I2C (); // SCL es alto, establezca SDA de 0 a 1 establecer_SDA (); Retraso I2C (); si ( leer_SDA () == 0 ) {     arbitraje_perdido (); } iniciado = falso ;  }// Escribe un bit en el bus I2Cvoid i2c_write_bit ( bit booleano )  { si ( bit ) {   establecer_SDA (); } demás {   borrar_SDA (); } // Retardo de propagación del cambio de SDA Retraso I2C (); // Establezca SCL alto para indicar que hay un nuevo valor SDA válido disponible establecer_SCL (); // Espere a que el destino lea el valor SDA, mínimo 4 us para el modo estándar Retraso I2C (); mientras ( read_SCL () == 0 ) { // Estiramiento del reloj      // Deberías agregar tiempo de espera a este bucle } // El SCL es alto, ahora los datos son válidos // Si el SDA es alto, verifique que nadie más esté manejando el SDA si ( bit && ( leer_SDA () == 0 )) {       arbitraje_perdido (); } // Limpiar el SCL al mínimo para preparar el próximo cambio borrar_SCL ();}//Lea un poco del bus I2Cbool i2c_read_bit ( vacío ) { bit booleano ;  // Deje que el objetivo conduzca los datos establecer_SDA (); // Espere a que el destino escriba el valor SDA, mínimo 4 us para el modo estándar Retraso I2C (); // Establezca SCL alto para indicar que hay un nuevo valor SDA válido disponible establecer_SCL (); mientras ( read_SCL () == 0 ) { // Estiramiento del reloj      // Deberías agregar tiempo de espera a este bucle } // Espere a que el destino escriba el valor SDA, mínimo 4 us para el modo estándar Retraso I2C (); // SCL es alto, lee el bit bit = leer_SDA ();   // Establezca SCL bajo en preparación para la siguiente operación borrar_SCL (); bit de retorno ; }// Escribe un byte en el bus I2C. Devuelve 0 si el destino lo confirma.bool i2c_write_byte ( bool enviar_inicio ,   bool enviar_detener ,  byte de carácter sin signo )  { bit sin signo ;  bocado de buey ;  si ( enviar_inicio ) {   condición de inicio i2c (); } para ( bit = 0 ; bit < 8 ; ++ bit ) {         i2c_write_bit (( byte y 0x80 ) != 0 );     byte <<= 1 ;   } nack = i2c_read_bit ();   si ( enviar_detener ) {   condición de parada i2c (); } volver nack ; }// Leer un byte del bus I2Ccarácter sin signo i2c_read_byte ( bool nack , bool send_stop )     { byte de carácter sin signo = 0 ;     bit de carácter sin signo ;   para ( bit = 0 ; bit < 8 ; ++ bit ) {         byte = ( byte << 1 ) | i2c_read_bit ();       } i2c_write_bit ( error ); si ( enviar_detener ) {   condición de parada i2c (); } byte de retorno ; }vacío I2C_delay ( vacío ) {  int volátil v ;   entero yo ;  para ( i = 0 ; i < I2CSPEED / 2 ; ++ i ) {           en ; }}

Compatibilidad con sistemas operativos

Herramientas de desarrollo

Al desarrollar o solucionar problemas de sistemas que utilizan I2C , la visibilidad a nivel de señales de hardware puede ser importante.

Adaptadores de host

Existen varias soluciones de hardware de adaptadores de host I2C para realizar una conexión de controlador o destino I2C a computadoras host que ejecuten Linux , Mac o Windows . La mayoría de las opciones son adaptadores USB a I2C . No todos requieren controladores o API propietarios .

Analizadores de protocolo

Los analizadores de protocolo I2C son herramientas que muestrean un bus I2C y decodifican las señales eléctricas para proporcionar una vista de nivel superior de los datos que se transmiten en el bus.

Analizadores lógicos

Al desarrollar y/o solucionar problemas del bus I2C, el examen de las señales de hardware puede ser muy importante. Los analizadores lógicos son herramientas que recopilan, analizan, decodifican y almacenan señales, de modo que las personas puedan ver las formas de onda de alta velocidad cuando lo deseen. Los analizadores lógicos muestran marcas de tiempo de cada cambio de nivel de señal, lo que puede ayudar a encontrar problemas de protocolo. La mayoría de los analizadores lógicos tienen la capacidad de decodificar señales de bus en datos de protocolo de alto nivel y mostrar datos ASCII.

Sistemas de cable populares

En varios módulos disponibles comercialmente, hay algunos conectores y pines principales: [29]

Limitaciones

La asignación de direcciones de destino es una debilidad del I2C . Siete bits es demasiado poco para evitar colisiones de direcciones entre los miles de dispositivos disponibles. Lo que alivia el problema de las colisiones de direcciones entre diferentes proveedores y también permite la conexión a varios dispositivos idénticos es que los fabricantes dedican pines que se pueden usar para configurar la dirección de destino en una de las pocas opciones de dirección por dispositivo. Dos o tres pines es lo típico y, con muchos dispositivos, hay tres o más opciones de cableado por pin de dirección. [34] [35] [36]

Las direcciones I2C de 10 bits aún no se utilizan ampliamente y muchos sistemas operativos host no las admiten. [37] Tampoco lo es el complejo esquema "ARP" de SMBus para asignar direcciones dinámicamente (excepto para tarjetas PCI con presencia de SMBus, para las que se requiere).

La configuración automática del bus es un problema relacionado. Una dirección dada puede ser utilizada por varios dispositivos incompatibles con distintos protocolos en varios sistemas, y casi ningún tipo de dispositivo puede ser detectado en tiempo de ejecución. Por ejemplo, 0x51puede ser utilizada por una EEPROM 24LC02 o 24C32 , con direccionamiento incompatible; o por un RTC PCF8563 , que no puede distinguirse de forma fiable de ninguno de los dos (sin cambiar el estado del dispositivo, lo que podría no estar permitido). Los únicos mecanismos de configuración fiables disponibles para los hosts implican mecanismos fuera de banda, como las tablas proporcionadas por el firmware del sistema, que enumeran los dispositivos disponibles. Nuevamente, este problema puede ser abordado parcialmente por ARP en sistemas SMBus, especialmente cuando se utilizan identificadores de proveedor y producto; pero eso no ha tenido realmente éxito. La versión Rev. 3 de la especificación I 2 C añade un mecanismo de identificación de dispositivo.

I 2 C admite un rango limitado de velocidades. Son raros los hosts que admiten velocidades de varios megabits. El soporte para la velocidad Fm+ de 1 Mbit/s está más extendido, ya que su electrónica son variantes simples de lo que se usa a velocidades más bajas. Muchos dispositivos no admiten la velocidad de 400 kbit/s (en parte porque SMBus aún no la admite). Los nodos I 2 C implementados en software (en lugar de hardware dedicado) pueden no admitir ni siquiera la velocidad de 100 kbit/s; por lo que el rango completo definido en la especificación rara vez se puede utilizar. Todos los dispositivos deben admitir al menos parcialmente la velocidad más alta utilizada o pueden detectar falsamente su dirección de dispositivo.

Los dispositivos pueden extender los ciclos de reloj para satisfacer sus necesidades particulares, lo que puede reducir el ancho de banda que necesitan los dispositivos más rápidos y aumentar las latencias al comunicarse con otras direcciones de dispositivos. La capacitancia del bus también impone un límite a la velocidad de transferencia, especialmente cuando no se utilizan fuentes de corriente para disminuir los tiempos de subida de la señal.

Debido a que I 2 C es un bus compartido, existe la posibilidad de que cualquier dispositivo tenga una falla y bloquee todo el bus. Por ejemplo, si algún dispositivo mantiene baja la línea SDA o SCL, evita que el controlador envíe comandos de INICIO o DETENCIÓN para reiniciar el bus. Por lo tanto, es común que los diseños incluyan una señal de reinicio que proporcione un método externo para reiniciar los dispositivos del bus. Sin embargo, muchos dispositivos no tienen un pin de reinicio dedicado, lo que obliga al diseñador a colocar circuitos que permitan que los dispositivos se apaguen y enciendan si es necesario reiniciarlos.

Debido a estos límites (gestión de direcciones, configuración del bus, posibles fallos, velocidad), pocos segmentos del bus I2C tienen siquiera una docena de dispositivos. En cambio, es habitual que los sistemas tengan varios segmentos más pequeños. Uno podría estar dedicado a su uso con dispositivos de alta velocidad, para la gestión de energía de baja latencia. Otro podría utilizarse para controlar unos pocos dispositivos en los que la latencia y el rendimiento no son cuestiones importantes; otro segmento podría utilizarse únicamente para leer chips EEPROM que describen tarjetas complementarias (como el estándar SPD utilizado con módulos DRAM).

En sistemas de muy baja potencia, las resistencias pull-up pueden consumir más energía que todo el resto del diseño combinado. En estos casos, las resistencias suelen recibir alimentación de una fuente de tensión conmutable, como una DIO de un microcontrolador. Las resistencias pull-up también limitan la velocidad del bus y tienen un pequeño coste adicional. Por ello, algunos diseñadores están recurriendo a otros buses seriales que no necesitan resistencias pull-up, como I3C o SPI .

Tecnologías derivadas

I 2 C es la base de ACCESS.bus , la interfaz VESA Display Data Channel (DDC), el bus de administración del sistema (SMBus), el bus de administración de energía (PMBus) y el bus de administración de plataforma inteligente (IPMB, uno de los protocolos de IPMI ). Estas variantes tienen diferencias en los rangos de voltaje y frecuencia de reloj, y pueden tener líneas de interrupción .

Los sistemas de alta disponibilidad ( AdvancedTCA , MicroTCA ) utilizan I2C redundante bidireccional para la gestión de los estantes. La capacidad de I2C de múltiples controladores es un requisito en estos sistemas.

TWI (Two-Wire Interface) o TWSI (Two-Wire Serial Interface) es esencialmente el mismo bus implementado en varios procesadores de sistema en chip de Atmel y otros proveedores. [38] Los proveedores usan el nombre TWI, aunque I 2 C no es una marca registrada al 7 de noviembre de 2014. [39] La protección de marca registrada solo existe para el logotipo respectivo (ver esquina superior derecha), y las patentes sobre I 2 C ahora han caducado. [ cita requerida ] Según Microchip Technology , TWI e I2C tienen algunas diferencias. Una de ellas es que TWI no admite el byte START. [40]

En algunos casos, el uso del término "interfaz de dos cables" indica una implementación incompleta de la especificación I2C . No admitir arbitraje o estiramiento del reloj es una limitación común, que sigue siendo útil para un solo controlador que se comunica con objetivos simples que nunca estiran el reloj.

El estándar de interfaz de sensor MIPI I3C (I3C) es un desarrollo de I 2 C, en desarrollo en 2017. [41]

Revisiones

Véase también

Referencias

  1. ^ "Comunicados de prensa financieros-NXP". investors.nxp.com . Consultado el 29 de abril de 2018 .
  2. ^ "MCP23008". Microchip . 26 de mayo de 2021. Archivado desde el original el 26 de mayo de 2021.
  3. ^ abcde "Especificación del bus I2C Rev 7" (PDF) . NXP Semiconductors . 1 de octubre de 2021. Archivado desde el original (PDF) el 6 de octubre de 2022.
  4. ^ "Direccionamiento de esclavos I2C de 7, 8 y 10 bits". Fase total . Archivado desde el original el 2013-06-01 . Consultado el 2018-04-29 .
  5. ^ "EEPROM de bus I2C serial de 8 Kbit (PDF)" (PDF) . STMicroelectronics . Octubre de 2017. Archivado (PDF) desde el original el 18 de octubre de 2019 . Consultado el 19 de noviembre de 2019 .
  6. ^ Uso de los protocolos ZONE_READ y ZONE_WRITE (PDF) (Nota de aplicación). Revisión 1.0.1. Foro de interfaz de administración del sistema. 2016-01-07. AN001. Archivado (PDF) desde el original el 2017-09-22.
  7. ^ "¿Existe alguna guía definitiva sobre la distribución de pines del I2C? No estoy buscando un "ESTÁNDAR"". StackExchange.
  8. ^ Nota de aplicación NXP AN11075: Conducción de señales de bus I2C a través de cables de par trenzado con PCA9605 (PDF) , 2017-08-16, archivado desde el original (PDF) el 2017-08-16
  9. ^ Vasquez, Joshua (16 de agosto de 2017), Dando el salto desde el tablero: una introducción a I2C sobre cables largos, archivado desde el original el 16 de agosto de 2017
  10. ^ Formato de placa apilable iPack, 19 de agosto de 2017, archivado desde el original el 19 de agosto de 2017
  11. ^ Ferrari, Mario; Ferrari, Giulio (29 de abril de 2018). Construcción de robots con LEGO Mindstorms NXT. Syngress. págs. 63–64. ISBN 9780080554334. Archivado desde el original el 29 de abril de 2018.
  12. ^ Gasperi, Michael; Hurbain, Philippe (2010), "Capítulo 13: Comunicación de bus I2C", Extreme NXT: Extendiendo LEGO MINDSTORMS NXT al siguiente nivel , ISBN 9781430224549
  13. ^ Philo. "Conector NXT" Archivado el 20 de agosto de 2017 en Wayback Machine.
  14. ^ Sivan Toledo. "Interfaz I2C, parte 1: agregar puertos de E/S digitales" Archivado el 12 de agosto de 2017 en Wayback Machine . 2006
  15. ^ "Envío de I2C de forma confiable a través de cables Cat5" Archivado el 18 de agosto de 2017 en Wayback Machine
  16. ^ "Conectores y cables de bus I2C" Archivado el 18 de agosto de 2017 en Wayback Machine
  17. ^ "Varios buses I2C · Wiki de Testato/SoftwareWire". GitHub .
  18. ^ "Compartiendo bus I2C | Microchip".
  19. ^ "Tabla de asignación de direcciones I2C" (PDF) (Guía de selección). Philips Semiconductors . 1999-08-24. Archivado desde el original (PDF) el 2017-10-16 . Consultado el 2017-10-01 .
  20. ^ Manual de datos IC12: Periféricos I2C, código de pedido de Philips 9397 750 00306
  21. ^ "Especificación del bus de administración del sistema (SMBus)" (PDF) . Versión 3.0. Foro de interfaz de administración del sistema. 2014-12-20. págs. 81–82. Archivado (PDF) desde el original el 2016-01-29 . Consultado el 2017-12-01 .
  22. ^ ab "Estándar VESA Display Data Channel Command Interface (DDC/CI)" (PDF) . Versión 1.1. VESA . 2004-10-29. págs. 15-16. Archivado (PDF) desde el original el 2016-09-09 . Consultado el 2017-12-01 .
  23. ^ "Especificación de interfaz de gestión de plataforma inteligente de segunda generación V2.0" (PDF) . Revisión del documento 1.1. Intel, NEC, Hewlett-Packard y Dell. 2013-10-01. p. 563. Archivado (PDF) desde el original el 2016-03-27 . Consultado el 2017-12-01 . La parte de 7 bits de la dirección esclava para el BMC es 0010_000b
  24. ^ Controlador de banda de bits TWI Master; Atmel; julio de 2012 Archivado el 29 de marzo de 2017 en Wayback Machine .
  25. ^ Componente i2c.resource Archivado el 24 de julio de 2011 en Wayback Machine para AmigaOS 4.x.
  26. ^ Theo de Raadt (29 de mayo de 2015). "/sys/dev/i2c/i2c_scan.c#probe_val". Referencia cruzada BSD del superusuario . OpenBSD . Consultado el 4 de marzo de 2019 .static u_int8_t probe_val[256];
  27. ^ Constantine A. Murenin (21 de mayo de 2010). "5.2. Escaneo del bus I 2 C a través de i2c_scan.c". Sensores de hardware OpenBSD: monitoreo ambiental y control de ventiladores ( tesis de maestría ). Universidad de Waterloo : UWSpace. hdl : 10012/5234. Identificador del documento: ab71498b6b1a60ff817b29d56997a418.
  28. ^ Introducción a HID sobre I2C
  29. ^ https://la-tecnologia.com/2022/05/04/the-connector-zoo-i2c-ecosystems/
  30. ^ https://www.sparkfun.com/qwiic
  31. ^ https://learn.adafruit.com/introduciendo-adafruit-stemma-qt
  32. ^ https://www.cable-tester.com/i2c-pin-out-grove-from-seeed-studio/
  33. ^ https://www.cable-tester.com/i2c-pin-out-from-gravity-dfrobot/
  34. ^ El LTC4151 de Linear Technology Archivado el 9 de agosto de 2017 en Wayback Machine tiene dos pines para la selección de direcciones, cada uno de los cuales puede conectarse alto o bajo o dejarse desconectado, lo que ofrece 9 direcciones diferentes.
  35. ^ MAX7314 de Maxim Archivado el 13 de julio de 2017 en Wayback Machine tiene un solo pin para la selección de dirección que se puede vincular alto o bajo o conectar a SDA o SCL, ofreciendo 4 direcciones diferentes.
  36. ^ UCD9224 de TI Archivado el 7 de noviembre de 2017 en Wayback Machine utiliza dos canales ADC que discriminan doce niveles cada uno para seleccionar cualquier dirección válida de 7 bits.
  37. ^ Delvare, Jean (16 de agosto de 2005). "Re: [PARCHE 4/5] agregar i2c_probe_device y i2c_remove_device". linux-kernel (Lista de correo). Archivado desde el original el 17 de agosto de 2016.
  38. ^ avr-libc: Ejemplo que utiliza la interfaz de dos cables (TWI) Archivado el 27 de mayo de 2007 en Wayback Machine .
  39. ^ "TESS -- Error". tmsearch.uspto.gov . Consultado el 29 de abril de 2018 .[ enlace muerto permanente ]
  40. ^ "¿Qué es TWI? Cómo configurar TWI para la comunicación I2C" (PDF) . Microchip Technology. 2018.
  41. ^ Thornton, Scott (29 de noviembre de 2017). "El circuito integrado mejorado (I3C)". Consejos sobre microcontroladores . Archivado desde el original el 3 de febrero de 2018.
  42. ^ Patente estadounidense 4689740, "Sistema de bus de dos cables que comprende un cable de reloj y un cable de datos para interconectar varias estaciones", expedida el 25 de agosto de 1987, asignada a US Philips Corporation 
  43. ^ "Philips demanda a ocho empresas más por infracción de la patente del bus I2C". EE Times . 17 de octubre de 2001. Archivado desde el original el 2 de abril de 2021.
  44. ^ Especificación de bus I2C Rev 2.0; Philips Semiconductors; diciembre de 1998; archivado.
  45. ^ Especificación de bus I2C Rev 2.1; Philips Semiconductors; enero de 2000; archivado.
  46. ^ Especificación de bus I2C Rev 3; NXP Semiconductors; 19 de junio de 2007; Archivado.
  47. ^ Especificación de bus I2C Rev 4; NXP Semiconductors; 13 de febrero de 2012; Archivado.
  48. ^ Especificación de bus I2C Rev 5; NXP Semiconductors; 9 de octubre de 2012; Archivado.
  49. ^ "Especificación del bus I2C Rev 6" (PDF) . NXP Semiconductors . 4 de abril de 2014. Archivado desde el original (PDF) el 26 de abril de 2021.

Lectura adicional

Enlaces externos