I²C

Serial comunication bus

No confundir con I²S .

Bus I ² C

Tipo	Bus de comunicación serial
Historial de producción
Diseñador	Philips Semiconductor , conocido hoy como NXP Semiconductors
Diseñado	1982 ; Hace 39 años (1982)
Datos
Señal de datos	Colector abierto o drenaje abierto
Ancho	1 bit (SDA) con reloj independiente (SCL)
Bitrate	0,1, 0,4, 1,0, 3,4 o 5,0  Mbit / s según el modo
Protocolo	Serie , semidúplex

I ² C ( Inter-Integrated Circuit ), pronunciado I-squared-C , es un bus de comunicación serie síncrono , multimaestro, multiesclavo , conmutado por paquetes , de un solo extremo , inventado en 1982 por Philips Semiconductor (ahora NXP Semiconductors ) . Se utiliza ampliamente para conectar circuitos integrados periféricos de baja velocidad a procesadores y microcontroladores en comunicaciones intraplaca de corta distancia. Alternativamente, I ² C a veces se escribe I2C (pronunciado I-dos-C) o IIC (pronunciado IIC).

Varios competidores, como Siemens (más tarde Infineon Technologies , ahora Intel Mobile Communications ), NEC , Texas Instruments , STMicroelectronics (antes SGS-Thomson), Motorola (más tarde Freescale , ahora fusionada con NXP), ^[1] Nordic Semiconductor e Intersil , han introdujo productos compatibles con I ² C en el mercado desde mediados de la década de 1990.

System Management Bus (SMBus), definido por Intel en 1995, es un subconjunto de I ² C, que define un uso más estricto. Uno de los objetivos de SMBus es promover la solidez y la interoperabilidad. En consecuencia, los sistemas I ² C modernos incorporan algunas políticas y reglas de SMBus, que a veces admiten tanto I ² C como SMBus, lo que requiere solo una reconfiguración mínima, ya sea mediante el uso de pines de salida o de comando.

Aplicaciones

STMicroelectronics 24C08: EEPROM serial con bus I ² C ^[2]

Una placa ADC de 16 bits con interfaz I ² C

Este artículo está en formato de lista , pero puede leerse mejor en prosa . Puede ayudar convirtiendo este artículo , si corresponde. La ayuda para la edición está disponible. ( Noviembre de 2020 )

I ² C es apropiado para periféricos donde la simplicidad y el bajo costo de fabricación son más importantes que la velocidad. Las aplicaciones comunes del bus I ² C son:

• Describir dispositivos conectables a través de pequeñas tablas de configuración de ROM para permitir la operación plug and play , como en EEPROM de detección de presencia en serie (SPD) en módulos de memoria duales en línea (DIMM) y datos de identificación de pantalla extendida (EDID) para monitores a través de VGA , DVI y conectores HDMI .
• Gestión de sistemas para sistemas de PC a través de SMBus ; Pasadores de SMBus se asignan en ambos convencional PCI y PCI Express conectores.
• Acceso a relojes en tiempo real y chips NVRAM que mantienen la configuración del usuario.
• Acceso a DAC y ADC de baja velocidad .
• Cambiar la configuración de contraste, tono y balance de color en monitores (a través del canal de datos de pantalla ).
• Cambio de volumen de sonido en altavoces inteligentes.
• Control de pantallas OLED o LCD pequeñas (p. Ej. , Teléfonos de funciones ) .
• Lectura de monitores de hardware y sensores de diagnóstico, por ejemplo, la velocidad de un ventilador.
• Encendido y apagado de la fuente de alimentación de los componentes del sistema. ^[3]

Una fortaleza particular de I ² C 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 que se utilizan en aplicaciones similares, como el bus de interfaz de periféricos en serie (SPI), requieren más pines y señales para conectar varios dispositivos.

Revisiones

Historial de lanzamientos de especificaciones I ² C

Año	Versión	Velocidad máxima	Notas	PDF
1981	Patentar	n / A	Patente de Estados Unidos 4.689.740 presentada el 2 de noviembre de 1981 por US Philips Corporation.	[4] [5]
mil novecientos ochenta y dos	Original	100 kbit / s	El sistema I 2 C se creó como un sistema de bus interno simple para la electrónica de control de edificios con varios chips de Philips.	n / A
1992	1	400 kbit / s	Se agregó el modo rápido (Fm) y un modo de direccionamiento de 10 bits para aumentar la capacidad a 1008 nodos. Esta fue la primera versión estandarizada.	n / A
1998	2	3,4 Mbit / s	Se agregó el modo de alta velocidad (Hs) con requisitos de ahorro de energía para voltaje y corriente eléctricos.	n / A
2000	2.1	3,4 Mbit / s	Versión 2 clarificada, sin cambios funcionales significativos.	[6]
2007	3	1 Mbit / s	Se agregó Fast-mode plus (Fm +) (usando controladores de 20 mA) y un mecanismo de identificación de dispositivo.	[7]
2012	4	5 Mbit / s	Se agregó el modo ultrarrápido (UFm) para las nuevas líneas USDA (datos) y USCL (reloj) utilizando lógica push-pull sin resistencias pull-up , y se agregó una tabla de identificación de fabricante asignada. Es solo un bus unidireccional .	[8]
2012	5	5 Mbit / s	Errores corregidos.	[9]
2014	6	5 Mbit / s	Se corrigieron dos gráficos. Este es el estándar actual.	[10]

Diseño

Un ejemplo de esquema con un maestro (un microcontrolador ), tres nodos esclavos (un ADC , un DAC y un microcontrolador) y resistencias pull-up R _p

I ² C usa solo dos colectores abiertos bidireccionales o líneas de drenaje abiertas , Línea de datos en serie (SDA) y Línea de reloj en serie (SCL), levantadas con resistencias . ^[10] 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 ² C tiene un espacio de direcciones de 7 bits , con una extensión de 10 bits que rara vez se usa. ^[11] Las velocidades de bus I ² C comunes son el modo estándar de 100  kbit / sy 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 recientes de I ² C pueden albergar más nodos y correr a velocidades más rápidas (/ s 400 kbit modo rápido , 1 Mbit / s modo rápido plus , 3,4  Mbit / s modo de alta velocidad, y 5  Mbit / s Ultra Fast-mode ). 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 maestro y el esclavo sin alargar el reloj u otra sobrecarga de hardware. Los gastos generales del protocolo incluyen una dirección esclava y quizás una dirección de registro dentro del dispositivo esclavo, así como bits ACK / NACK por byte. Por lo tanto, la tasa de transferencia real de datos de usuario es menor de lo que implicarían las tasas de bits máximas por sí solas. Por ejemplo, si cada interacción con un esclavo permite de manera ineficaz la transferencia de solo 1 byte de datos, la tasa de datos será menos de la mitad de la tasa de bits máxima.

El número de nodos que pueden existir en un bus I ² C dado 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, que nuevamente restringe el uso práctico a la comunicación dentro de la misma placa de circuito impreso o sistema pequeño de placas.

Diseño de referencia

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

• Nodo maestro: nodo que genera el reloj e inicia la comunicación con los esclavos.
• Nodo esclavo: nodo que recibe el reloj y responde cuando lo direcciona el maestro.

El bus es un bus multimaestro , lo que significa que puede estar presente cualquier número de nodos maestros. Además, los roles de maestro y esclavo pueden cambiarse entre mensajes (después de que se envía un STOP).

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

• transmisión maestra: el nodo maestro está enviando datos a un esclavo,
• recepción maestra: el nodo maestro está recibiendo datos de un esclavo,
• transmisión esclava: el nodo esclavo está enviando datos al maestro,
• recepción de esclavos: el nodo esclavo está recibiendo datos del maestro.

Además de los bits de datos 0 y 1, el bus I ² C permite señales especiales de ARRANQUE 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 los bits de parada utilizados en la comunicación en serie asíncrona , que se distinguen de los bits de datos solo por su sincronización).

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

Si el esclavo existe en el bus, responderá con un bit ACK (activo bajo para reconocido) para esa dirección. Luego, el maestro continúa en modo de transmisión o recepción (de acuerdo con el bit de lectura / escritura que envió), y el esclavo continúa en el modo complementario (recepción o transmisión, respectivamente).

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

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

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

Una transacción I ² C puede constar de varios mensajes. El maestro 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 ² C define tipos básicos de transacciones, cada una de las cuales comienza con un START y termina con un STOP:

• Mensaje único en el que un maestro escribe datos en un esclavo.
• Mensaje único donde un maestro lee datos de un esclavo.
• Formato combinado, donde un maestro emite al menos dos lecturas o escrituras a uno o más esclavos.

En una transacción combinada, cada lectura o escritura comienza con un INICIO y la dirección del esclavo. Las condiciones de INICIO posteriores a 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 esclavos saben que el siguiente mensaje es parte de la misma transacción.

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

Los sistemas puros I ² C admiten estructuras de mensajes arbitrarias. SMBus está restringido a nueve de esas estructuras, como la palabra de lectura N y la palabra de escritura N , que involucran a un solo esclavo. PMBus amplía SMBus con un protocolo de grupo , lo que permite enviar varias transacciones de SMBus en un mensaje combinado. La PARADA final 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 esclavas I ² C diferentes ), y sus nuevas configuraciones entrarían en vigencia al mismo tiempo: cuando reciban ese STOP.

Con solo unas pocas excepciones, ni I ² C ni SMBus definen la semántica de los mensajes, como el significado de los bytes de datos en los mensajes. De lo contrario, la semántica de los mensajes es específica del producto. Esas excepciones incluyen mensajes dirigidos a la dirección de llamada general I ² C (0x00) oa la dirección de respuesta de alerta de SMBus ; y mensajes involucrados en el Protocolo de resolución de direcciones (ARP) SMBus para la asignación y administración dinámicas de direcciones.

En la práctica, la mayoría de los esclavos 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 una dirección. Esos bytes determinan cómo se tratan los bytes escritos posteriores o cómo responde el esclavo en las lecturas posteriores. La mayoría de las operaciones de SMBus involucran comandos de un solo byte.

Ejemplo de mensajería: EEPROM 24C32

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 direcciones EEPROM de 32  kbit (o 4  kB ). El mismo direccionamiento de dos bytes también es utilizado por EEPROM más grandes, como el 24C512 que almacena 512 kbits (o 64 kB). La escritura y la lectura de datos en estas EEPROM utilizan 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. I^Las EEPROM ² C de menos de 32 kbit, como la 24C02 de 2 kbit, se utilizan a menudo en el SMBus con transferencias de datos de un solo byte ineficaces para superar este problema.

Un solo mensaje se escribe en la EEPROM. Después del INICIO, el maestro envía la dirección del bus del chip con el bit de dirección borrado ( escritura ), luego envía la dirección de datos de dos bytes dentro de la EEPROM y luego envía los bytes de datos para que se escriban 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á ocupado guardando esos bytes en la memoria, la EEPROM no responderá a más solicitudes de I ² C. (Esa es otra incompatibilidad con SMBus: los dispositivos SMBus siempre deben responder a sus direcciones de bus).

Para leer comenzando en una dirección particular en la EEPROM, se usa un mensaje combinado. Después de un INICIO, el maestro escribe primero la dirección del bus de ese chip con el bit de dirección en blanco ( escritura ) y luego los dos bytes de la dirección de datos EEPROM. Luego envía un START (repetido) y la dirección del bus de la EEPROM con el bit de dirección establecido ( leído ). La EEPROM entonces 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 maestro 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 varios bytes pueden recuperar todo el contenido de la EEPROM utilizando un mensaje combinado.

Capa física

En la capa física , las líneas SCL y SDA tienen un diseño de drenaje abierto , por lo que se necesitan resistencias pull-up . Se emite un "0" lógico tirando de la línea a tierra, y se emite un "1" lógico dejando que la línea flote (salida de alta impedancia ) para que la resistencia pull-up la eleve. Una línea nunca se eleva activamente. Este cableado permite que varios nodos se conecten al bus sin cortocircuitos por contención de señales. 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 adaptarse a una mayor capacitancia del bus y permitir tiempos de subida más rápidos.

Una consecuencia importante de esto es que varios nodos pueden controlar las líneas simultáneamente. Si algún nodo está bajando la línea, será baja. Los nodos que están intentando transmitir uno lógico (es decir, dejando que la línea flote en alto) pueden detectar esto y concluir que otro nodo está activo al mismo tiempo.

Cuando se usa en SCL, esto se denomina alargamiento de reloj y es un mecanismo de control de flujo para esclavos. Cuando se usa en SDA, esto se denomina arbitraje y garantiza que solo haya un transmisor a la vez.

Cuando está inactivo, ambas líneas están altas. Para iniciar una transacción, SDA se baja mientras que SCL permanece alto. Es ilegal ^{[10] : 14} transmitir un marcador de parada liberando SDA para que flote alto de nuevo (aunque tal "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 del reloj en alto mientras se mantiene estable la línea de datos en el nivel deseado.

Mientras SCL es bajo, el transmisor (inicialmente el maestro) establece 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. El maestro entonces espera 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 alargamiento del reloj de un esclavo.

Una vez que el SCL es alto, el maestro espera un tiempo mínimo (4 μs para I ² C de velocidad estándar ) para asegurarse de que el receptor ha visto el bit, luego lo 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 "reconocimiento" en la otra dirección. El transmisor y el receptor cambian las funciones de 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:

• (Si el maestro está transmitiendo al esclavo) El esclavo no puede aceptar los datos. No existe tal esclavo, comando no entendido o no puede aceptar más datos.
• (Si el esclavo está transmitiendo al maestro) El maestro desea que la transferencia se detenga después de este byte de datos.

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

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

• Comience a transferir otro byte de datos: el transmisor establece SDA y el maestro pulsa SCL alto.
• Enviar un "Stop": establezca SDA bajo, deje que SCL suba y luego deje que SDA suba. Esto libera el bus I ² C.
• Envíe un "inicio repetido": establezca SDA alto, deje que SCL suba, luego baje el SDA nuevamente. Esto inicia un nuevo mensaje de bus I ² C sin liberar el bus.

Estiramiento del reloj usando SCL

Una de las características más importantes del protocolo I ² C es el alargamiento del reloj. Un dispositivo esclavo direccionado puede mantener baja la línea de reloj (SCL) 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 maestro que se está comunicando con el esclavo no finalice la transmisión del bit actual, pero debe esperar hasta que la línea del reloj se ponga alta. Si el esclavo está alargando el reloj, la línea del reloj seguirá siendo baja (porque las conexiones son de drenaje abierto ). Lo mismo es cierto si un segundo maestro más lento intenta hacer funcionar el reloj al mismo tiempo. (Si hay más de un maestro, todos menos uno normalmente perderán el arbitraje).

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

Aunque el maestro también puede mantener baja la línea SCL durante el tiempo que desee (esto no está permitido en la versión más reciente de la Rev.6 del protocolo - subsección 3.1.1), el término "alargamiento del reloj" se usa normalmente solo cuando los esclavos lo hacen. . Aunque en teoría cualquier pulso de reloj se puede estirar, generalmente son los intervalos antes o después del bit de reconocimiento los que se utilizan. Por ejemplo, si el esclavo es un microcontrolador , su interfaz I ² C podría estirar el reloj después de cada byte, hasta que el software decida si enviar un acuse de recibo positivo o un NACK.

El alargamiento del reloj es el único momento en I ² C donde el esclavo controla SCL. Muchos esclavos no necesitan alargar el reloj y, por lo tanto, tratan a SCL estrictamente como una entrada sin circuitos para controlarlo. Es posible que algunos maestros, como los que se encuentran dentro de los ASIC personalizados , no admitan el alargamiento del reloj; a menudo, estos dispositivos se etiquetarán como una "interfaz de dos cables" y no como I ² C.

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

Arbitraje con SDA

Cada maestro monitorea el bus en busca de bits de inicio y parada y no inicia un mensaje mientras otro maestro mantiene el bus ocupado. Sin embargo, dos maestros pueden iniciar la transmisión aproximadamente al mismo tiempo; en este caso, se produce el arbitraje. El modo de transmisión esclavo también se puede arbitrar, cuando un maestro se dirige a varios esclavos, pero esto es menos común. A diferencia de los protocolos (como Ethernet ) que utilizan retrasos de retroceso aleatorios antes de emitir un reintento, I ² 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 SDA en 1 (no impulsa una señal) y un segundo transmisor lo establece en 0 (tira a tierra), el resultado es que la línea es baja. El primer transmisor luego observa que el nivel de la línea es diferente al esperado y concluye que otro nodo está transmitiendo. El primer nodo en notar tal diferencia es el que pierde el arbitraje: deja de conducir SDA. Si es un maestro, también deja de conducir 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 ahora la señal ha sido exactamente la esperada; ningún otro transmisor ha perturbado su mensaje.

Si los dos maestros envían un mensaje a dos esclavos diferentes, el que envía la dirección de esclavo inferior siempre "gana" el arbitraje en la etapa de dirección. Dado que los dos maestros pueden enviar mensajes a la misma dirección de esclavo, y las direcciones a veces se refieren a varios esclavos, el arbitraje a veces debe continuar en las etapas de datos.

El arbitraje ocurre muy raramente, pero es necesario para un soporte multimaestro adecuado. Al igual que con el alargamiento del reloj, no todos los dispositivos admiten el arbitraje. Los que lo hacen, generalmente se etiquetan a sí mismos como compatibles con la comunicación "multimaestro".

Un caso que debe manejarse con cuidado en las implementaciones de I ² C multimaestro es el de los maestros hablando entre sí. Un maestro puede perder el arbitraje por un mensaje entrante y debe cambiar su función de maestro a esclavo a tiempo para reconocer su propia dirección.

En el caso extremadamente raro de que dos maestros envíen simultáneamente mensajes idénticos, ambos considerarán que la comunicación fue exitosa, pero el esclavo solo verá un mensaje. Por esta razón, cuando un esclavo puede ser accedido por varios maestros, cada comando reconocido por el esclavo debe ser idempotente o debe garantizarse que nunca será emitido por dos maestros al mismo tiempo. (Por ejemplo, un comando que es emitido por un solo maestro no necesita ser idempotente, ni es necesario que un comando específico sea idempotente cuando algún mecanismo de exclusión mutua asegura que solo un maestro pueda emitir ese comando en un momento dado. .)

Arbitraje en SMBus

Mientras que I ² C solo arbitra entre maestros, SMBus usa el arbitraje en tres contextos adicionales, donde varios esclavos responden al maestro y uno recibe su mensaje.

• Aunque conceptualmente es un bus de un solo maestro, un dispositivo esclavo que admite el "protocolo de notificación de host" actúa como maestro para realizar la notificación. Toma el bus y escribe un mensaje de 3 bytes en la dirección reservada "SMBus Host" (0x08), pasando su dirección y dos bytes de datos. Cuando dos esclavos intentan notificar al anfitrión al mismo tiempo, uno de ellos perderá el arbitraje y deberá volver a intentarlo.
• Un sistema de notificación esclavo alternativo utiliza la señal SMBALERT # separada para solicitar atención. En este caso, el host realiza una lectura de 1 byte de la "Dirección de respuesta de alerta SMBus" reservada (0x0C), que es una especie de dirección de transmisión. Todos los esclavos que alertan responden con bytes de datos que contienen su propia dirección. Cuando el esclavo transmite con éxito su propia dirección (ganando el arbitraje contra otros), deja de generar esa interrupción. Tanto en este caso como en el anterior, el arbitraje garantiza que se recibirá el mensaje de un esclavo y que los demás sabrán que deben volver a intentarlo.
• SMBus también admite un "protocolo de resolución de direcciones", en el que los dispositivos devuelven un "ID de dispositivo universal" ( UDID ) de 16 bytes . Pueden responder varios dispositivos; el que tenga el UDID más bajo ganará el arbitraje y será reconocido.

Arbitraje en PMBus

PMBus versión 1.3 amplía el protocolo de respuesta de alerta SMBus en su protocolo de "lectura de zona". ^{[12] Los} esclavos pueden agruparse en "zonas", y todos los esclavos en una zona pueden ser direccionados 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 reordenado (por lo que la información más significativa se envía primero). El arbitraje asegura que la respuesta de mayor prioridad sea la primera que se devuelva al maestro.

PMBus reserva las direcciones I ² 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 ² C. Todos son compatibles porque siempre se puede usar 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 se indica a continuación:

• El modo rápido es altamente compatible y simplemente ajusta varios de los parámetros de tiempo para lograr una velocidad de 400 kbit / s. El modo rápido es ampliamente compatible con dispositivos esclavos I ² C, por lo que un maestro puede usarlo siempre que sepa que la capacitancia del bus y la fuerza de pull-up lo permiten.
• El modo rápido plus alcanza hasta 1 Mbit / s utilizando controladores y pull-ups más potentes (20 mA) para lograr tiempos de subida y bajada más rápidos. La compatibilidad con dispositivos de modo estándar y rápido (con capacidad de pull-down de 3 mA) se puede lograr si hay alguna forma de reducir la fuerza de los pull-ups al hablar con ellos.
• El modo de alta velocidad (3.4 Mbit / s) es compatible con dispositivos I ² C normales en el mismo bus, pero requiere que el maestro tenga un pull-up activo en la línea de reloj que está habilitado durante transferencias de alta velocidad. El primer bit de datos se transfiere con un borde de reloj ascendente de drenaje abierto normal, que puede estirarse. Para los siete bits de datos restantes y el ACK, el maestro impulsa el reloj alto en el momento apropiado y el esclavo no puede estirarlo. Todas las transferencias de alta velocidad están precedidas por un "código maestro" de un solo byte a velocidad rápida o estándar. Este código tiene tres propósitos:
  1. le dice a los dispositivos esclavos de alta velocidad que cambien a reglas de temporización de alta velocidad,
  2. asegura que los dispositivos de velocidad rápida o normal no intentarán participar en la transferencia (porque no coincide con su dirección), y
  3. debido a que identifica al maestro (hay ocho códigos maestros, y cada maestro debe usar uno diferente), asegura que el arbitraje se complete antes de la parte de alta velocidad de la transferencia, por lo que la parte de alta velocidad no necesita tener en cuenta esa habilidad.
• El modo ultrarrápido es esencialmente un subconjunto de I ² C de solo escritura , que es incompatible con otros modos, excepto en que es fácil agregarle soporte a un diseño de hardware de interfaz I ² C existente . Solo se permite un maestro, y este controla activamente las líneas de datos en todo momento para lograr una tasa de transferencia de 5 Mbit / s. Se omiten la extensión del reloj, el arbitraje, las transferencias de lectura y los reconocimientos. Está diseñado principalmente para pantallas LED animadas donde un error de transmisión solo causaría una falla visual breve e intrascendente . El parecido con otros modos de bus I ² C se limita a:
  • las condiciones de inicio y parada se utilizan para delimitar transferencias,
  • El direccionamiento I ² C permite que varios dispositivos esclavos compartan el bus sin señales de selección de esclavo estilo bus SPI , y
  • se envía un noveno pulso de reloj por byte transmitido que marca la posición de los bits de reconocimiento no utilizados.

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

En todos los modos, la frecuencia de reloj es controlada por el maestro (s), y un bus más largo de lo normal puede operarse a una velocidad más lenta que la nominal mediante un subclocking .

Interconexiones de circuitos

I ² C es popular para interconectar circuitos periféricos con sistemas de creación de prototipos, como Arduino y Raspberry Pi . I ² C no emplea un conector estandarizado, sin embargo, los diseñadores de placas han creado varios esquemas de cableado para las interconexiones I ² C. Para minimizar el posible daño debido a enchufar cabezales de 0.1 pulgadas al revés, algunos desarrolladores han sugerido usar señales alternas y conexiones de alimentación de los siguientes esquemas de cableado: (GND, SCL, VCC, SDA) o (VCC, SDA, GND, SCL) . ^[13]

La gran mayoría de las aplicaciones utilizan I ² C en la forma en que se diseñó 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 un conector. . Sin embargo, utilizando un controlador diferencial, una versión alternativa de I ² C puede comunicarse hasta 20 metros (posiblemente más de 100 metros) a través de CAT5 u otro cable. ^{[14] [15]}

Varios conectores estándar llevan señales I ² C. Por ejemplo, el conector UEXT lleva I ² C; el conector iPack de 10 pines lleva I ² C; ^[16] el conector 6P6C Lego Mindstorms NXT lleva I ² C; ^{[17] [18] [19] [20]} a algunas personas utilizan los conectores 8P8C y cable CAT5 normalmente utilizadas para Ethernet de capa física a su lugar llevan I-diferenciales codificado ² señales C ^[21] o impulsado I único de composición ² señales C ; ^[22] y todos los HDMI y la mayoríaLos conectores DVI y VGA transportan datos DDC2 a través de I ² C.

Almacenamiento en búfer y multiplexación

Cuando hay muchos dispositivos I ² C en un sistema, puede ser necesario incluir búferes de bus o multiplexores para dividir segmentos de bus grandes en segmentos 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 múltiples dispositivos con la misma dirección sean separados por un multiplexor. Existen muchos tipos de multiplexores y búferes y todos deben tener en cuenta el hecho de que las líneas I ² C están especificadas para ser bidireccionales. Los multiplexores se pueden implementar con conmutadores analógicos, que pueden vincular 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 búferes se pueden utilizar para aislar la capacitancia en un segmento de otro y / o permitir que I ² C se envíe a través de cables o trazas más largos. Los búferes para líneas bidireccionales como I ² C deben usar uno de varios esquemas para prevenir el enganche. Yo ²C es de drenaje abierto, por lo que los amortiguadores deben conducir una baja en un lado cuando ven una baja en el otro. Un método para prevenir el enganche es que un búfer tenga niveles de entrada y salida cuidadosamente seleccionados de manera que el nivel de salida de su controlador sea mayor que 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 varios búferes implementan este El esquema no se puede poner en serie entre sí.

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

Compartir SCL entre varios buses

Cuando se tiene un solo maestro, es posible que varios buses I ² C compartan la misma línea SCL. ^{[23] [24]} Los paquetes de 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 en periodos cortos alternados con SCL alto seguidos de periodos cortos con SCL bajo. Y el reloj se puede alargar, si un autobús necesita más tiempo en un estado.

Las ventajas son el uso de dispositivos esclavos con la misma dirección al mismo tiempo y el ahorro de conexiones o un rendimiento más rápido al usar 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 ² C.

Estado de la línea

Tipo	Bus inactivo (NORTE)	Comienzo (S)	Inactivo (I)	Detener (PAG)	Estiramiento del reloj (CS)
Nota	Libre de reclamar arbitraje	Bus reclamando (maestro)	Bus reclamado (maestro)	Liberación de bus (maestro)	Detenido por esclavo
SDA	Pullup pasivo	Borde descendente (maestro)	Mantenido bajo (maestro)	Filo ascendente (maestro)	No me importa
SCL	Pullup pasivo	Pullup pasivo	Pullup pasivo	Pullup pasivo	Mantenido bajo (esclavo)

Estado de la línea

Tipo	Envío de un bit de datos (1) (0) (SDA se establece / muestrea después de SCL para evitar la detección de estado falso)		Respuesta del receptor con bit ACK (Byte recibido del remitente)		Respuesta del receptor con bit NACK (Byte no recibido del remitente)
	Configuración de bits (Bs)	Listo para muestrear (Bx)	Configuración de bits (Bs)	ACK (A)	Configuración de bits (Bs)	NACK (A ')
Nota	Bit de conjunto del remitente (maestro / esclavo)	Bit de muestra del receptor (maestro / esclavo)	Emisor transmisor hi-Z	El remitente ve que el SDA es bajo	Emisor transmisor hi-Z	El remitente ve que el SDA es alto
SDA	Establecer bit (después de que caiga SCL)	Bit de captura (después de que SCL sube)	Mantenido bajo por el receptor (después de que SCL cae)		Conducido alto (o alto pasivo) por el receptor (después de que SCL cae)
SCL	Borde descendente (maestro)	Filo ascendente (maestro)	Borde descendente (maestro)	Filo ascendente (maestro)	Borde descendente (maestro)	Filo ascendente (maestro)

Estado de la línea (inicio repetido)

Tipo	Configuración para una señal (Sr) después de un ACK / NACK				Inicio repetido (Sr)
Nota	Empiece aquí desde ACK	Evitar el estado de parada (P)		Empiece aquí desde NACK	Igual que la señal de inicio (S)
SDA	Se mantuvo bajo para ACK	Flanco ascendente	Pasivo alto	Pasivo alto	Borde descendente (maestro)
SCL	Borde descendente (maestro)	Mantenido bajo	Filo ascendente (maestro)	Pasivo alto	Pullup pasivo

Estructura de direccionamiento

Direccionamiento de 7 bits

Campo:	S	Campo de dirección I 2 C							R / W '	A	Secuencias de mensajes I 2 C ...	PAG
Tipo	Comienzo	Byte 1								ACK	Byte X, etc. Resto de la lectura o escritura el mensaje va aquí	Detener
Posición de bit en el byte X		7	6	5	4	3	2	1	0
Pos de dirección de 7 bits		7	6	5	4	3	2	1
Nota		MSB						LSB	1 = Leer
									0 = escribir

Direccionamiento de 10 bits

Campo:	S	Indicador de modo de 10 bits					Dirección superior		R / W '	A	Campo de dirección inferior								Secuencias de mensajes I 2 C	PAG
Tipo	Comienzo	Byte 1								ACK	Byte 2								Byte X, etc. Resto de la lectura o escritura el mensaje va aquí	Detener
Posición de bit en el byte X		7	6	5	4	3	2	1	0		7	6	5	4	3	2	1	0
Valor de bit		1	1	1	1	0	X	X	X		X	X	X	X	X	X	X	X
Pos de dirección de 10 bits							10	9			8	7	6	5	4	3	2	1
Nota		Indica el modo de 10 bits					MSB		1 = Leer									LSB
									0 = escribir

Direcciones reservadas en el espacio de direcciones de 7 bits

Se reservan dos grupos de direcciones para funciones especiales:

• 0000 XXX
• 1111 XXX

Índice de direcciones reservadas	Byte de 8 bits			Descripción
	Dirección de 7 bits		Valor R / W
	MSB (4 bits)	LSB (3 bits)	1 bit
1	0000	000	0	Convocatoria general
2	0000	000	1	Byte de inicio
3	0000	001	X	Dirección CBUS
4	0000	010	X	Reservado para diferentes formatos de bus
5	0000	011	X	Reservado para fines futuros
6	0000	1XX	X	Código maestro del modo HS
7	1111	1XX	1	ID del dispositivo
8	1111	0XX	X	Direccionamiento esclavo de 10 bits

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

Direcciones no reservadas en el espacio de direcciones de 7 bits

MSB (4 bits)	Uso típico [25] [26] [27] [28] [29]
0001	Receptores digitales, SMBus
0010	Decodificadores de línea de video de TV, IPMB
0011	Códecs AV
0100	Codificadores de video, expansores GPIO
0101	ACCESO autobús , PMBus
0110	VESA DDC , PMBus
0111	Controlador de pantalla
1000	Procesamiento de señales de TV, procesamiento de audio, SMBus
1001	Conmutación AV, ADC y DAC , IPMB , SMBus
1010	Memoria de almacenamiento, reloj en tiempo real
1011	Procesadores AV
1100	PLL y sintonizadores, moduladores y demoduladores, SMBus
1101	Procesadores y decodificadores AV, amplificadores de potencia de audio, SMBus
1110	Convertidores de espacio de color AV

Aunque MSB 1111 está reservado para ID de dispositivo y direccionamiento esclavo de 10 bits, también lo utilizan los dispositivos que dependen de la pantalla VESA DDC , como los dispositivos señaladores . ^[28]

Formato de transacción

Una transacción I ² 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 solo 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 ² 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 sola transacción; los esclavos tienen prohibido responder si observan un símbolo de parada. Los modos de configuración, calibración o autocomprobación que hacen que el esclavo responda de manera inusual también suelen terminarse automáticamente al final de una transacción.

Diagrama de tiempos

1. La transferencia de datos se inicia con una condición de inicio (S) señalada por SDA baja mientras que SCL permanece alta.
2. El SCL se baja y SDA establece el primer nivel de bits de datos mientras se mantiene el 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 subsiguiente (todo el tiempo de la barra verde).
4. Este proceso se repite, SDA en transición mientras SCL es bajo y los datos se leen mientras SCL es alto (B2, ... Bn).
5. El bit final es seguido por un pulso de reloj, durante el cual SDA se baja en preparación para el bit de parada .
6. Una condición de parada (P) se señaliza cuando SCL sube, seguida de SDA sube.

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

Ejemplo de bit-banging del protocolo maestro I ² C

A continuación se muestra un ejemplo de bit-golpeando la I ² protocolo C como un I ² C maestro. El ejemplo está escrito en la pseudo C . Ilustra todas las características I ² C descritas anteriormente (alargamiento del reloj, arbitraje, bit de inicio / parada, ack / nack). ^[30]

// Funciones de soporte específicas del hardware que DEBEN personalizarse:#define I2CSPEED 100void  I2C_delay ( void );bool  read_SCL ( vacío );  // Devuelve el nivel actual de la línea SCL, 0 o 1bool  read_SDA ( vacío );  // Devuelve el nivel actual de la línea SDA, 0 o 1void  set_SCL ( void );  // No conduzca SCL (establezca el pin de alta impedancia)void  clear_SCL ( void );  // Conduce activamente la señal SCL a bajavoid  set_SDA ( vacío );  // No conduzca SDA (establezca el pin de alta impedancia)void  clear_SDA ( vacío );  // Conduce activamente la señal SDA bajavoid  arbitration_lost ( nulo );bool  iniciado  =  falso ;  // datos globalesvoid  i2c_start_cond ( void )  { if  ( iniciado )  {  // si se inicia, realiza una condición de reinicio // establece SDA en 1 set_SDA (); I2C_delay (); set_SCL (); while  ( read_SCL ()  ==  0 )  {  // Alargamiento del reloj // Deberías agregar tiempo de espera a este ciclo } // Tiempo de configuración de inicio repetido, mínimo 4.7us I2C_delay (); } si  ( read_SDA ()  ==  0 )  { arbitration_lost (); } // SCL es alto, establezca SDA de 1 a 0. clear_SDA (); I2C_delay (); clear_SCL (); iniciado  =  verdadero ;}void  i2c_stop_cond ( void )  { // establece SDA en 0 clear_SDA (); I2C_delay (); set_SCL (); // Estiramiento del reloj while  ( read_SCL ()  ==  0 )  { // agrega tiempo de espera a este ciclo. } // Detener el tiempo de configuración del bit, mínimo 4us I2C_delay (); // SCL es alto, establezca SDA de 0 a 1 set_SDA (); I2C_delay (); si  ( read_SDA ()  ==  0 )  { arbitration_lost (); } iniciado  =  falso ;}// Escribe un bit en el bus I2Cvoid  i2c_write_bit ( bool  bit )  { si  ( bit )  { set_SDA (); }  más  { clear_SDA (); } // Retardo de propagación del cambio SDA I2C_delay (); // Establezca SCL alto para indicar que hay disponible un nuevo valor SDA válido set_SCL (); // Espere a que el esclavo lea el valor SDA, mínimo de 4us para el modo estándar I2C_delay (); while  ( read_SCL ()  ==  0 )  {  // Alargamiento del reloj // Deberías agregar tiempo de espera a este ciclo } // SCL es alto, ahora los datos son válidos // Si el SDA es alto, compruebe que nadie más esté conduciendo el SDA if  ( bit  &&  ( read_SDA ()  ==  0 ))  { arbitration_lost (); } // Borre el SCL a bajo en preparación para el próximo cambio clear_SCL ();}// Leer un poco del bus I2Cbool  i2c_read_bit ( void )  { bool  bit ; // Deja que el esclavo maneje los datos set_SDA (); // Espere a que el esclavo escriba el valor SDA, mínimo de 4us para el modo estándar I2C_delay (); // Establezca SCL alto para indicar que hay disponible un nuevo valor SDA válido set_SCL (); while  ( read_SCL ()  ==  0 )  {  // Alargamiento del reloj // Deberías agregar tiempo de espera a este ciclo } // Espere a que el esclavo escriba el valor SDA, mínimo de 4us para el modo estándar I2C_delay (); // 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 esclavo lo acepta.bool  i2c_write_byte ( bool  send_start , bool  send_stop , unsigned  char  byte )  {  bit sin firmar ; bool  nack ; if  ( send_start )  { i2c_start_cond (); } para  ( bit  =  0 ;  bit  <  8 ;  ++ bit )  { i2c_write_bit (( byte  &  0x80 )  ! =  0 ); byte  << =  1 ; } nack  =  i2c_read_bit (); if  ( send_stop )  { i2c_stop_cond (); } return  nack ;}// Leer un byte del bus I2Cunsigned  char  i2c_read_byte ( bool  nack ,  bool  send_stop )  {  byte de carácter  sin signo = 0 ;    bit char  sin firmar ; para  ( bit  =  0 ;  bit  <  8 ;  ++ bit )  { byte  =  ( byte  <<  1 )  |  i2c_read_bit (); } i2c_write_bit ( nack ); if  ( send_stop )  { i2c_stop_cond (); } retorno  byte ;}void  I2C_delay ( void )  {  volatile  int  v ; int  i ; para  ( i  =  0 ;  i  <  I2CSPEED  /  2 ;  ++ i )  { v ; }}

Soporte del sistema operativo

• En AmigaOS se puede usar el componente i2c.resource ^[31] para AmigaOS 4.xy MorphOS 3.xo la biblioteca compartida i2c.library de Wilhelm Noeker para sistemas más antiguos.
• Los desarrolladores de Arduino pueden usar la biblioteca "Wire".
• Maximite admite comunicaciones I ² C de forma nativa como parte de su MMBasic.
• PICAXE usa los comandos i2c y hi2c.
• eCos admite I ² C para varias arquitecturas de hardware.
• ChibiOS / RT admite I ² C para varias arquitecturas de hardware.
• FreeBSD , NetBSD y OpenBSD también proporcionan un marco I ² C, con soporte para varios controladores y sensores maestros comunes.
  • Desde OpenBSD 3.9 (lanzado el 1 de mayo de 2006 ; hace 15 años ), un subsistema central i2c_scan sondea todos los chips sensores posibles a la vez durante el arranque, utilizando un esquema de ponderación ad hoc y una función de almacenamiento en caché local para leer los valores de registro de los esclavos I ² C; ^[32] esto hace que sea posible la sonda sensores en de propósito general off-the-shelf i386 / amd64 hardware durante el arranque sin ninguna configuración por parte del usuario ni un retraso de sondeo notable; los procedimientos de coincidencia de los controladores individuales sólo tienen que depender de un "nombre descriptivo" basado en cadenas para la coincidencia; ^[33] como resultado, la mayoría de I ² (2006-05-01) Los controladores de sensor C se habilitan automáticamente de forma predeterminada en las arquitecturas aplicables sin efectos nocivos en la estabilidad; Los sensores individuales, tanto I ² C como de otro tipo, se exportan al área de usuario a través del marco sysctl hw.sensors . En marzo de 2019 ^[update], OpenBSD tiene más de dos docenas de controladores de dispositivos en I ² C que exportan algún tipo de sensor a través del marco hw.sensors , y la mayoría de estos controladores están completamente habilitados de forma predeterminada en los GENERICnúcleos i386 / amd64 de OpenBSD.
  • En NetBSD , existen más de dos docenas ^de dispositivos esclavos I ² C que cuentan con sensores de monitoreo de hardware, a los que se puede acceder a través del marco sysmon envsys como listas de propiedades . En hardware de propósito general, cada controlador tiene que hacer su propio sondeo, por lo tanto, todos los controladores para los esclavos I ² C están deshabilitados de forma predeterminada en NetBSD en las GENERICcompilaciones i386 / amd64.
• En Linux , I ² C se maneja con un controlador de dispositivo para el dispositivo específico y otro para el adaptador I ² C (o SMBus ) al que está conectado. Varios cientos de estos controladores forman parte de las versiones actuales.
• En Mac OS X , hay alrededor de dos docenas ^de extensiones de kernel I ² C que se comunican con sensores para leer voltaje, corriente, temperatura, movimiento y otros estados físicos.
• En Microsoft Windows , I ² C se implementa mediante los respectivos controladores de dispositivo de gran parte del hardware disponible en la industria. Para dispositivos HID integrados / SoC , Windows 8 y versiones posteriores tienen un controlador de bus I²C integrado. ^[34]
• En Windows CE , I ² C se implementa mediante los respectivos controladores de dispositivo de gran parte del hardware disponible en la industria.
• Unison OS , un POSIX RTOS para IoT, admite I ² C para varias arquitecturas de hardware MCU y MPU.
• En RISC OS , I ² C se proporciona con una interfaz I ² C genérica desde el controlador IO y es compatible con el sistema del módulo OS
• En los sistemas operativos Sinclair QDOS y Minerva QL , I ² C es compatible con un conjunto de extensiones proporcionadas por TF Services .

Herramientas de desarrollo

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

Adaptadores de host

Hay una serie de soluciones de hardware de adaptador de host I ² C para realizar una conexión I ² C maestro o esclavo a equipos host que ejecutan Linux , Mac o Windows . La mayoría de las opciones son adaptadores USB a I ² C. No todos requieren controladores o API propietarios .

Analizadores de protocolo

Los analizadores de protocolo I ² C son herramientas que muestrean un bus I ² 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 ² C, 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, para que las personas puedan ver las formas de onda de alta velocidad en su tiempo libre. 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

La asignación de direcciones esclavas es una debilidad de I ² C. Siete bits es muy pocos para evitar colisiones de direcciones entre los muchos 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 esclava en una de las pocas opciones de dirección por dispositivo. Es típico dos o tres pines, y con muchos dispositivos, hay tres o más opciones de cableado por pin de dirección. ^{[35] [36] [37]}

Las direcciones I ² C de 10 bits aún no se utilizan ampliamente y muchos sistemas operativos host no las admiten. ^[38] Tampoco lo es el complejo esquema "ARP" de SMBus para la asignación dinámica de direcciones (salvo para las tarjetas PCI con presencia SMBus, para las que es necesario).

La configuración automática del bus es un problema relacionado. Una dirección determinada puede ser utilizada por varios dispositivos incompatibles con el protocolo 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 PCF8563 RTC, que no se puede distinguir de forma fiable de ninguno de los dos (sin cambiar el estado del dispositivo, 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. Una vez más, este problema puede ser abordado parcialmente por ARP en sistemas SMBus, especialmente cuando se utilizan identificadores de proveedores y productos; pero eso realmente no se ha popularizado. El rev. 03 de la especificación I ² C agrega un mecanismo de identificación de dispositivo.

I ² C admite un rango limitado de velocidades. Los hosts que admiten 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 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). Es posible que los nodos I ² C implementados en software (en lugar de hardware dedicado) ni siquiera admitan 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 de manera falsa la dirección de su dispositivo.

Los dispositivos pueden estirar los ciclos de reloj para adaptarse a sus necesidades particulares, lo que puede privar del 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 limita la velocidad de transferencia, especialmente cuando no se utilizan fuentes de corriente para reducir los tiempos de subida de la señal.

Debido a que I ² 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, evita que el maestro envíe comandos de INICIO o DETENCIÓN 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 de bus. Sin embargo, muchos dispositivos no tienen un pin de reinicio dedicado, lo que obliga al diseñador a instalar circuitos para permitir que los dispositivos se apaguen y enciendan si es necesario reiniciarlos.

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

Tecnologías derivadas

I ² C es la base para ACCESS.bus , la interfaz VESA Display Data Channel (DDC), System Management Bus (SMBus), 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 ² C redundante de ² vías para la gestión de estanterías. La capacidad I ² C multimaestro es un requisito en estos sistemas.

TWI (interfaz de dos cables) o TWSI (interfaz de serie de dos cables) es esencialmente el mismo bus implementado en varios procesadores de sistema en chip de Atmel y otros proveedores. ^[39] Los proveedores utilizan el nombre TWI, a pesar de que I ² C no es una marca registrada a partir de 2014-11-07. ^[40] La protección de marca registrada solo existe para el logotipo respectivo (ver esquina superior derecha), y las patentes sobre I ² C han caducado.

En algunos casos, el uso del término "interfaz de dos cables" indica una implementación incompleta de la especificación I ² C. No admitir el arbitraje o el alargamiento del reloj es una limitación común, que sigue siendo útil para un solo maestro que se comunica con esclavos simples que nunca alargan el reloj.

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

Ver también

• Lista de buses de la red
• ACCESO.bus
• I3C
• Bus de administración de energía
• Bus de gestión del sistema
• Conector UEXT
• Canal de datos de pantalla VESA

Referencias

1. "Comunicados de prensa financieros-NXP" . inversores.nxp.com . Consultado el 29 de abril de 2018 .
2. " EEPROM de bus I 2 C serie 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 .
3. "Beneficios de las fuentes de alimentación equipadas con comunicaciones Ethernet I2C" . Aegis Power Systems. Archivado desde el original el 21 de diciembre de 2015 . Consultado el 21 de diciembre de 2015 .
4. Patente estadounidense 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 Philips Corporation de EE. UU. 
5. "Philips demanda a ocho empresas más por infracción de la patente del autobús I2C" . EE Times . 17 de octubre de 2001. Archivado desde el original el 2 de abril de 2021.
6. I 2 especificación C-bus Rev 2.1; Semiconductores Philips; Enero de 2000; Archivado.
7. I 2 Especificación C-bus Rev 3; Semiconductores NXP; 19 de junio de 2007; Archivado.
8. I 2 Especificación C-bus Rev 4; Semiconductores NXP; 13 de febrero de 2012; Archivado.
9. I 2 Especificación C-bus Rev 5; Semiconductores NXP; 9 de octubre de 2012; Archivado.
10. " Especificación del bus C I 2 " (PDF) . Rev 6. Semiconductores NXP . 4 de abril de 2014. Archivado (PDF) desde el original el 25 de julio de 2014.
11. "Direccionamiento esclavo I2C de 7 bits, 8 bits y 10 bits" . Fase total . Archivado desde el original el 1 de junio de 2013 . Consultado el 29 de abril de 2018 .
12. 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.
13. "¿Hay alguna guía definitiva de asignación de pines I2C? No busco un" ESTÁNDAR " " . StackExchange.
14. 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
15. Vasquez, Joshua (16 de agosto de 2017), Dar el salto: una introducción a I2C a través de cables largos , archivado desde el original el 16 de agosto de 2017
16. Formato de tablero apilable iPack , 2017-08-19, archivado desde el original el 2017-08-19
17. Ferrari, Mario; Ferrari, Giulio (29 de abril de 2018). Construyendo robots con LEGO Mindstorms NXT . págs. 63–64. ISBN 9780080554334. Archivado desde el original el 29 de abril de 2018.
18. Gasperi, Michael; Hurbain, Philippe (2010), "Capítulo 13: Comunicación por bus I 2 C" , Extreme NXT: Ampliación de LEGO MINDSTORMS NXT al siguiente nivel , ISBN 9781430224549
19. Philo. "Conector de enchufe NXT" Archivado el 20 de agosto de 2017 en la Wayback Machine.
20. Sivan Toledo. "I2C Interfacing Part 1: Adding Digital I / O Ports" Archivado el 12 de agosto de 2017 en Wayback Machine . 2006
21. "Envío confiable de I2C a través de cables Cat5" Archivado el 18 de agosto de 2017 en la Wayback Machine.
22. "Cables y conectores de bus I2C" Archivado el 18 de agosto de 2017 en la Wayback Machine.
23. https://github.com/Testato/SoftwareWire/wiki/Multiple-I2C-buses
24. https://www.microchip.com/forums/m474935.aspx
25. " Tabla de asignación de direcciones I 2 C" (PDF) (Guía de selección). Semiconductores Philips . 1999-08-24. Archivado desde el original (PDF) el 16 de octubre de 2017 . Consultado el 1 de octubre de 2017 .
26. Manual de datos IC12: Periféricos I2C, código de pedido de Philips 9397750 00306
27. "Especificación del bus de administració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 .
28. "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 .
29. "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
30. Controlador TWI Master Bit Band; Atmel; Julio de 2012 Archivado el 29 de marzo de 2017 en la Wayback Machine .
31. Componente i2c.resource Archivado el 24 de julio de 2011 en Wayback Machine para AmigaOS 4.x.
32. 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];
33. Constantine A. Murenin (21 de mayo de 2010). "5.2. Exploración del bus I ² C a través de i2c_scan.c". Sensores de hardware OpenBSD - Monitoreo ambiental y control de ventiladores ( tesis MMath ). Universidad de Waterloo : UWSpace. hdl : 10012/5234 . ID de documento: ab71498b6b1a60 ff817 b29d56997a418.
34. Introducción a HID sobre I2C
35. LTC4151 de Linear Technology Archivado 2017-08-09 en Wayback Machine tiene dos pines para la selección de direcciones, cada uno de los cuales se puede unir alto o bajo o dejar sin conectar, ofreciendo 9 direcciones diferentes.
36. Maxim's MAX7314 Archivado 2017-07-13 en Wayback Machine tiene un solo pin para que la selección de dirección esté vinculada alta o baja o conectada a SDA o SCL, ofreciendo 4 direcciones diferentes.
37. UCD9224 de TI archivado 2017-11-07 en Wayback Machine utiliza dos canales ADC que discriminan doce niveles cada uno para seleccionar cualquier dirección válida de 7 bits.
38. Delvare, Jean (16 de agosto de 2005). "Re: [PATCH 4/5] agregar i2c_probe_device e i2c_remove_device" . linux-kernel (lista de correo). Archivado desde el original el 17 de agosto de 2016.
39. avr-libc: Ejemplo de uso de la interfaz de dos cables (TWI) Archivado 2007-05-27 en Wayback Machine .
40. "TESS - Error" . tmsearch.uspto.gov . Consultado el 29 de abril de 2018 .^{[ enlace muerto permanente ]}
41. Thornton, Scott (29 de noviembre de 2017). "El circuito interintegrado mejorado (I3C)" . Consejos para microcontroladores . Archivado desde el original el 3 de febrero de 2018.

Lectura adicional

• Himpe, Vincent (2011). El dominio de la I ² C autobús . ISBN 978-0-905705-98-9. (248 páginas)
• Paret, Dominique (1997). El bus I2C: de la teoría a la práctica . ISBN 978-0-471-96268-7. (314 páginas)

Enlaces externos

• Medios relacionados con I2C en Wikimedia Commons
• Especificación oficial I 2 C Rev 6 (gratis) , NXP
• Introducción detallada, Primer
• Descripción general técnica del bus I 2 C y preguntas frecuentes
• Introducción a los protocolos SPI e I2C
• Uso del bus I 2 C con Linux
• Página de manual de OpenBSD iic (4)
• Página de información de buses seriales