Tutorial protocolo I2C

Tutorial protocolo I2C, aprende y utilízalo

Primer artículo del Tutorial Protocolo I2C desarrollado por Philips. Cuando el fabricante de semiconductores Philips diseñó el protocolo I2C, no se imaginaba que a lo largo de los años se consolidó como uno de los mejores de su categoría. Se utiliza masivamente en la industria automovilística, computadores y en casi todos los miniPC en placas SBS que se diseñan hoy día.

Tutorial protocolo I2C

Introducción al Tutorial protocolo I2C

En este tutorial protocolo I2C, aprenderá todo sobre el protocolo de comunicación I2C, por qué usted necesita usarlo y cómo se implementa en sus proyectos.

hace poco publicamos otro Tutorial I2C a fondo con la intención de que puedan sacar provecho de este maravilloso Bus. Hoy les ofrecemos otra visión muy buena también que esperamos les agrade porque les vamos a ofrecer algunos proyectos muy interesante sobre el Bus I2C.

El I2C es un protocolo destinado a permitir múltiples circuitos integrados digitales “esclavos” ( “chips”) para comunicarse con uno o más chips “maestro”. Al igual que el interfaz serie (SPI), que sólo se diseñó para las comunicaciones de corta distancia dentro de un solo dispositivo. Como Interfaces asíncrono en serie (tales como RS-232 o UARTs) que sólo requiere dos cables de señal para intercambiar información.

Lectura sugerida antes de seguir con el Tutorial protocolo I2C

Cosas que sería útil saber antes de leer este tutorial:

  • Código Binario
  • Comunicación serie
  • Interfaz Periféricos Serie
  • Registros de desplazamiento
  • Los niveles lógicos

¿Por qué utilizar I2C?

Para entender por qué uno podría querer comunicarse a través de I2C, primero hay que compararlo con las otras opciones disponibles para ver en qué se diferencia.

¿Qué está mal con puertos serie?

Diagrama de bloques de un sistema de serie asíncrono.

Debido a que los puertos serie son asíncrono (sin datos del reloj de transmisión), los dispositivos que utilizan deben estar de acuerdo entre ellos antes del envío de datos. Los dos dispositivos también deben tener relojes que están ajustados a la misma velocidad y si hay diferencias excesivas entre las frecuencias de reloj en cada extremo, hará que los datos sean ilegibles.

Los puertos serie asíncronos requieren hardware. La UART en cada extremo es relativamente complejo y difícil de implementar con exactitud en software cuando es necesario. Al menos un bit de arranque y parada es necesario en cada trama de datos, lo que significa que se requieren 10 bits de tiempo de transmisión para cada 8 bits de los datos enviados, que provoca reducir la velocidad de datos.

Otro defecto básico en los puertos serie asíncronos es que son susceptibles de entrar comunicaciones entre los dos y sólo dos dispositivos a la vez. Si bien es posible conectar varios dispositivos a un solo puerto serie, la contención de bus (en el que dos dispositivos intentan conducir la misma línea al mismo tiempo) es siempre un problema y debe ser tratado con cuidado para evitar daños en los dispositivos en cuestión y se hace generalmente a través de hardware externo.

Por último, la velocidad de datos es un problema. Si bien no hay teórica límite a las comunicaciones serie asíncronas, la mayoría de los dispositivos UART sólo admiten un cierto conjunto de velocidades de transmisión fijas y la más alta de ellas es generalmente alrededor de 230.400 bits por segundo.

¿Qué está mal con SPI?

Diagrama de bloques de un sistema SPI

La desventaja más evidente de la comunicación SPI es el número de pines requeridos. Conexión de un solo maestro a un solo esclavo con un bus SPI requiere cuatro líneas; cada esclavo adicional requiere un pin de selección de E / S de chips adicionales en el maestro. La rápida proliferación de las conexiones en paralelo hace que sea deseable en situaciones en las que una gran cantidad de dispositivos deben estar acoplados a un maestro. Además, el gran número de conexiones para cada dispositivo puede hacer que las señales de enrutamiento sea más difícil en las situaciones de diseño de PCB pequeños. El SPI sólo permite un maestro en el bus, pero es compatible con un número arbitrario de esclavos (sujeto solamente a la capacidad de accionamiento de los dispositivos conectados al bus y el número de pines de selección de chips disponibles).

El SPI es bueno para la alta velocidad de datos full-duplex (simultánea envío y recepción de datos) conexiones, que admite velocidades de reloj más de 10 MHz (y por tanto, 10 millones de bits por segundo) para algunos dispositivos. El hardware en cada extremo es generalmente un simple registro de desplazamiento, lo que permite una fácil implementación en software.

Protocolo I2C – El mejor de ambos mundos!

Diagrama de bloques de un sistema de I2C

El bus I2C requiere sólo dos cables, como la serie asíncrono, pero esos dos cables pueden soportar hasta 1008 dispositivos esclavos. Además, a diferencia de SPI, el I2C puede funcionar con un sistema multi-master, lo que permite más de un maestro para comunicarse con todos los dispositivos del bus (aunque los dispositivos maestros no pueden comunicarse entre sí a través del bus y debe esperar su turno en la línea del bus).

La velocidades de datos caen entre serie asíncrono y SPI; la mayoría de dispositivos I2C pueden comunicarse a 100 kHz o 400 kHz. Hay algo de sobrecarga con I2C; por cada 8 bits de datos a enviar, un bit más de los metadatos (los bits “ACK / NACK” que hablaremos más adelante) debe ser transmitida.

El hardware necesario para implementar I2C es más complejo que SPI, pero menos que el serie asíncrono. Puede ser implementado bastante trivialmente en software.

Breve historia del bus I2C

I2C fue desarrollado originalmente en 1982 por Philips para varios chips de Philips. La especificación original, permitió sólo las comunicaciones a 100kHz y proporcionaba únicamente direcciones de 7 bits, lo que limitaba el número de dispositivos en el bus a 112 (hay varias direcciones reservadas que nunca se van a utilizar para direcciones válidas I2C). En 1992, la primera especificación pública se publicó, la adición de una comunicación por encima de los 400kHz y una ampliación del espacio de direcciones a 10 bits. Gran parte del tiempo (por ejemplo, en el dispositivo ATMega328 de muchas placas compatibles con Arduino), dan soporte a dispositivos I2C con este nuevo protocolo. Hay tres modos adicionales que se especifican: rápido en modo positivo a 1 MHz; modo de alta velocidad a 3.4MHz y modo ultra-rápido a 5 MHz.

Además Intel introdujo una variante en 1995 llamado “bus de gestión del sistema” (SMBus). SMBus es un formato más estrechamente controlado, que intenta maximizar la previsibilidad de las comunicaciones entre los circuitos integrados de apoyo en las placas base de PC. La diferencia más significativa entre SMBus es que limita la velocidad de 10 kHz a 100 kHz, mientras que I2C puede soportar dispositivos de 0kHz a 5 MHz. SMBus incluye un modo de tiempo de espera de reloj para operaciones de baja velocidad.

I2C a nivel de hardware

Señales

Cada I 2 autobuses C consta de dos señales: SCL y SDA. SCL es la señal de reloj, y SDA es la señal de datos. La señal de reloj se genera siempre por el maestro de bus actual; algunos dispositivos esclavos pueden forzar el reloj de baja a veces para retrasar el envío de más datos maestros (o requerir más tiempo para preparar los datos antes de maestro intenta reloj hacia fuera). Esto se conoce como “reloj de estiramiento” y se describe en la página de protocolo.

A diferencia de las conexiones UART o SPI, los I 2 conductores de autobús C son “drenaje abierto” , lo que significa que puede tirar de la línea de señal correspondiente baja, pero no pueden conducir en alto. Por lo tanto, no puede haber conflicto de bus, donde un dispositivo está tratando de impulsar la línea de alta, mientras que otro trata de sacarlas de allí baja, lo que elimina la posibilidad de daños a los conductores o excesiva disipación de potencia en el sistema. Cada línea de señal tiene una resistencia pull-up en él, para restaurar la señal de alto cuando no hay ningún dispositivo está afirmando que baja.

Esquema equivalente del circuito interno de un sistema I2C.

Fíjese en las resistencias pull-up de las dos líneas de comunicación.

Selección de la resistencia varía con dispositivos en el bus, pero una buena regla general es comenzar con 4.7k y ajustar hacia abajo si es necesario. I 2 C es un protocolo bastante robusta, y se puede utilizar con recorridos cortos de alambre (2-3m). Para carreras largas, o sistemas con una gran cantidad de dispositivos, resistencias más pequeñas son mejores.

los niveles de señal

Dado que los dispositivos del bus en realidad no conducen las señales de alto, 2 C permite una cierta flexibilidad en dispositivos con diferentes voltajes de entrada / salida de conexión. En general, en un sistema en el que un dispositivo está en un voltaje más alto que el otro, puede ser posible para conectar los dos dispositivos a través de I 2 C sin ningún cambio de nivel de circuitos entre ellos. El truco consiste en conectar las resistencias pull-up a la menor de las dos tensiones. Esto sólo funciona en algunos casos, cuando la menor de las dos tensiones de la red es superior a la tensión de entrada de alto nivel del sistema, por ejemplo, el voltaje más alto, un Arduino 5V y un acelerómetro de 3.3V.

Si la diferencia de tensión entre los dos sistemas es demasiado grande (por ejemplo, 5 V y 2,5 V), Sparkfun ofrece una sencilla placa I2C . Dado que también incluye una línea de habilitación, que se puede utilizar para deshabilitar las comunicaciones a los dispositivos seleccionados. Esto es útil en los casos en los que es más de un dispositivo con la misma dirección para ser conectado a un único maestro -Wii Nunchucks son un buen ejemplo.

Protocolo

Comunicación a través de I 2 C es más compleja que con un UART o solución SPI. La señalización debe adherirse a un protocolo determinado para los dispositivos en el bus a la reconocen como válidos I 2comunicaciones C. Afortunadamente, la mayoría de los dispositivos se encargan de todos los detalles complicados para usted, lo que le permite concentrarse en los datos que desea intercambiar.

Lo esencial

Estándar mensaje de transferencia dirección de 7 bits.

Los mensajes se dividen en dos tipos de trama: un bloque de dirección, donde el maestro indica que el esclavo al que se envía el mensaje, y una o más tramas de datos, que son mensajes de datos de 8 bits se transmiten de maestro a esclavo o viceversa . Los datos se coloca en la línea SDA SCL después pasa a nivel bajo, y se tomaron muestras después de la línea SCL pasa a nivel alto. El tiempo entre flanco de reloj y datos de lectura / escritura se define por los dispositivos en el bus y variará de chip para chip.

Condición de inicio

Para iniciar el bloque de dirección, el dispositivo maestro deja SCL alta y tira de SDA baja. Esto pone a todos los dispositivos esclavos sobre aviso de que una transmisión está a punto de comenzar. Si dos dispositivos maestros desean tomar posesión del autobús a la vez, el dispositivo que tira de SDA bajos primero gana el control de carrera y las ganancias del autobús. Es posible emitir arranques repetidos, iniciando una nueva secuencia de comunicación sin renunciar al control del bus a otros maestros; hablaremos de eso más tarde.

Frame Dirección

La trama de dirección es siempre el primero en cualquier nueva secuencia de comunicación. Para una dirección de 7 bits, la dirección se registraron hacia fuera el bit más significativo (MSB) en primer lugar, seguido de un bit R / W que indica si se trata de una (1) o escribir (0) operación de lectura.

El bit noveno de la trama es el bit NACK / ACK. Este es el caso para todas las tramas de datos (o dirección). Una vez que se envían los primeros 8 bits de la trama, el dispositivo de recepción se da control sobre SDA. Si el dispositivo receptor no tire de la línea SDA baja antes de que el impulso de reloj 9ª, se puede inferir que el dispositivo receptor, o bien no ha recibido los datos o no sabía cómo analizar el mensaje. En ese caso, el intercambio se detiene, y le toca a la maestra del sistema para decidir cómo proceder.

Las tramas de datos

Después de la trama de dirección ha sido enviado, los datos pueden comenzar a ser transmitida. El maestro simplemente continuará generando pulsos de reloj a intervalos regulares, y los datos serán colocados en SDA por el maestro o el esclavo, dependiendo de si el bit R / W indica una lectura o escritura. El número de tramas de datos es arbitraria, y la mayoría de los dispositivos esclavos se auto-incremento del registro interno, lo que significa que la posterior lee o escribe procederá de la siguiente registro en la fila.

Condición de parada

Una vez que se han enviado todas las tramas de datos, el maestro generará una condición de parada. Condiciones de parada se definen por una transición 0-> 1 (menor a mayor) en SDA después de una transición 0-> 1 en SCL, con SCL restante alta. Durante el funcionamiento normal de escritura de datos, el valor en SDA debe no cambia cuando SCL es alta, para evitar condiciones de parada falsos.

Temas avanzados de protocolo

Las direcciones de 10 bits

dirección de 10 bits enmarca ejemplo.

En un sistema de direccionamiento de 10 bits, se requieren dos marcos para transmitir la dirección del esclavo. El primer cuadro estará formado por el código b11110xyz, donde “x” es el MSB de la dirección del esclavo, y es el bit 8 de la dirección del esclavo, y z es el bit de lectura / escritura como se describió anteriormente. bit ACK del primer fotograma será afirmada por todos los esclavos que se ajustan a los dos primeros bits de la dirección. Al igual que con una transferencia normal de 7 bits, otra transferencia se inicia inmediatamente, y esta transferencia contiene los bits 7: 0 de la dirección. En este punto, el esclavo direccionado debe responder con un bit de ACK. Si no lo hace, el modo de fallo es el mismo que un sistema de 7 bits.

Tenga en cuenta que los dispositivos de dirección de 10 bits pueden coexistir con los dispositivos de dirección de 7 bits, ya que no forma parte de ninguna de las direcciones de 7 bits válidos del ‘11110’ parte principal de la dirección.

Condiciones de arranque repetidos

Una condición de arranque repetido.

A veces, es importante que dispongan de un dispositivo maestro de intercambiar varios mensajes de una sola vez, sin permitir que otros dispositivos maestro en el bus de interferir. Por esta razón, la condición de arranque repetido se ha definido.

Para realizar un arranque repetido, SDA se le permite ir de alta, mientras que SCL es baja, SCL se le permite ir de alta, y luego se pone SDA baja de nuevo mientras SCL es alta. Debido a que no había estado parada en el autobús, la comunicación previa no fue verdaderamente completa y el maestro actual mantiene el control del bus.

En este punto, el siguiente mensaje puede comenzar la transmisión. La sintaxis de este nuevo mensaje es el mismo que cualquier otro telegrama-una dirección seguida de tramas de datos. Se permite cualquier número de arranques repetidos, y el maestro mantendrá el control del autobús hasta que se emite una condición de parada.

reloj de estiramiento

Un esclavo usando el reloj de estiramiento para retrasar la siguiente trama de datos.

A veces, la velocidad de datos del maestro será superior a la capacidad del esclavo para proporcionar esos datos. Esto puede deberse a que los datos no están listos todavía (por ejemplo, el esclavo no ha completado un convertidor analógico-digital de conversión aún) o debido a una operación anterior todavía no se ha completado (por ejemplo, una EEPROM, que no se ha completado escrito a la memoria no volátil y todavía tiene que terminar antes de que que puede dar servicio a otras solicitudes).

En este caso, algunos dispositivos esclavos ejecutarán lo que se conoce como “reloj de estiramiento”. Nominalmente, todos de reloj es impulsado por los maestros de dispositivos esclavos simplemente poner datos en el bus de datos o tomar el autobús en respuesta a pulsos de reloj del maestro. En cualquier momento del proceso de transferencia de datos, un esclavo direccionado puede mantener el bajo de línea SCL después de que los maestros lo libera. Se requiere que el maestro que se abstengan de pulsos de reloj adicionales o de transferencia de datos hasta que el esclavo libera la línea SCL.

Yendo más lejos y recursos

I2C no es una interfaz relativamente complejo y hay muchos recursos para poder utilizarlo en sus proyectos electrónicos. A continuación se presentan algunos de los sitios más informativos.

  • Artículo de Wikipedia sobre el I 2 C – No es genial, pero no es un lugar terrible para empezar.
  • Doc normas – Phillips Semiconductor convirtió NXP hace unos años; este es el doc normas oficiales para I 2 C.
  • I 2 C – ORG – El sitio oficial del bus I 2 C y tecnologías relacionadas.
  • Herramientas de Linux para I 2 C – Un buen conjunto de herramientas para trabajar con I 2 C y buses relacionados en entornos Linux embebido, como pcDuino o Frambuesa Pi.

Más adelante les presentaremos unos proyectos para que lo aprendido en este tutorial protocolo I2C puedas aprender de manera práctica a utilizarlo y muy especialmente en los Microcontroladores PIC. Son proyectos con el código en CCS Compiler y probados tanto en circuito real como simulado en Proteus. Hasta entonces amigos lectores, repasen bien este tutorial y el anterior que publicamos aquí.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *