Autor: Robert Perkel, Ingeniero de Aplicaciones de la unidad de negocio de microcontroladores de 8 bits de Microchip
I3C® es un nuevo protocolo de comunicación en serie para sistemas embebidos que ofrece una velocidad de transmisión de los datos considerablemente mayor y más funciones avanzadas que I2C. Con I3C, ingenieros y diseñadores pueden mejorar el rendimiento de sus diseños y añadir nuevas funciones como los modos Hot-Join, IBI (In-Band Interrupts) y HDR (High Data Rate). Además I3C es compatible y se puede comunicar con dispositivos I2C. La Tabla 1 resume sus diferencias respecto a I2C.
Tabla 1. Principales diferencias entre I3C e I2C.
Velocidad del bus
El cambio más evidente entre I2C y I3C es la velocidad del reloj. I2C suele ser de 100 kHz, 400 kHz o
1 MHz, mientras que I3C puede alcanzar una velocidad de hasta 12,5 MHz. Uno de los principales factores para este incremento es el uso de salidas en contrafase (push-pull) en I3C. Los interruptores I3C situados entre los drivers de drenador abierto y en contrafase dependen del estado del bus. El drenador abierto se usa durante el direccionamiento inicial o el arbitraje cuando varios dispositivos de destino pueden controlar la línea al mismo tiempo. Por su parte, se utiliza la configuración en contrafase cuando la comunicación es unidireccional y no existe la posibilidad de que otro dispositivo se comunique al mismo tiempo.
Características eléctricas
A diferencia de I2C, I3C no necesita resistencias externas de polarización (pull-up) ya que las proporciona el controlador principal en el bus. I2C tiene un amplio rango de funcionamiento, si bien 3,3V y 5V son los valores más comunes. I3C tiene tres niveles nominales: 1,2V, 1,8V y 3,3V. No obstante, admite otros.
Direccionamiento del dispositivo
I2C admite 7 bits y 10 bits para el direccionamiento de dispositivos, mientras que I3C solo admite direccionamiento de 7 bits. Sin embargo, I3C usa direccionamiento dinámico, es decir, el controlador activo asigna a cada dispositivo de destino una dirección única para evitar la colisión entre direcciones. Esto contrasta con I2C, en el que los desarrolladores deben hacer un seguimiento de las direcciones utilizadas para evitar que dos dispositivos compartan la misma dirección. El direccionamiento dinámico de los dispositivos de destino se produce durante la inicialización del bus.
Interrupciones IBI (In-Band Interrupts) y función Hot-Join
En I2C no hay ningún mecanismo para que un dispositivo indique al controlador que los datos están listos sin utilizar otra línea de E/S. En I3C, en cambio, los dispositivos pueden enviar una señal de interrupción mediante las líneas SDA y SCL, por lo que se convierte en un verdadero protocolo de dos hilos. Del mismo modo, este tipo de señalización en banda también se utilizan para implementar la función de conexión en caliente (hot-join) en I3C, por lo que los dispositivos se pueden conectar tras la asignación inicial de direcciones. La sección dedicada a interrupciones IBI (In-Band Interrupts) y arbitraje de direcciones lo describirá más adelante con detalle.
Controladores activos y controladores secundarios
I2C admite buses multicontrolador, de manera que varios dispositivos funcionan como controladores pero solo uno se comunica activamente en un momento determinado. Sin embargo, en I3C solo un dispositivo puede ser el controlador activo; es posible que otros dispositivos soliciten convertirse en el controlador del activo en el bus. Este dispositivo se denomina controlador secundario. Cuando un controlador secundario no actúa como controlador activo, funciona un dispositivo de destino de I3C.
Compatibilidad con I2C
I3C admite la comunicación con dispositivos I2C. Para que la comunicación sea posible, los dispositivos de destino de I2C deben cumplir estos requisitos:
- Tener una dirección de 7 bits
- No estirar el reloj
También se recomienda encarecidamente que el dispositivo de destino de I2C contenga filtros de 50ns en sus entradas. Si se cumplen estos requisitos, el dispositivo de I2C es compatible con el bus I3C. Además, algunos dispositivos I3C pueden funcionar como dispositivos de destino de I2C hasta que se asigne una dirección dinámica. Mientras se encuentra en modo I2C, el dispositivo I3C tiene una dirección estática para la comunicación. Esta dirección estática no tiene por qué ser igual a la dirección dinámica, pero se le puede asignar la misma si se desea. A continuación se puede ver un ejemplo de bus I3C.
Figura 1. Ejemplo de un posible bus I3C.
Aspectos básicos de la comunicación I3C
Antes de que empiece cualquier comunicación en un bus I3C, se ha de configurar el bus y se han de asignar las direcciones dinámicas a los dispositivos de destino.
Luego empieza la comunicación como I2C. Se genera una condición START y después se envía una dirección dinámica de 7 bits, con un bit R/nW seguido por un ACK o NACK del dispositivo de destino. A continuación, I3C usa transferencias en serie de 9 bits como I2C, pero la función del 9º bit se ha cambiado de ACK / NACK a un bit de Transición o bit T, que tiene dos funciones. Cuando el controlador está escribiendo en un dispositivo de destino, el bit T es un bit de paridad impar del byte de datos enviado. Cuando un controlador está leyendo de un destino, el bit T se usa como indicador de Fin de datos. Este indicador puede ser emitido por el controlador para señalar que ha terminado de leer datos o por el dispositivo de destino para señalar que no tiene más datos por devolver. Para finalizar la transferencia de datos, el controlador genera la condición STOP o RESTART en el bus. Obsérvese que, si se utiliza un RESTART, la cabecera se transmite en forma de contrafase ya que no hay arbitraje.
Figura 2. Diagrama simplificado de la transferencia de datos en I3C (para 1 byte de datos).
Un cambio crucial con I3C es que no hay estiramiento del reloj. I2C usa estiramiento del reloj para dar más tiempo de proceso a los dispositivos de destino antes de devolver los datos. Con I3C, el reloj solo es dirigido por el controlador activo y en modo SDR (Single Data Rate). Por tanto, el estiramiento del reloj solo puede ser efectuado por el controlador bajo unas determinadas circunstancias.
No obstante, el dispositivo puede indicar restricciones de velocidad durante el proceso de inicialización del bus con el fin de indicar una frecuencia máxima de funcionamiento, tiempos de lectura y escritura y otros parámetros de sincronización.
Códigos CCC (Common Command Codes)
Los códigos CCC (Common command codes) son un nuevo concepto en I3C y son utilizados por el controlador activo para inicializar y/o configurar el bus I3C. Los CCC se pueden transmitir a cualquier dispositivo de destino o se pueden dirigir a un destino determinado de forma privada. Para enviar un CCC, envía primero la dirección 7’h7E/W. Todos los dispositivos I3C deben reconocer y leer esta dirección. Los dispositivos I2C no admiten esta dirección ya que 7’h7E está reservada para la especificación I2C. A continuación envía el código CCC. Para los CCC que escriben datos en los dispositivos de destino, continúa enviando datos hasta finalizar. Para los CCC que leen valores, envía cualquier parámetro (según las necesidades), reinicia el bus y empieza a leer los datos.
Hay demasiados CCC como para comentarlos en este artículo; estos son algunos de los más importantes:
ENTDAA (Enter Dynamic Address Assignment)
ENTDAA notifica a todos los dispositivos de destino que el controlador activo está asignando direcciones dinámicas. Si un dispositivo de destino ya tiene una dirección asignada, no reconocerá este comando.
SETNEWDA (Set New Dynamic Address Assignment)
SETNEWDA se usa para cambiar la dirección dinámica de un dispositivo.
ENEC (Enable Events) / DISEC (Disable Events)
Los comandos ENEC o DISEC indican si en ese momento se permiten eventos como la conexión en caliente (Hot-Join) o las interrupciones IBI (In-Band Interrupts) en el bus.
RSTDAA (Reset Dynamic Address Assignment)
RSTDAA borra la dirección asignada actualmente pero no reasigna otra. En v1.1 de la especificación I3C se ha descartado la forma directa de RSTDAA.
SETMRL (Set Max Read Length) / Get Max Read Length (GETMRL)
SETMRL o GETMRL especifican el número máximo de bytes que se pueden leer en un momento determinado.
Set Max Write Length (SETMWL) / GETMWL (Get Max Write Length)
SETMWL o GETMWL establecen el número máximo de bytes que se pueden leer o escribir en un momento determinado.
GETDCR (Get Device Characteristics Register)
DCR (Device Characteristics Register) es un registro que especifica el tipo de dispositivo de destino. Un ejemplo sería el código 0xC6, el código para un microcontrolador. La especificación I3C define los valores del DCR. La MIPI® Alliance ofrece una lista de los códigos disponibles.
GETBCR (Get Bus Characteristics Register)
BCR (Bus Characteristics Register) es un registro que define las capacidades de I3C presentes en el dispositivo de destino. Este registro también se usa para determinar si se necesita una restricción de la velocidad para el dispositivo de destino.
RSTACT (Target Reset Action)
RSTACT define qué les sucede a los dispositivos de destino cuando se detecta un patrón de reinicio. Para generar un reinicio, SDA se mantiene en nivel bajo mientras transcurren 14 ciclos de reloj de SCL, seguido de un reinicio y un STOP. Los dispositivos de destino detectan el patrón de reinicio y actúan en de acuerdo con lo que se les haya asignado. Este CCC no activa un reinicio pero asigna una respuesta al dispositivo de destino. Si no se reinicia tras este comando, la siguiente condición START borrará la acción asignada.
ENTHDRx (Enter High Data Rate Mode)
Finalmente se encuentra ENTHDRx; este CCC indica que el controlador activo está aplicando uno de los 4 modos HDR (0, 1, 2 o 3).
Modos HDR (High Data Rate)
La especificación I3C define actualmente 4 modos HDR.
- HDR-DDR (HDR Double Data Rate) [Modo 0]
- HDR-TSP (HDR Ternary Symbol Pure-bus) [Modo 1]
- HDR-TSL (HDR Ternary Symbol Legacy-inclusive-bus) [Modo 2]
- HDR-BT (HDR Bulk Transport) [Modo 3]
En HDR, la velocidad del reloj no cambia pero sí cambia la manera de codificar los datos. HDR no es imprescindible para la comunicación básica de I3C. Los dispositivos que no admiten HDR ignoran la comunicación hasta que detectan el patrón de salida de HDR.
HDR-DDR
HDR-DDR es un modo que usa ambos flancos del reloj para transmitir datos. Esto incrementa notablemente la velocidad de transmisión de los datos en el bus (pero no la duplica debido a la sobrecarga que supone para el protocolo).
HDR-TSP y HDR-TSL
En HDR-TSP y HDR-TSL, los datos se transmiten en código ternario, con tres símbolos definidos creados en las líneas SDA y SCL. De acuerdo con la especificación, los símbolos se definen eléctricamente por:
- Solo cambia SCL
- Solo cambia SDA
- Cambian SCL y SDA
La elección entre HDR-TSP y TDR-TSL se basa en si hay presente un dispositivo de destino I2C. HDR-TSP solo se puede utilizar en presencia de dispositivos de destino I3C, mientras que HDR-TSL se usa en presencia de un dispositivo de destino I2C.
HDR-BT
HDR-BT permite utilizar varias líneas de datos al mismo tiempo para aumentar el paralelismo. Para que sean compatibles, solo se usa el bit menos significativo, o LSB, de la línea SDA para la comunicación SDR (Single Data Rate). HDR-BT admite configuraciones de dos y cuatro líneas. La Figura 3 muestra un ejemplo de configuración.
Figura 3. Ejemplo de un bus I3C mixto que admite HDR-BT.
Interrupciones IBI (In-Band Interrupts) y arbitraje de direcciones
A diferencia de I2C, los dispositivos de destino pueden generar una condición de inicio de IBI cuando el bus está en reposo (o libre). Esto ocurre si no se producen transacciones durante un cierto tiempo. Cuando el controlador activo detecta una condición de inicio procedente del dispositivo de destino, suministra la señal de reloj para completar la transacción. Si dos dispositivos de destino intentan comunicarse simultáneamente se efectuará un arbitraje del direccionamiento.
El arbitraje es el proceso consistente en determinar a qué dispositivo se le permite comunicarse con el controlador. Imaginemos, por ejemplo, que dos dispositivos A y B se quieren comunicar con el controlador activo simultáneamente. El dispositivo A tiene una dirección de 7’h10, mientras que el dispositivo B tiene una dirección de 7’h14. Cuando se genera una interrupción en banda, ambos dispositivos intentarán transmitir su dirección al controlador activo. En este estado del bus, la línea de datos está en drenador abierto. Durante la comunicación en drenador abierto, la línea vuelve de manera pasiva a “1” por medio de una resistencia de polarización y se puede llevar activamente a “0”. Esto evita que se produzca un cortocircuito cuando ambos dispositivos transmiten 1 y 0 al mismo tiempo.
Figura 4. Vista simplificada de la línea SDA (la resistencia de polarización está integrada en el controlador principal).
La dirección ganadora en el arbitraje es la que recibe el controlador. Como se puede ver en la figura 5, en primer lugar se transmiten dos ceros desde la dirección de cada dispositivo. A continuación, ambos liberarán la línea de datos para el “1” en su dirección. A continuación ambos transmitirán otro 0. En este momento ningún dispositivo ha ganado el arbitraje ya que la dirección recibida iguala a ambos. Pero con el siguiente uno de los dispositivos de destino liberará la línea de datos para enviar un “1” mientras el otro intenta enviar un “0”. El transmisor del “1” perderá el arbitraje porque el “1” es dirigido de forma pasiva por la configuración de drenador abierto mientras el otro dispositivo de destino mantiene activamente el “0”. Al completar el resto de la secuencia de transmisión se puede ver que el controlador recibió la dirección 7’h10, no 7’h14. Por tanto, el dispositivo B perdió el arbitraje y dejó de comunicarse. En el arbitraje de I3C, la dirección más alta siempre perderá y se concederá al dispositivo con la dirección más baja.
Figura 5. Ejemplo de arbitraje de I3C con las direcciones 7’h10 y 7’h14.
Conclusión
I3C proporciona un aumento significativo del ancho de banda del bus serie, así como muchas funciones nuevas. Este artículo ha revisado las funciones de mayor nivel y las características del bus pero no trata de ofrecer una lista exhaustiva de las posibles funciones y comandos. La especificación de I3C se encuentra disponible a través de la MIPI Alliance.
