Lo básico acerca de este protocolo de comunicación.
Introducción
Antes de referirnos a los detalles del proyecto desarrollado con el protocolo I2C me ha parecido conveniente dejar información acerca del protocolo, esto con el fin de entender como funciona este.
I2C son las siglas de inter-integrated circuits (circuitos inter-integrados) y se trata de un bus de comunicación en serie desarrollado por Phillips. La primera versión 1.0 fue lanzada en 1992.
Tiene una velocidad de 100kbits/s pudiendo alcanzar velocidades de 3.4Mbits/s.
Su importancia radica en el hecho de que es muy utilizado en la industria para la comunicación de microcontroladores y sus periféricos en sistemas embebidos.
Características
La caraterística de este protocolo es que solo utiliza dos líneas para transmitir información: Una línea de datos (SDA) y una línea para la señal de reloj (SCL o SCK). Adicionalmente se agrega la tierra (GND) que aunque bien es una tercera línea no transmite información y su única finalidad es de referencia.
Las líneas de SDA y SCK son de drenador abierto. Esto amerita que deba utilizarse una resistencia de pull-up para su funcionamiento.
Los dispositivos conectados al bus pueden ser maestros o esclavos. El dispositivo maestro puede iniciar la transferencia de datos y dar la señal de reloj pero no es necesario que el dispositivo maestro sea siempre el mismo. Esto es, que dicha característica se puede ir pasando entre los dispositivos que tengan esta capacidad. Por esta propiedad, al protocolo I2C se le conoce como multimaestro.
¿Cómo se realiza la comunicación?
Las transacciones se realizan con el siguiente formato
Y los pasos son los siguientes:
El bus esta libre cuando SDA y SCL están en estado lógico alto.
En estado bus libre, cualquier dispositivo puede ocupar el bus I2C como maestro.
El maestro comienza la comunicación enviando un patrón llamado "start condition". Esto alerta a los dispositivos esclavos, poniéndolos a la espera de una transacción.
El maestro se dirige al dispositivo con el que quiere hablar, enviando un byte que contiene los siete bits (A7-A1) que componen la dirección del dispositivo esclavo con el que se quiere comunicar, y el octavo bit (A0) de menor peso se corresponde con la operación deseada (L/E), lectura=1 (recibir del esclavo) y escritura=0 (enviar al esclavo).
La dirección enviada es comparada por cada esclavo del bus con su propia dirección, si ambas coinciden, el esclavo se considera direccionado como esclavo-transmisor o esclavo-receptor dependiendo del bit R/W.
El esclavo responde enviando un bit de ACK que le indica al dispositivo maestro que el esclavo reconoce la solicitud y está en condiciones de comunicarse.
Seguidamente comienza el intercambio de información entre los dispositivos.
El maestro envía la dirección del registro interno del dispositivo que se desea leer o escribir.
El esclavo responde con otro bit de AC
Ahora el maestro puede empezar a leer o escribir bytes de datos. Todos los bytes de datos deben constar de 8 bits, el número máximo de bytes que pueden ser enviados en una transmisión no está restringido, siendo el esclavo quien fija esta cantidad de acuerdo a sus características.
Cada byte leido/escrito por el maestro debe ser obligatoriamente reconocido por un bit de ACK por el dispositivo maestro/esclavo.
Se repiten los 2 pasos anteriores hasta finalizar la comunicación entre maestro y esclavo.
Aun cuando el maestro siempre controla el estado de la línea del reloj, un esclavo de baja velocidad o que deba detener la transferencia de datos mientras efectúa otra función, puede forzar la línea SCL a nivel bajo. Esto hace que el maestro entre en un estado de espera, durante el cual, no transmite información esperando a que el esclavo esté listo para continuar la transferencia en el punto donde había sido detenida.
Cuando la comunicación finaliza, el maestro transmite una "stop condition" para dejar libre el bus.
Después de la "stop condition", es obligatorio para el bus estar idle durante unos microsegundos.
El código del kernel de Linux para el soporte I2C está separado en varias piezas lógicas:
I2C chip driver (maneja uno de los chips conectados al bus I2C, tanto si se comporta como maestro o como esclavo)
I2C bus driver
I2C algorithm driver
I2C core (la parte genérica del subsistema de I2C)
Y así es como se hace la comunicación n I2C. La ventaja de ya que sea un bus ya estandarizado permite que haya bibliotecas o bloques de código para algunos microcontroladores que nos permitan realizar todos los procesos de forma sencilla sin tener que estar "reinventado" o rompiendonos tanto la cabeza al realizar la comunicación.
Personalmente no había manejado esta interfaz de comunicación, pero no es muy difícil como lo pude comprobar hice un par de pruebas simuladas con el ISIS usando un 18f4550 y un par de memorias EEPROM, creo que de las principales ventajas es el menor uso de cables y como desventaja que tiene un numero limitado de direccionamiento.
ResponderEliminarDespués de leer como funciona creo que es más fácil que SPI
ResponderEliminarEn lo particular no he tenido la oportunidad de manejar este tipo de comunicación pero de acuerdo a lo publicado puedo coincidir en que muestra ser más fácil que la comunicación por SPI, debido a las líneas de comunicación que maneja ya que la SPI maneja 4(MOSI, MISO, SCK,SS) y el I2C sólo 2(SDA y SCL) usando GND como referencia. Buen aporte me sirvió bastante la información :)
ResponderEliminarYo tampoco había trabajado con este tipo de comunicación, es bueno el haber mencionado la característica de que las líneas SDA y SCK vayan conectadas a una resistencia en pull-up para futuros visitantes a tu foro, ya que en nuestro equipo en un principio no las colocamos de esta forma y teníamos ligeras fallas.
ResponderEliminarNo había tenido la oportunidad de trabajar directamente con este protocolo de comunicación directamente, al trabajar con el freesoc tuvimos que hacer prácticamente nuestra librería para el acelerometro pero definitivamente el I2C a comparacion del SPI es un protocolo mas organizado al momento de enviar y recibir los datos, definitivamente prefiero el I2C que el SPI y ademas de que el I2C trabaja con 2 cables y el spi con 3 o 4 cables.
ResponderEliminarSaludos, yo si había tenido la oportunidad de trabajar con el I2C, leyendo una memoria EEPROM en la materia de Interfaces con el maestro Romero, personalmente pienso que el I2C es más amigable que el SPI, pero el protocolo y la dificultad realmente lo pone el dispositivo que será leído o con el que se realizará la interfaz. Como en SPI no existe una secuencia de envío y recepción en ocasiones se vuelve un poco tedioso a diferencia del I2C.
ResponderEliminarLa verdad no había meneado antes este bus de comunicación, no pasaba de la UART, pero es sencillo de utilizar y muy organizado a la hora de lecturas y escrituras, solo hay que tener sus debidos cuidados en los direccionamientos y es casi un hecho que tu comunicación sera exitosa. Por otra parte es cómodo solo trabajar con dos cables para la comunicación. También tiene como característica que en el maestro no siempre debe de ser el mismo en el sistema se puede ir pasando el maestro a los otros dispositivos que tengan esa capacidad. Es por eso que se le domina al I²C bus multimaestro.
ResponderEliminarbueno, al igual que lucio yo no había trabajado con esta forma de comunicación, solamente había trabajado con la UART, pero algo que me agrado es el hecho de que solo son dos hilos uno para reloj y el otro para la transferencia. igual considero que es mas rápido que la UART.
ResponderEliminar