I3C en dispositivos móviles

¿Qué es el I3C y cuáles son sus ventajas para los teléfonos inteligentes?

I3C es una interfaz de bus de utilidad y control escalable y de alta velocidad para conectar periféricos a un procesador de aplicaciones, optimizando la integración y mejorando la rentabilidad. Ofrece a los desarrolladores oportunidades sin precedentes para crear diseños innovadores para cualquier producto móvil, desde teléfonos inteligentes a wearables o sistemas de automoción.

I3C permite conectar periféricos a un procesador de aplicaciones en cualquier dispositivo móvil, simplificando el proceso de conexión y gestión de múltiples sensores en un dispositivo. I3C está pensado principalmente para sensores de alto rendimiento. Además, I3C transmite las interrupciones como un mensaje en el protocolo sin líneas adicionales. Con 10,6 MBit/s, I3C supera a I2C en más de tres veces. El modo de alta velocidad de datos alcanza los 33 MBit/s. Así, en algunos casos, I3C también puede sustituir a la más potente Interfaz Periférica Serie (SPI). Las ventajas de la especificación I3C son el menor consumo de energía, el número reducido de pines, así como las rutas únicas y la alta velocidad de transmisión con compatibilidad descendente simultánea con I2C. Además, las direcciones de los dispositivos se pueden asignar dinámicamente.
Touch over I3C es una opción de interfaz convergente para datos táctiles procesados y sin procesar. CCI sobre I3C ofrece un control de la cámara más rápido, con menor latencia y más eficiente. 

¿Encuadre I3C?

Al igual que el I²C, el I3C utiliza 9 ciclos de reloj para enviar cada byte de 8 bits. Sin embargo, el 9º ciclo se utiliza de forma diferente. El I²C utiliza el último ciclo para un acuse de recibo que se envía en sentido contrario a los 8 primeros bits. I3C funciona del mismo modo para el primer byte (dirección) de cada mensaje y para los mensajes compatibles con I²C. En la comunicación con esclavos I3C, los bytes de mensaje posteriores al primero utilizan el 9º bit como bit de paridad impar al escribir y como indicador de fin de datos al leer. Las escrituras sólo pueden ser terminadas por el maestro. Tanto el maestro como el esclavo pueden terminar una operación de lectura. El esclavo pone SDA a nivel bajo para indicar que no hay más datos disponibles. Entonces el maestro toma el control de SDA y genera un STOP o un START repetido. Para permitir que continúe una operación de lectura, el esclavo pone SDA alto mientras SCL está bajo antes del 9º bit, pero deja SDA flotando (drenaje abierto) mientras SCL está alto. El maestro puede poner SDA bajo en ese momento (una condición de START repetido) para abortar la operación de lectura. 

Arbitraje del bus I3C

Al principio de una trama, varios dispositivos pueden competir por el uso del bus, y el proceso de arbitraje del bus se utiliza para seleccionar qué dispositivo obtiene el control de la línea SDA. Tanto en I²C como en I3C, el arbitraje del bus se realiza con la línea SDA en modo de drenaje abierto, lo que permite a los dispositivos que transmiten un 0 binario (bajo) anular a los dispositivos que transmiten un 1 binario. Los dispositivos competidores controlan la línea SDA mientras funcionan en modo abierto. Modo drenaje. Cuando un dispositivo detecta un estado bajo (0 bit) en la línea SDA mientras transmite un estado alto (1 bit), ha perdido el arbitraje y debe dejar de competir hasta que comience la siguiente transacción.

Cada transacción comienza con la dirección de destino, y la implementación da prioridad a las direcciones de destino con números más bajos. La diferencia es que el I²C no tiene límite en la duración del arbitraje (en la situación, rara pero legal, de que varios dispositivos intenten enviar un mensaje al mismo dispositivo, el conflicto sólo se detecta después del byte de dirección). Sin embargo, I3C garantiza que el arbitraje se completa como muy tarde al final del primer byte. Esto permite utilizar controladores push-pull y velocidades de reloj más rápidas la mayor parte del tiempo. Esto se consigue de varias maneras: I3C admite varios maestros, pero no son simétricos. Uno es el maestro actual y se encarga de generar el reloj.

Otros dispositivos que envían un mensaje por el bus (interrupciones en banda o maestros secundarios que quieren utilizar el bus) deben decidir antes de enviar otros datos utilizando su propia dirección. Por tanto, no hay dos mensajes de bus legales que compartan el mismo primer byte, a menos que el maestro y otro dispositivo se estén comunicando al mismo tiempo. El I3C, como el I²C, permite varios mensajes por transacción, separados por símbolos de "INICIO repetido". El arbitraje es por transacción, por lo que estos mensajes posteriores nunca están sujetos a arbitraje. La mayoría de las transacciones del maestro I3C comienzan con la dirección reservada 0x7E (1111110 2 ).

Como ésta tiene una prioridad inferior a la de cualquier dispositivo I3C, una vez pasado el arbitraje, el maestro sabe que ningún otro dispositivo está luchando por el bus. Si a los dispositivos I3C se les asignan direcciones bajas como caso especial (I3C admite la asignación dinámica de direcciones controlada por el maestro), 0x7E el maestro conoce este arbitraje , una vez que la dirección ha ganado el arbitraje por suficientes bits iniciales para distinguirla de una dirección asignada se ha completado y se puede pasar al funcionamiento push-pull en SDA. Si todas las direcciones asignadas son inferiores a 0x40, esto ocurre después del primer bit. Si todas las direcciones son inferiores a 0x60 , esto ocurre después del segundo bit y así sucesivamente.

En el caso descrito anteriormente, en el que el maestro actual inicia una transacción con la dirección de un dispositivo que a su vez está luchando por el uso del bus, ambos transmiten sus bytes de dirección con éxito. Sin embargo, cada uno espera que el otro confirme la dirección (tirando de SDA bajo) para el siguiente bit de confirmación. En consecuencia, ni uno ni otro notarán la falta de acuse de recibo. En este caso, el mensaje no se enviará, pero el maestro ganará el arbitraje: posiblemente se enviará un inicio repetido, seguido de un reintento, que tendrá éxito.

Opciones HDR (Alta Velocidad de Datos)

Cada transacción del bus I3C comienza en modo SDR, pero el maestro I3C puede emitir un comando de difusión CCC "Entrar en HDR" que informa a todos los esclavos I3C de que la transacción continuará en un modo HDR específico. Los esclavos I3C que no admitan HDR pueden entonces ignorar el tráfico del bus hasta que vean una secuencia específica de "Salida HDR" que les informe de que ha llegado el momento de volver a escuchar el bus. (El maestro sabe qué esclavos admiten HDR y, por tanto, nunca intentará utilizar HDR para comunicarse con un esclavo que no lo admita) Algunos modos HDR también son compatibles con los dispositivos I²C si éstos tienen un filtro de picos de 50 ns en la línea SCL. Esto significa que ignoran un nivel alto en la línea SCL que dure menos de 50 ns. Esto se exige en la especificación I²C, pero no se implementa universalmente, y no todas las implementaciones ignoran los picos que se repiten con frecuencia.

Por lo tanto, hay que comprobar la compatibilidad con I3C HDR. Los modos HDR compatibles utilizan pulsos SCL de 45 ns o menos, por lo que los dispositivos I²C los ignoran. El modo HDR DDR utiliza señalización de doble velocidad de datos con un reloj de 12,5 MHz para conseguir una velocidad de datos brutos de 25 Mbit/s (efectivamente 20 Mbit/s). Esto requiere cambiar la línea SDA mientras SCK está alto, una violación del protocolo I²C, pero los dispositivos I²C no ven el breve pulso alto en SCL y, por tanto, no se dan cuenta de la violación. Los modos HDR-TSP y HDR-TSL utilizan uno de los tres símbolos como dígitos ternarios (trits):

Una transición desde SDA y SCL (recibidas con un intervalo de 12,8 ns entre sí), Sólo una transición desde SCL o Sólo una transición desde SDA. Dos bytes más dos bits de paridad (18 bits en total) se dividen en seis tripletes de 3 bits, y cada triplete se codifica como dos trits. A una velocidad de 25 Mtrit / s, se consigue una velocidad de datos efectiva de 33,3 Mbit / s. El par de trits formado por sólo dos transiciones desde SDA no se utiliza para codificar datos, sino para el encuadre que marca el final de una secuencia HDR. Aunque esto limita el tiempo máximo entre transiciones SCL a tres tiempos de trit, esto supera el límite de 50 ns de los dispositivos I²C más antiguos. Por lo tanto, el modo HDR TSP (símbolo ternario, puro) sólo se puede utilizar en un bus sin dispositivos I²C antiguos. Para permitir buses con dispositivos I²C (con un filtro de picos), se debe utilizar el modo HDR-TSL (símbolo ternario, legado). Esto mantiene la compatibilidad I²C mediante el trit stuffing : si tras un flanco ascendente en SCL el trit siguiente no es 0, el transmisor inserta un trit 1 (transición sólo en SCL) y el receptor lo ignora. Esto garantiza que SCL nunca esté alto durante más de un tiempo trit. 

Las siguientes funciones I²C no son compatibles con I3C

Las resistencias pull-up las proporciona el maestro I3C. Las resistencias pull-up externas ya no son necesarias. Estiramiento del reloj - Se espera que los dispositivos sean lo suficientemente rápidos para funcionar a la velocidad del bus. El maestro I3C es la única fuente de reloj. Direcciones I²C ampliadas (10 bits). Todos los dispositivos de un bus I3C se direccionan con una dirección de 7 bits. Los dispositivos I3C nativos tienen una dirección única de 48 bits que sólo se utiliza para asignar direcciones dinámicas.

I3C Tacto y Cámara

I3C contiene numerosas especificaciones diseñadas específicamente para la industria móvil. Estas ampliaciones de las especificaciones para casos de uso específicos van desde la conectividad táctil a la de cámara, por ejemplo, y permiten a los desarrolladores una implementación más sencilla y un ahorro de costes en el desarrollo.
I3C HCI, también se incluye en la familia de especificaciones táctiles I3C  , de modo que se pueden utilizar comandos táctiles y múltiples flujos de datos para añadir capacidades táctiles diferenciadoras a un diseño. Las empresas de procesadores de aplicaciones pueden aplicar la especificación para estandarizar el método HCI utilizado en sus dispositivos. La especificación define varias optimizaciones basadas en el uso típico. Por ejemplo, la función de comando combinado permite transferencias eficientes de una sola vez de escritura y luego de lectura en el bus. Otro ejemplo es el comando automático que puede leer eficazmente un búfer de datos grande en el contexto de interrupciones en banda.