stringtranslate.com

I²C

I 2 C ( circuito interintegrado ; pronunciado como “ ojo-cuadrado- C ” o “ ojo-dos- C ”), conocido alternativamente como I2C o IIC , es un sistema síncrono , multimaestro/multiesclavo (controlador/objetivo). ), bus de comunicación en serie de un solo extremo inventado en 1982 por Philips Semiconductors . Se utiliza ampliamente para conectar circuitos integrados periféricos de baja 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 en el mercado productos I 2 C compatibles desde mediados de los años 1990.

El bus I 2 C se puede encontrar en una amplia gama de aplicaciones electrónicas donde la simplicidad y el bajo coste de fabricación son más importantes que la velocidad. Los componentes y sistemas de PC que involucran I 2 C son EEPROM de detección de presencia en serie (SPD) en módulos de memoria duales 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 más conocidas en microcontroladores son 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 pequeñas (por ejemplo, teléfonos básicos ) , cambio de retroiluminación, contraste, tono y color. ajustes de equilibrio, etc. en monitores (a través del canal de datos de visualización ), cambio de volumen del sonido en altavoces inteligentes, etc.

Una fortaleza particular del I 2 C es la capacidad de un microcontrolador para controlar una red de chips de dispositivos con sólo 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 serie (SPI), requieren más pines y señales para conectar múltiples dispositivos.

System Management Bus (SMBus), definido por Intel en 1995, es un subconjunto de I 2 C, 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 I 2 C modernos incorporan algunas políticas y reglas de SMBus, que a veces admiten tanto I 2 C como SMBus, y requieren sólo una reconfiguración mínima ya sea mediante comando o uso de pines de salida. La gestión del sistema para sistemas PC utiliza SMBus cuyos pines están ubicados en conectores PCI y PCI Express convencionales .

Expansor de E/S Microchip MCP23008 de 8 bits I 2 C en paquete 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 líneas bidireccionales de colector abierto o de drenaje abierto : la línea de datos en serie (SDA) y la línea de reloj en serie (SCL), levantadas 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 que rara vez se utiliza. [4] Las velocidades comunes del bus I 2 C son el  modo estándar de 100 kbit/s y el modo rápido de 400 kbit/s . También existe 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 ejecutarse 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 en sistemas integrados que en PC.

Tenga en cuenta que las velocidades de bits se cotizan para las transferencias entre el controlador (maestro) y el destino (esclavo) sin alargamiento del reloj ni otros gastos generales de hardware. Los gastos generales del 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 del usuario es más baja de lo que implicarían esas tasas de bits máximas por sí solas. Por ejemplo, si cada interacción con un objetivo permite de manera ineficiente transferir solo 1 byte de datos, la velocidad de datos será menos de la mitad de la velocidad de bits máxima.

El número de nodos que pueden existir en un determinado bus I 2 C está limitado por el espacio de direcciones y también por la capacitancia total del bus de 400  pF , lo que restringe las distancias prácticas de comunicación 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 antes mencionado es un bus con líneas de reloj (SCL) y de datos (SDA) con direccionamiento de 7 bits. El bus tiene dos roles para los nodos, ya sea controlador (maestro) o destino (esclavo):

El bus es un bus de múltiples controladores, lo que significa que puede estar presente cualquier número de nodos de controlador. Además, los roles de controlador y destino se pueden cambiar entre mensajes (después de enviar una DETENCIÓN).

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

Además de los bits de datos 0 y 1, el bus I 2 C permite señales especiales de INICIO y PARADA que actúan como delimitadores de mensajes y son distintas de los bits de datos. (Esto contrasta con los bits de inicio y de parada utilizados en la comunicación serie asíncrona , que se distinguen de los bits de datos sólo por su sincronización).

Inicialmente, el controlador está en modo de transmisión del controlador enviando un INICIO 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. Luego, el controlador continúa en modo 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).

La dirección y los bytes de datos se envían primero el bit más significativo . La condición inicial se indica mediante una transición de mayor a menor de SDA con SCL alto; la condición de parada 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 del controlador y el objetivo está en modo de recepción de objetivo).

Si el controlador desea leer del destino, recibe repetidamente un byte del destino y el controlador 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 objetivo está en modo de transmisión de objetivo).

Una transacción I 2 C puede constar de múltiples mensajes. El controlador termina un mensaje con una condición STOP si este es el final de la transacción o puede enviar otra condición START para retener 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 INICIO y termina con STOP:

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

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

Los sistemas Pure I 2 C soportan estructuras de mensajes arbitrarias. SMBus está restringido a nueve de esas estructuras, como leer palabra N y escribir palabra N , que involucran un solo objetivo. PMBus amplía SMBus con un protocolo de grupo , lo que permite enviar múltiples transacciones SMBus en un mensaje combinado. La STOP de terminación indica cuándo deben surtir efecto esas acciones agrupadas. Por ejemplo, una operación de PMBus podría reconfigurar tres fuentes de alimentación (usando tres direcciones de destino I 2 C diferentes) y sus nuevas configuraciones entrarían en vigor al mismo tiempo: cuando reciban esa PARADA.

Con sólo 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 del mensaje es específica del producto. Esas excepciones incluyen mensajes dirigidos a la dirección de llamada general I 2 C (0x00) o a la dirección de respuesta de alerta SMBus ; y mensajes involucrados en el Protocolo de resolución de direcciones (ARP) SMBus para la asignación y administración dinámica de direcciones.

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

Ejemplo de mensajería: EEPROM 24C32

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

Un ejemplo específico es la EEPROM 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 direcciones o comandos de un solo byte). Estos bytes se utilizan para direccionar bytes dentro del  espacio de direcciones EEPROM de 32 kbit (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 conteo y se pueden transferir más de 32 bytes a la vez. Las EEPROM I 2 C de menos de 32 kbit, como la 24C02 de 2 kbit, se utilizan a menudo en SMBus con transferencias de datos de un solo byte ineficientes para superar este problema.

Un solo mensaje se escribe en la EEPROM. Después del INICIO, el controlador envía la dirección del bus del chip con el bit de dirección limpio ( escribir ), luego envía la dirección de datos de dos bytes dentro de la EEPROM y luego envía bytes de datos para escribir comenzando en esa dirección, seguido de una DETECCIÓN. 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 de 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 INICIO, el controlador primero escribe la dirección del bus de ese chip con el bit de dirección limpio ( escribir ) y luego los dos bytes de la dirección de datos EEPROM. Luego envía un INICIO (repetido) y la dirección del bus de la EEPROM con el bit de dirección establecido ( leer ). La EEPROM luego responderá con los bytes de datos comenzando en la dirección de datos 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 una DETENCIÓN. La EEPROM incrementa la dirección después de cada byte de datos transferido; Las lecturas de varios bytes pueden recuperar todo el contenido de la EEPROM utilizando un mensaje combinado.

Capa fisica

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 SDA tienen un diseño de bus de drenaje abierto ( MOSFET ) o de colector abierto ( BJT ), por lo que se necesita una resistencia pull-up para cada línea. Se genera un "0" lógico al tirar de la línea a tierra, y se genera un "1" lógico al dejar que la línea flote (salida de alta impedancia ) para que la resistencia pull-up la levante. Una línea nunca se eleva activamente. Este cableado permite que múltiples nodos se conecten al bus sin cortocircuitos debidos a la 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 activar solo SCL o tanto SCL como SDA, para acomodar una capacitancia de bus más alta y permitir tiempos de subida más rápidos.

Una consecuencia importante de esto es que múltiples nodos pueden estar impulsando las líneas simultáneamente. Si algún nodo está bajando la línea, estará bajo. Los nodos que intentan transmitir uno lógico (es decir, dejar que la línea flote alto) pueden detectar esto y concluir que otro nodo está activo al mismo tiempo.

Cuando se utiliza en SCL, esto se denomina ampliación 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 altas. Para iniciar una transacción, SDA baja mientras SCL permanece alto. Es ilegal [3] : 14  transmitir un marcador de parada liberando el SDA para que flote alto nuevamente (aunque ese "mensaje nulo" suele ser inofensivo), por lo que el siguiente paso es bajar el SCL.

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

Mientras SCL está bajo, el transmisor (inicialmente el controlador) configura SDA en el valor deseado y (después de un pequeño retraso para permitir que el valor se propague) deja que SCL flote alto. Luego, el controlador espera a que 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 SCL está alto, el controlador espera un tiempo mínimo (4 μs para velocidad estándar I 2 C) para asegurarse de que el receptor haya visto la broca y luego la baja nuevamente. 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 "acuse de recibo" en la otra dirección. El transmisor y el receptor intercambian funciones por un bit, y el receptor original transmite un único bit "0" (ACK). Si el transmisor ve un bit "1" (NACK), 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 usando SCL

Una de las características más importantes del protocolo I 2 C es la ampliación 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. Es posible que el controlador que se comunica con el objetivo no finalice la transmisión del bit actual, pero debe esperar hasta que la línea de reloj realmente suba. Si el objetivo se está alargando el reloj, la línea del reloj seguirá siendo baja (porque las conexiones son de drenaje abierto ). Lo mismo ocurre si un segundo controlador, más lento, intenta hacer funcionar el reloj al mismo tiempo. (Si hay más de un controlador, todos menos uno normalmente perderán el arbitraje).

El controlador debe esperar hasta que observe que la línea del reloj aumenta y un tiempo mínimo adicional (4 μs para el estándar 100 kbit/s I 2 C) antes de volver a bajar el reloj.

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 usa solo cuando los objetivos lo hacen. Aunque en teoría se puede alargar cualquier impulso de reloj, generalmente son los intervalos antes o después del bit de confirmación 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 envía un reconocimiento positivo o un NACK.

La extensión del reloj es el único momento en I 2 C donde el objetivo impulsa SCL. Muchos objetivos no necesitan estirar el reloj y, por lo tanto, tratan a SCL estrictamente como una entrada sin circuitos que la impulsen. Es posible que algunos controladores, como los que se encuentran dentro de los ASIC personalizados , no admitan la ampliación del reloj; A menudo, estos dispositivos estarán etiquetados como "interfaz de dos cables" y no como I 2 C.

Para garantizar un rendimiento mínimo del bus , SMBus impone límites a la extensión de los relojes. Los hosts y objetivos que se adhieran a esos límites no pueden bloquear el acceso al autobús por más de un corto período de tiempo, lo cual no es una garantía que ofrecen los sistemas I 2 C puros.

Arbitraje utilizando SDA

Cada controlador monitorea el bus en busca de bits de inicio y parada 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 se produce el arbitraje. El modo de transmisión de destino también se puede arbitrar cuando un controlador aborda múltiples objetivos, pero esto es menos común. A diferencia de los protocolos (como Ethernet ) que utilizan retrasos aleatorios 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 esperados; si no coinciden, ese transmisor ha perdido el arbitraje y abandona esta interacción de protocolo.

Si un transmisor configura SDA en 1 (sin generar señal) y un segundo transmisor lo configura en 0 (tracción 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 al esperado y concluye que otro nodo está transmitiendo. El primer nodo que nota tal diferencia es el que pierde el arbitraje: deja de impulsar SDA. Si es un controlador, también deja de manejar SCL y espera un STOP; entonces 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 el momento la señal ha sido exactamente la esperada; ningún otro transmisor ha perturbado su mensaje.

Si los dos controladores envían un mensaje a dos objetivos diferentes, el que envía la dirección de destino inferior 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 se refieren a múltiples objetivos, el arbitraje a veces debe continuar hasta las etapas de datos.

El arbitraje ocurre muy raramente, pero es necesario para lograr un soporte adecuado para múltiples controladores. Al igual que con la ampliación del reloj, no todos los dispositivos admiten el arbitraje. Aquellos que lo hacen, generalmente se etiquetan como compatibles con la comunicación "multicontrolador".

Un caso que debe manejarse con cuidado en implementaciones I 2 C con múltiples controladores es el de los controladores hablando entre sí. Un controlador puede perder el arbitraje debido a un mensaje entrante y debe cambiar su función de controlador a objetivo a tiempo para reconocer su propia dirección.

En el caso extremadamente raro de que dos controladores envíen simultáneamente mensajes idénticos, ambos considerarán que la comunicación fue exitosa, pero el objetivo solo verá un mensaje. Por esta razón, 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 pueda emitir ese comando en un momento dado. .)

Arbitraje en SMBus

Mientras que I 2 C sólo 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

PMBus versión 1.3 amplía el protocolo de respuesta de alerta SMBus en su protocolo de "lectura de zona". [6] Los objetivos pueden agruparse en "zonas", y todos los objetivos en una zona pueden ser dirigidos para responder, con sus respuestas enmascaradas (omitiendo información no deseada), invertidas (por lo que la información deseada se envía como 0 bits, que ganan el arbitraje), o reordenarse (para que la información más importante 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 I 2 C 0x28 y 0x37 para lecturas y escrituras de zona, respectivamente.

Diferencias entre modos

Hay varios modos de funcionamiento posibles para la comunicación I 2 C. Todos son compatibles en el sentido de que siempre se puede usar el modo estándar de 100 kbit/s , pero combinar dispositivos de diferentes capacidades en el mismo bus puede causar problemas, como se muestra a continuación:

Algunos proveedores ofrecen el llamado 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(los) controlador(es) y un bus más largo de lo normal puede operarse a una velocidad más lenta que la nominal mediante subclocking .

Interconexiones de circuitos

Una placa ADC de 16 bits con interfaz I 2 C

I 2 C es popular para conectar circuitos periféricos a sistemas de creación de prototipos, como Arduino y Raspberry Pi . I 2 C no emplea un conector estandarizado; sin embargo, los diseñadores de placas han creado varios esquemas de cableado para las interconexiones I 2 C. 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 alternas de señal y alimentación de los siguientes esquemas de cableado: (GND, SCL, VCC, SDA) o (VCC, SDA, GND, SCL) . [7]

La gran mayoría de las aplicaciones utilizan I 2 C 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, en distancias relativamente cortas de menos de 1 pie (30 cm), sin conector. . Sin embargo, utilizando un controlador diferencial, una versión alternativa de I 2 C puede comunicarse hasta 20 metros (posiblemente más de 100 metros) a través de CAT5 u otro cable. [8] [9]

Varios conectores estándar transportan señales I 2 C. Por ejemplo, el conector UEXT lleva I 2 C; el conector iPack de 10 pines lleva I 2 C; [10] el conector 6P6C Lego Mindstorms NXT lleva I 2 C; [11] [12] [13] [14] algunas personas usan los conectores 8P8C y el cable CAT5 que normalmente se usa para la capa física de Ethernet para transportar señales I 2 C con codificación diferencial [15] o señales I 2 C amplificadas de un solo extremo ; [16] y todos los conectores HDMI y la mayoría de DVI y VGA transportan datos DDC2 a través de I 2 C.

Almacenamiento en búfer y multiplexación

Cuando hay muchos dispositivos I 2 C 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 un multiplexor separe varios dispositivos con la misma dirección. Existen muchos tipos de multiplexores y buffers y todos deben tener en cuenta el hecho de que las líneas I 2 C están especificadas para ser bidireccionales. Los multiplexores se pueden implementar con interruptores analógicos, que pueden unir un segmento a otro. Los interruptores 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 almacenamiento en búfer.

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 amortiguadores para líneas bidireccionales como I 2 C deben utilizar uno de varios esquemas para evitar el enganche. I 2 C es de drenaje abierto, por lo que los amortiguadores deben generar un nivel bajo en un lado cuando ven un nivel bajo en el otro. Un método para evitar el enganche es que un búfer tenga niveles de entrada y salida cuidadosamente seleccionados de modo que el nivel de salida de su controlador sea superior a su umbral de entrada, evitando que se active. Por ejemplo, un búfer 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 múltiples búferes implementan esto. El esquema no se puede poner en serie entre sí.

Alternativamente, existen otros tipos de buffers que implementan amplificadores de corriente o realizan un seguimiento del estado (es decir, de qué lado el bus está bajo) para evitar el enganche. El método de estado generalmente significa que se crea un pulso no intencionado durante una transferencia cuando un lado está bajando el bus, luego el otro lo baja y luego el primer lado lo libera (esto es común durante un reconocimiento de I 2 C ).

Compartir SCL entre múltiples autobuses

Cuando se tiene un único controlador, es posible que varios buses I 2 C compartan la misma línea SCL. [17] [18] Los paquetes en cada bus se envían uno tras otro o al mismo tiempo. Esto es posible porque la comunicación en cada bus se puede subdividir alternando períodos cortos con SCL alto seguidos de períodos cortos con SCL bajo. Y el tiempo se puede alargar si un autobús 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 estado de línea

Estas tablas muestran los diversos estados atómicos y operaciones de bits que pueden ocurrir durante un mensaje I 2 C.

Estructura de direccionamiento

direccionamiento de 7 bits

direccionamiento de 10 bits

Direcciones reservadas en espacio de direcciones de 7 bits

Se reservan dos grupos de direcciones para funciones especiales:

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

Esto deja un total de 107 direcciones de 7 bits sin reservas en común entre I 2 C, SMBus y PMBus.


Direcciones no reservadas en espacio de direcciones de 7 bits

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

Formato de transacción

Una transacción I 2 C 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 parada. Los símbolos de inicio después del primero, que inician un mensaje pero no 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 único mensaje se denomina transacción de lectura o escritura. Una transacción que consta de varios mensajes se denomina transacción combinada. La forma más común de este último es un mensaje de escritura que proporciona información de dirección dentro del dispositivo, seguido de un mensaje de lectura.

Muchos dispositivos I 2 C 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 única transacción; Los objetivos tienen prohibido responder si observan un símbolo de parada. 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 tiempo

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 el descenso del SDA mientras que el SCL permanece alto.
  2. SCL se baja y SDA establece el primer nivel de bit de datos mientras mantiene SCL bajo (durante el tiempo de la barra azul).
  3. Los datos se muestrean (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 (el tiempo completo 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 baja en preparación para el bit de parada .
  6. Se señala una condición de parada (P) cuando SCL aumenta, seguido por un aumento de SDA.

Para evitar la detección de marcadores falsos, existe 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 acuses de recibo) contiene n + 1 pulsos de reloj.

Diseño de software

I 2 C se presta a un diseño de software de "conductor de autobús". El software para dispositivos conectados está escrito para llamar a un "controlador de bus" que maneja el hardware I 2 C real de bajo nivel . Esto permite que el código del controlador de los dispositivos conectados se transfiera fácilmente a otro hardware, incluido un diseño de bits.

Ejemplo de bit-banging del protocolo I 2 C

A continuación se muestra un ejemplo de cómo modificar los bits del protocolo I 2 C como controlador I 2 C (maestro). El ejemplo está escrito en pseudo C. Ilustra todas las características de I 2 C descritas anteriormente (estiramiento de reloj, arbitraje, bit de inicio/parada, confirmación/desconexión). [24]

// Funciones de soporte específicas del hardware que DEBEN personalizarse:#definir I2CSPEED 100anular I2C_delay ( anular ); bool read_SCL ( nulo ); // Devuelve el nivel actual de la línea SCL, 0 o 1  bool read_SDA ( nulo ); // Devuelve el nivel actual de la línea SDA, 0 o 1  vacío set_SCL ( vacío ); // No conduzca SCL (fije el pin de alta impedancia)  anular clear_SCL ( anular ); // Maneja activamente la señal SCL baja  vacío set_SDA ( vacío ); // No conduzca SDA (fije el pin en alta impedancia)  anular clear_SDA ( anular ); // Maneja activamente la señal SDA baja  nulo arbitration_lost ( nulo ); bool iniciado = falso ; //datos globales    anular i2c_start_cond ( anular ) { si ( comenzó ) {    // si se inició, realizar una condición de reinicio // establece SDA en 1 set_SDA (); I2C_retraso (); set_SCL (); while ( read_SCL () == 0 ) { // Ampliación del reloj      // Deberías agregar tiempo de espera a este bucle } // Tiempo de configuración de inicio repetido, mínimo 4,7us I2C_retraso (); } si ( read_SDA () == 0 ) {     arbitraje_perdido (); } // SCL es alto, configure SDA de 1 a 0. claro_SDA (); I2C_retraso (); clear_SCL (); iniciado = verdadero ;  }anular i2c_stop_cond ( anular ) { // establece SDA en 0 claro_SDA (); I2C_retraso (); set_SCL (); // Estiramiento del reloj mientras ( read_SCL () == 0 ) {     // agrega tiempo de espera a este bucle. } // Tiempo de configuración del bit de parada, mínimo 4us I2C_retraso (); // SCL es alto, configura SDA de 0 a 1 set_SDA (); I2C_retraso (); si ( read_SDA () == 0 ) {     arbitraje_perdido (); } iniciado = falso ;  }// Escribe un bit en el bus I2Canular i2c_write_bit ( bit bool )  { si ( poco ) {   set_SDA (); } demás {   claro_SDA (); } // retraso en la propagación del cambio SDA I2C_retraso (); // Establece SCL alto para indicar que hay disponible un nuevo valor SDA válido set_SCL (); // Espere a que el objetivo lea el valor SDA, mínimo de 4us para el modo estándar I2C_retraso (); while ( read_SCL () == 0 ) { // Ampliación del reloj      // Deberías agregar tiempo de espera a este bucle } // SCL es alto, ahora los datos son válidos // Si el SDA es alto, verifique que nadie más esté conduciendo el SDA si ( bit && ( read_SDA () == 0 )) {       arbitraje_perdido (); } // Borrar el SCL a bajo en preparación para el próximo cambio clear_SCL ();}// Leer un poco del bus I2Cbool i2c_read_bit ( nulo ) { bit booleano ;  // Deja que el objetivo conduzca los datos set_SDA (); // Espere a que el destino escriba el valor SDA, mínimo de 4us para el modo estándar I2C_retraso (); // Establece SCL alto para indicar que hay disponible un nuevo valor SDA válido set_SCL (); while ( read_SCL () == 0 ) { // Ampliación del reloj      // Deberías agregar tiempo de espera a este bucle } // Espere a que el destino escriba el valor SDA, mínimo de 4us para el modo estándar I2C_retraso (); // SCL es alto, lee el bit bit = read_SDA ();   // Establecer SCL bajo en preparación para la siguiente operación clear_SCL (); bit de retorno ; }// Escribe un byte en el bus I2C. Devuelve 0 si el objetivo lo ataca.bool i2c_write_byte ( bool send_start ,   bool enviar_detener ,  byte de caracteres sin firmar )  { bit sin firmar ;  bool nack ;  si ( enviar_inicio ) {   i2c_start_cond (); } para ( bit = 0 ; bit < 8 ; ++ bit ) {         i2c_write_bit (( byte y 0x80 ) ! = 0 );     byte <<= 1 ;   } nack = i2c_read_bit ();   si ( enviar_detener ) {   i2c_stop_cond (); } volver atrás ; }// Lee un byte del bus I2Ccarácter sin firmar i2c_read_byte ( bool nack , bool send_stop )     { byte de carácter sin firmar = 0 ;     bit de carácter sin firmar ;   para ( bit = 0 ; bit < 8 ; ++ bit ) {         byte = ( byte << 1 ) | i2c_read_bit ();       } i2c_write_bit ( después ); si ( enviar_detener ) {   i2c_stop_cond (); } byte de retorno ; }anular I2C_delay ( anular ) {  volátil int v ;   int yo ;  para ( yo = 0 ; yo < I2CSPEED / 2 ; ++ yo ) {           v ; }}

Soporte del sistema operativo

Herramientas de desarrollo

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

Adaptadores de host

Hay varias soluciones de hardware de adaptador de host I 2 C para realizar un controlador I 2 C o una conexión de destino a computadoras host que ejecutan Linux , Mac o Windows . La mayoría de las opciones son adaptadores USB a I 2 C. No todos requieren controladores o API propietarios .

Analizadores de protocolos

Los analizadores de protocolo I 2 C son herramientas que toman muestras de un bus I 2 C 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 I 2 C, el examen de las señales del hardware puede ser muy importante. Los analizadores lógicos son herramientas que recopilan, analizan, decodifican y almacenan señales, para que las personas puedan ver las formas de onda de alta velocidad cuando quieran. 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.

Limitaciones

En sistemas de baja potencia, las resistencias pull-up pueden consumir más energía que el resto del diseño combinado. En estos, las resistencias suelen estar alimentadas por una fuente de voltaje conmutable, como un DIO de un microcontrolador. Las pull-ups también limitan la velocidad del autobús y tienen un pequeño coste adicional. Por lo tanto, algunos diseñadores están recurriendo a otros buses en serie, por ejemplo, I3C o SPI , que no necesitan pull-ups.

La asignación de direcciones de destino es una debilidad de I 2 C. Siete bits es muy 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 conectarse a varios dispositivos idénticos es que los fabricantes dedican pines que pueden usarse para configurar la dirección de destino en una de las pocas opciones de dirección por dispositivo. Lo normal es tener dos o tres pines y, con muchos dispositivos, hay tres o más opciones de cableado por pin de dirección. [29] [30] [31]

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

La configuración automática del bus es un tema relacionado. Una dirección determinada puede ser utilizada por varios dispositivos diferentes con protocolos incompatibles en varios sistemas, y casi ningún tipo de dispositivo puede detectarse en tiempo de ejecución. Por ejemplo, 0x51puede ser utilizado por una EEPROM 24LC02 o 24C32 , con direccionamiento incompatible; o por un RTC PCF8563 , que no se puede distinguir de manera confiable de ninguno de los dos (sin cambiar el estado del dispositivo, lo que podría no estar permitido). Los únicos mecanismos de configuración confiables disponibles para los hosts involucran mecanismos fuera de banda, como tablas proporcionadas por el firmware del sistema, que enumeran los dispositivos disponibles. Nuevamente, este problema puede solucionarse parcialmente mediante ARP en sistemas SMBus, especialmente cuando se utilizan identificadores de proveedores y productos; pero eso realmente no se ha popularizado. La versión Rev. 3 de la especificación I 2 C agrega un mecanismo de identificación de dispositivo.

I 2 C admite un rango limitado de velocidades. Los hosts que soportan velocidades de varios megabits son raros. El soporte para la velocidad Fm+ 1 Mbit/s está más extendido, ya que su electrónica son variantes simples de la que se utiliza 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 ni siquiera soportar la velocidad de 100 kbit/s; por lo que rara vez se puede utilizar todo el rango definido en la especificación. Todos los dispositivos deben admitir al menos parcialmente la velocidad más alta utilizada o pueden detectar falsamente la dirección de su dispositivo.

A los dispositivos se les permite estirar 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 hablar 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 cuelgue todo el bus. Por ejemplo, si algún dispositivo mantiene baja la línea SDA o SCL, impide que el controlador envíe comandos START o STOP para restablecer 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 instalar circuitos que permitan reiniciar los dispositivos si es necesario reiniciarlos.

Debido a estos límites (gestión de direcciones, configuración del bus, posibles fallos, velocidad), pocos segmentos del bus I 2 C tienen siquiera una docena de dispositivos. Es común que los sistemas tengan varios de estos segmentos. Uno podría estar dedicado a dispositivos de alta velocidad, para administración de energía de baja latencia. Otro podría usarse para controlar algunos dispositivos donde la latencia y el rendimiento no son cuestiones importantes; otro segmento más podría usarse solo para leer chips EEPROM que describen tarjetas adicionales (como el estándar SPD usado con unidades DRAM).

Tecnologías derivadas

I 2 C es la base para ACCESS.bus , la interfaz VESA Display Data Channel (DDC), el System Management Bus (SMBus), el Power Management Bus (PMBus) y el Intelligent Platform Management Bus (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 I 2 C redundante de 2 vías para la gestión de estanterías. La capacidad de múltiples controladores I 2 C es un requisito en estos sistemas.

TWI (interfaz de dos cables) o TWSI (interfaz serie de dos cables) es esencialmente el mismo bus implementado en varios procesadores de sistema en chip de Atmel y otros proveedores. [33] Los proveedores utilizan el nombre TWI, aunque I 2 C no es una marca registrada a partir del 7 de noviembre de 2014. [34] La protección de marca sólo existe para el logotipo respectivo (ver esquina superior derecha), y las patentes sobre I 2 C ya han caducado. [ cita necesaria ] Según Microchip Technology , TWI e I2C tienen algunas diferencias. Uno de ellos es que TWI no admite el byte de INICIO. [35]

En algunos casos, el uso del término "interfaz de dos hilos" indica una implementación incompleta de la especificación I 2 C. No admitir el arbitraje o la ampliación del reloj es una limitación común, que sigue siendo útil para un único controlador que se comunica con objetivos simples que nunca alargan el reloj.

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

Revisiones

Ver también

Referencias

  1. ^ "Comunicados de prensa financieros-NXP". inversores.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) . Semiconductores NXP . 1 de octubre de 2021. Archivado desde el original (PDF) el 6 de octubre de 2022.
  4. ^ "Direccionamiento esclavo I2C de 7, 8 y 10 bits". Fase Total . Archivado desde el original el 1 de junio de 2013 . Consultado el 29 de abril de 2018 .
  5. ^ "EEPROM de bus I2C serie de 8 Kbit (PDF)" (PDF) . STMicroelectrónica . 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 gestión del sistema. 2016-01-07. AN001. Archivado (PDF) desde el original el 22 de septiembre de 2017.
  7. ^ "¿Existe alguna guía definitiva de asignación de pines I2C? No busco un" ESTÁNDAR"". Intercambio de pila.
  8. ^ Nota de aplicación de 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: una introducción a I2C a través de cables largos, archivado desde el original el 16 de agosto de 2017
  10. ^ Formato de tablero apilable iPack, 2017-08-19, archivado desde el original el 2017-08-19
  11. ^ Ferrari, Mario; Ferrari, Giulio (29 de abril de 2018). Construyendo Robots con LEGO Mindstorms NXT. Singreso. 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 por bus I2C", Extreme NXT: Extendiendo LEGO MINDSTORMS NXT al siguiente nivel , ISBN 9781430224549
  13. ^ Filón. "Conector NXT" Archivado el 20 de agosto de 2017 en Wayback Machine.
  14. ^ Siván 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 manera confiable a través de cables Cat5" Archivado el 18 de agosto de 2017 en Wayback Machine.
  16. ^ "Cables y conectores de bus I2C" Archivado el 18 de agosto de 2017 en Wayback Machine.
  17. ^ "Múltiples buses I2C · Testato/SoftwareWire Wiki". GitHub .
  18. ^ "Compartir bus I2C | Microchip".
  19. ^ "Tabla de asignación de direcciones I2C" (PDF) (Guía de selección). Semiconductores Philips . 24 de agosto de 1999. Archivado desde el original (PDF) el 16 de octubre de 2017 . Consultado el 1 de octubre de 2017 .
  20. ^ Manual de datos IC12: Periféricos I2C, código de pedido de Philips 9397 750 00306
  21. ^ "Especificación del bus de gestión del sistema (SMBus)" (PDF) . Versión 3.0. Foro de interfaz de gestión del sistema. 2014-12-20. págs. 81–82. Archivado (PDF) desde el original el 29 de enero de 2016 . Consultado el 1 de diciembre de 2017 .
  22. ^ ab "Estándar de interfaz de comando de canal de datos de pantalla VESA (DDC/CI)" (PDF) . Versión 1.1. VESA . 2004-10-29. págs. 15-16. Archivado (PDF) desde el original el 9 de septiembre de 2016 . Consultado el 1 de diciembre de 2017 .
  23. ^ "Especificación de interfaz de gestión de plataforma inteligente Segunda generación V2.0" (PDF) . Revisión del Documento 1.1. Intel, NEC, Hewlett-Packard y Dell. 2013-10-01. pag. 563. Archivado (PDF) desde el original el 27 de marzo de 2016 . Consultado el 1 de diciembre de 2017 . La parte de 7 bits de la dirección esclava del BMC es 0010_000b
  24. ^ Controlador de banda de bits maestro TWI; 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. ^ Constantino 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 MMath ). Universidad de Waterloo : UWSpace. hdl :10012/5234. ID del documento: ab71498b6b1a60ff817b29d56997a418.
  28. ^ Introducción a HID sobre I2C
  29. ^ 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 se puede vincular alto o bajo o dejar desconectado, ofreciendo 9 direcciones diferentes.
  30. ^ MAX7314 de Maxim Archivado el 13 de julio de 2017 en Wayback Machine tiene un solo pin para que la selección de direcciones esté vinculada a alto o bajo o conectada a SDA o SCL, y ofrece 4 direcciones diferentes.
  31. ^ 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.
  32. ^ Delvare, Jean (16 de agosto de 2005). "Re: [PARCHE 4/5] agregar i2c_probe_device e i2c_remove_device". kernel-linux (lista de correo). Archivado desde el original el 17 de agosto de 2016.
  33. avr-libc: Ejemplo usando la interfaz de dos hilos (TWI) Archivado el 27 de mayo de 2007 en Wayback Machine .
  34. ^ "TESS - Error". tmsearch.uspto.gov . Consultado el 29 de abril de 2018 .[ enlace muerto permanente ]
  35. ^ "¿Qué es TWI? Cómo configurar TWI para comunicación I2C" (PDF) . Tecnología de microchips. 2018.
  36. ^ Thornton, Scott (29 de noviembre de 2017). "El circuito interintegrado mejorado (I3C)". Consejos para el microcontrolador . Archivado desde el original el 3 de febrero de 2018.
  37. ^ Patente de EE. UU. 4689740, "Sistema de bus de dos cables que comprende un cable de reloj y un cable de datos para interconectar varias estaciones", emitida el 25 de agosto de 1987, asignada a US Philips Corporation 
  38. ^ "Philips demanda a ocho empresas más por infracción de la patente del autobús I2C". Tiempos EE.UU. 17 de octubre de 2001. Archivado desde el original el 2 de abril de 2021.
  39. ^ Especificación del bus I2C Rev 2.0; Semiconductores Philips; diciembre de 1998; Archivado.
  40. ^ Especificación del bus I2C Rev 2.1; Semiconductores Philips; enero de 2000; Archivado.
  41. ^ Especificación del bus I2C Rev 3; Semiconductores NXP; 19 de junio de 2007; Archivado.
  42. ^ Especificación del bus I2C Rev 4; Semiconductores NXP; 13 de febrero de 2012; Archivado.
  43. ^ Especificación del bus I2C Rev 5; Semiconductores NXP; 9 de octubre de 2012; Archivado.
  44. ^ "Especificación del bus I2C Rev 6" (PDF) . Semiconductores NXP . 4 de abril de 2014. Archivado desde el original (PDF) el 26 de abril de 2021.

Otras lecturas

enlaces externos