Archivo de la etiqueta: Comunicación

¿Qué es la comunicación serie?

La electrónica integrada se conforma con circuitos interconectados (procesadores u otros circuitos integrados) para crear un sistema en el que están repartidas las funciones. Para que esos circuitos individuales intercambien su información, deben compartir un protocolo de comunicación común. Se han definido muchos protocolos de comunicación para lograr este intercambio de datos y, esencialmente, cada uno puede ubicarse en una de dos categorías: 1. Paralelo o 2. Serie.

Paralelo versus serie

Las interfaces paralelas transfieren múltiples bits simultáneamente. Por lo general, requieren barras (buses) de datos, que se transmiten a través de ocho, dieciséis o más cables. Los datos se transfieren en amplios oleajes de 1s y 0s.

Un bus de datos de 8 bits, controlado por un reloj,
que transmite un byte por cada pulso de reloj. Se utilizan 9 líneas


En cambio, las interfaces serie transmiten sus datos un bit a la vez. Estas interfaces pueden operar con tan solo un cable, por lo general nunca más de cuatro.

Ejemplo de una interfaz serie, transmitiendo un bit cada pulso de reloj. Solo se requieren 2 cables


Piense en las dos interfaces como una fila de automóviles: una interfaz paralela sería una autopista de 8 carriles o más, mientras que una interfaz en serie es más parecida a una carretera de dos carriles. Durante un lapso determinado, la autopista tiene el potencial de llevar a más personas a destino, pero en muchos casos ese sistema sencillo de dos carriles responde a su propósito, y construirlo cuesta una fracción de los fondos.

La comunicación paralela ciertamente tiene sus beneficios. Es rápida, directa y relativamente fácil de implementar. Pero requiere muchas más líneas de entrada/salida (E/S). Si alguna vez ha tenido que traspasar un proyecto de un Arduino Mega a un Arduino UNO básico, sabe que las líneas de E/S en un microprocesador pueden ser preciosas por lo limitadas. Por lo tanto, cada vez más optamos por la comunicación en serie, sacrificando una velocidad potencial para ahorrar pines.

Serie asíncrono (asincrónico)

A lo largo de los años, se han creado docenas de protocolos en serie para satisfacer las necesidades particulares de los sistemas integrados. USB (Universal Serial Bus = Bus Serie Universal) y Ethernet son dos de las interfaces serie de computación más conocidas en la actualidad. Otras interfaces serie muy comunes son SPI (del inglés Serial Peripheral Interface), I²C (del inglés Inter-Integrated Circuit) y el interfaz serie estándar TX/RX, del que hablaremos aquí. Estas interfaces serie pueden clasificarse en uno de dos grupos: sincrónico o asincrónico.

Una interfaz serie sincrónica siempre necesita tener una señal de reloj junto a las líneas de datos, por lo que todos los dispositivos en un bus serie sincrónico comparten un pulso común de reloj. Esto hace que en una transferencia en serie más directa, a menudo más rápida, también se requiera al menos un cable adicional entre los dispositivos de comunicación. Entre los ejemplos de interfaces sincrónicas están SPI e I²C.

Asincrónico significa que los datos se transfieren sin el respaldo de una señal de reloj conectada entre sistemas. Este método de transmisión es ideal para minimizar los cables necesarios, y en consecuencia la cantidad de pines de E/S utilizados, pero implica que debemos poner un poco de esfuerzo adicional en transferir y recibir datos de manera confiable. El protocolo en serie que analizaremos es la forma más común para las transferencias asincrónicas. De hecho, es tan común que cuando la mayoría de la gente dice «en serie», “o serial”, están hablando sobre este protocolo.

El protocolo serie sin reloj que analizaremos se usa ampliamente en electrónica integrada. Si está buscando agregar un módulo serie GPS, Bluetooth, XBee, LCD, o muchos otros dispositivos externos a su proyecto, es probable que necesite un interfaz serie.

Reglas de la comunicación serie

El protocolo serie asincrónico tiene una serie de reglas integradas: mecanismos que ayudan a garantizar transferencias de datos sólidas y sin errores. Estos mecanismos, que obtenemos para evitar la señal del reloj externo, son:

   ■ Bits de datos
   ■ Bits de sincronización
   ■ Bits de paridad
   ■ Velocidad en baudios

Teniendo en cuenta la variedad de estos mecanismos de señalización, vemos que no hay una sola manera de enviar datos en serie. El protocolo es altamente configurable. La parte crítica es asegurarse de que ambos dispositivos en una línea serie estén configurados para usar exactamente los mismos protocolos.

Velocidad en baudios

La especificación de velocidad de transmisión indica qué tan rápido se envían los datos a través de una línea serie. Normalmente se expresa en unidades de bits por segundo (bps). Si se invierte la velocidad en baudios, se puede averiguar cuánto tiempo se tarda en transmitir cada bit. Este valor determina durante cuánto tiempo el transmisor mantiene en alto/bajo una línea serie, o a qué velocidad muestrea su línea el dispositivo receptor.

Las velocidades en baudios pueden ser casi cualquier valor dentro de lo que permite el hardware. El único requisito es que ambos dispositivos funcionen a la misma velocidad. Una de las velocidades en baudios más comunes, especialmente para cosas simples donde la velocidad no es crítica, es de 9600 bps. Otras velocidades en baudios «estándar» son 1200, 2400, 4800, 19200, 38400, 57600 y 115200.

Cuanto mayor sea la velocidad en baudios, más rápido se envían/reciben los datos, pero existen límites para la velocidad a la que se pueden transferir los datos. Por lo general, no verá velocidades superiores a 115200, lo que es suficientemente rápido para la mayoría de los microcontroladores. Aumente demasiado y comenzará a ver errores en el extremo receptor, ya que los pulsos de reloj y los períodos de muestreo no pueden mantenerse.

Estructurando los datos

Cada bloque de datos (generalmente un byte) que se transmite se envía en realidad en un paquete de bits. Los paquetes se crean agregando bits de sincronización y paridad a nuestros datos.

Algunos símbolos en la estructura del paquete tienen tamaños de bits que son configurables.

Vamos a entrar en los detalles de cada una de estas partes de la estructura del paquete, o bloque.

Bloque de datos

La verdadera sustancia de cada paquete serie es la información que lleva. Ambiguamente llamamos a este bloque de datos un “bloque”, porque su tamaño no está específicamente establecido. En este estándar, la cantidad de datos en cada paquete se puede establecer en valores de 5 a 9 bits. Ciertamente, el tamaño de datos clásico es un byte de 8 bits, pero se usan otros tamaños. Un bloque de datos de 7 bits puede ser más eficiente que 8 si solo está transfiriendo caracteres ASCII de 7 bits.

Después de acordar la longitud para un caracter, ambos dispositivos serie también tienen que acordar el formato de sus datos. ¿Se envían los datos desde el bit más significativo (most significative bit = msb) al menos significativo, o viceversa? Si no se indica lo contrario, generalmente se puede asumir que los datos se transfieren enviando primero el bit menos significativo (least significative bit = lsb).

Bits de sincronización

Los bits de sincronización son dos o tres bits especiales transferidos con cada porción de datos. Son el bit de inicio y el(los) bit(s) de parada. Tal como indica su nombre, estos bits marcan el principio y el final de un paquete. Siempre hay un único bit de inicio, pero la cantidad de bits de parada se puede configurar en uno o dos (aunque normalmente se deja en uno).

El bit de inicio siempre se indica mediante una línea de datos inactiva que pasa de 1 a 0 (ALTO a BAJO). Los bits de parada volverán al estado inactivo manteniendo la línea en 1 (ALTO).

Bits de paridad

La paridad es una forma de comprobación de errores muy simple y de bajo nivel. Se presenta en dos variantes: impar o par. Para generar el bit de paridad, se suman todos los bits del byte de datos (5 a 9), y el resultado de la suma define si el bit es 1 o 0. Por ejemplo, suponiendo que la paridad se establece en par y se agrega a un byte de datos como 0b01011101, que tiene una cantidad impar de 1s (5), el bit de paridad quedaría en 1. Por el contrario, si el modo de paridad se configuró en impar, el bit de paridad sería 0.

La paridad es opcional, y no se usa mucho. Puede ser útil para transmitir a través de medios ruidosos, pero también ralentizará un poco la transferencia de datos y requiere que tanto el transmisor como el receptor implementen el manejo de errores (generalmente, si se detecta error, los datos recibidos con falla deben reenviarse).

Un ejemplo

9600 8N1 – 9600 baudios, 8 bits de datos, sin paridad y 1 bit de parada: es uno de los protocolos serie más utilizados. Entonces, ¿cómo se vería un paquete o dos de datos de 9600 8N1?

Un dispositivo que transmita los caracteres ASCII ‘O’ y ‘K’ tendría que crear dos paquetes de datos. El valor ASCII de O (en mayúsculas) es 79, que se divide en un valor binario de 8 bits de 01001111, mientras que el valor binario de K es 01001011. Todo lo que queda es agregar bits de sincronización.

No se establece específicamente, pero la norma más aceptada es que los datos se transfieren enviando primero el bit menos significativo. Observe cómo se envía cada uno de los dos bytes a medida que se lee de derecha (bit 0) a izquierda (bit 7).

Dado que estamos transfiriendo a 9600 bps, el tiempo empleado en mantener cada uno de esos bits alto o bajo es 1/9600 (bps) o 104 µs por bit.

Por cada byte de datos transmitidos, en realidad como mínimo se envían 10 bits: un bit de inicio, 8 bits de datos y un bit de parada. Entonces, a 9600 bps, en realidad estamos enviando 9600 bits por segundo o 960 (9600/10) bytes por segundo.

Ahora que sabemos cómo construir paquetes serie, podemos pasar a la sección de hardware. Allí veremos cómo esos 1s y 0s, y la velocidad de transmisión, se implementan a un nivel de señal.

Cableado y Hardware

Un bus serie consta de solo dos cables, uno para enviar datos y otro para recibir. Entonces, los dispositivos serie deben tener dos pines serie: el receptor: RX y el transmisor: TX.

Cableado en serie

Es importante tener en cuenta que esas etiquetas RX y TX son con respecto al dispositivo en sí. Entonces, el RX de un dispositivo debe ir al TX del otro y viceversa. Es extraño si uno está acostumbrado a conectar Vcc con Vcc, GND con GND, MOSI con MOSI, etc., pero —pensándolo— tiene sentido. El transmisor debe estar comunicándose con un receptor, no con otro transmisor.

Una interfaz en serie en la que ambos dispositivos pueden enviar y recibir datos es dúplex completo (full-duplex) o semidúplex. Full-duplex significa que ambos dispositivos pueden enviar y recibir simultáneamente. La comunicación semidúplex significa que los dispositivos serie deben turnarse para enviar y recibir.

Algunas conexiones serie pueden implementarse con una sola línea entre un dispositivo de transmisión y un dispositivo de recepción. Por ejemplo, los LCD que tienen conexión serie son solo receptores, y realmente no tienen ningún tipo de información para devolver al dispositivo de control. Esto es lo que se conoce como comunicación serie simplex. Todo lo que necesita es un solo cable desde la transmisión del dispositivo maestro a la línea RX del que recibe.

Implementación de hardware

Hasta ahora fue una cobertura de la comunicación serie asíncrona desde un lado conceptual. Sabemos qué cables necesitamos, pero, ¿cómo se implementa realmente la comunicación en serie a nivel de señal? En una variedad de formas, en realidad. Hay todo tipo de estándares para la comunicación en serie. Veamos algunas de las implementaciones de hardware más populares de serie: nivel lógico o TTL, y RS-232.

Cuando los microcontroladores y otros circuitos integrados de bajo nivel se comunican en serie, generalmente lo hacen a un nivel TTL (Transistor Transistor Logic = Lógica Transistor-Transistor). Las señales serie TTL están en el rango del voltaje que alimenta a un microcontrolador, generalmente de 0V a 3,3V, 0V o 5V. Una señal en el nivel VCC (3,3V, 5V, etc.) indica una línea inactiva, un bit de valor 1 o un bit de parada. Una señal de 0V (GND) representa un bit de inicio o un bit de datos de valor 0.

El protocolo RS-232, que se puede encontrar en algunas de las computadoras y periféricos más antiguos, es como una interfaz serie TTL puesta cabeza abajo. Las señales RS-232 generalmente oscilan entre -13V y 13V, aunque la especificación permite cualquier cosa desde +/- 3V a +/- 25V. En estas señales, un voltaje bajo (-5V, -13V, etc.) indica la línea inactiva, un bit de parada o un bit de datos de valor 1. Una señal RS-232 alta significa un bit de inicio o un bit de datos de valor 0. Eso es lo contrario del protocolo TTL.

Entre los dos estándares de señal en serie, el TTL es mucho más fácil de implementar en circuitos integrados. Sin embargo, los niveles de baja tensión son más susceptibles a sufrir pérdidas en las líneas de transmisión largas. El RS-232 o estándares más complejos —como RS-485— son más adecuados para transmisiones en serie de largo alcance.

Cuando conecte dos dispositivos serie juntos, es importante asegurarse de que coincidan los voltajes de su señal. No se puede conectar directamente un dispositivo serie TTL con una línea RS-232. Se deben adaptar esas señales.

Continuando, exploraremos la herramienta que usan los microcontroladores para convertir sus datos que se encuentran presentes en un bus paralelo desde y hacia una interfaz serial: se llama UART.

UARTs

La última pieza de este armado en serie es encontrar algo para crear los paquetes en serie y controlar las líneas de hardware físico. Esto se concreta con un módulo llamado UART (Universal Asynchronous Receiver/Transmiter = Receptor/Transmisor Asíncrono Universal).

Un receptor/transmisor asíncrono universal es un bloque de circuitos responsable de implementar la comunicación en serie. En esencia, este UART actúa como un intermediario entre las interfaces paralelas y seriales. En un extremo del UART hay un bus de ocho o más líneas de datos (más algunos pines de control), en el otro lado están los dos cables serie: RX y TX.

UART simplificado
UART
Los UART existen como circuitos integrados independientes, pero en la actualidad es más común que se encuentren dentro de los microcontroladores. Debemos consultar la hoja de datos de un microcontrolador para ver si tiene algún UART. Algunos no tienen, otros tienen uno, otros tienen varios. Por ejemplo, el Arduino UNO, basado en el «antiguo y fiel» ATmega328, tiene un solo UART, mientras que el Arduino Mega, construido sobre un ATmega2560, tiene cuatro UART.

Como lo indican las letras R y T en el acrónimo, los UART son responsables de enviar y recibir datos en serie. En el lado de transmisión, un UART debe crear el paquete de datos —agregando la sincronización y los bits de paridad— y enviar ese paquete por la línea TX con una sincronización precisa (de acuerdo con la velocidad de transmisión establecida). En el extremo de recepción, el UART tiene que muestrear la línea de RX a velocidades acordes con la velocidad de transmisión que se espera, seleccionar los bits de sincronización y entregar como resultado los datos.

UART interno

Los UART más avanzados pueden enviar los datos que reciben a un archivo de memoria de respaldo, llamado búfer, donde pueden permanecer hasta que el microcontrolador vaya a buscarlos. Los UART generalmente publicarán sus datos almacenados en un búfer con un sistema de “el primero que entra es el primero que sale” (First In First Out = FIFO). Los búfer pueden tener apenas unos pocos bits, o pueden ser de gran tamaño, como miles de bytes.

Diagrama de bloques de un UART con FIFO


UARTs de software

Si un microcontrolador no tiene un UART, o no tiene suficientes, se puede implementar la interfaz en serie en bits que son controlados directamente por el procesador. Este es el enfoque que tienen las bibliotecas de Arduino como SoftwareSerial. El uso de bits es intensivo en el procesador, y no suele ser tan preciso como un UART, pero funciona en caso de necesidad.

Errores comunes

Eso fue todo lo básico sobre la comunicación en serie. Podemos dejar señalados algunos errores comunes que un ingeniero, de cualquier nivel de experiencia, puede llegar a cometer:

RX a TX, / TX a RX

Parece bastante simple, pero es un error que algunos cometen un par de veces. Por mucho que desee que sus etiquetas coincidan, siempre asegúrese de cruzar las líneas RX y TX entre los dispositivos serie.

FTDI Basic programando un Pro Mini. Note que RX y TX están cruzados


Discrepancia en la velocidad de transmisión

Los valores de baudios son como claves en lenguajes de la comunicación en serie. Si dos dispositivos no están hablando a la misma velocidad, los datos pueden ser mal interpretados o completamente perdidos. Si todo lo que el dispositivo receptor ve en su línea de recepción está compuesta de caracteres extraños, llamados “basura” en el ambiente, verifique que coincidan las velocidades en baudios definidas en ambos extremos.

Datos transmitidos a 9600 bps, pero recibidos a 19200 bps. Desajuste de baudios = basura


Contención de transferencia en la línea

La comunicación en serie está diseñada para permitir que solo dos dispositivos se comuniquen a través de un bus en serie. Si más de un dispositivo está intentando transmitir en la misma línea serie, podría encontrarse con una contención de bus.

Por ejemplo, si está conectando un módulo GPS a su Arduino, puede conectar la línea de transmisión de ese módulo a la línea RX de Arduino. Pero ese pin Arduino RX ya está conectado al pin TX del convertidor de USB a serie (por ejemplo un chip FTDI) que se usa cada vez que se programa el Arduino, o se usa el Monitor Serie. Esto establece la situación potencial en la que tanto el módulo GPS como el chip FTDI intentan transmitir en la misma línea al mismo tiempo.

Ejemplo de contención de línea (o bus)

No es bueno que dos dispositivos intenten transmitir datos al mismo tiempo en la misma línea. En el mejor de los casos, ninguno de los dispositivos podrá enviar sus datos. En el peor de los casos, las líneas de transmisión de ambos dispositivos se volverán locas (aunque eso es raro y generalmente están protegidos contra esta situación).

Puede ser seguro conectar varios dispositivos receptores a un solo dispositivo de transmisión. Realmente no cabe dentro de las especificaciones, y probablemente esté mal visto por un ingeniero experimentado, pero funcionará. Por ejemplo, si conectamos un LCD serie a un Arduino, el método más sencillo puede ser conectar la línea RX del módulo LCD a la línea TX del Arduino. El TX de Arduino ya está conectado a la línea RX del programador USB, pero eso deja solo un dispositivo controlando la línea de transmisión.

Implementación segura pero dudosa de un transmisor y dos receptores

La distribución de una línea de transmisión de este tipo puede ser peligrosa desde la perspectiva del firmware, ya que no puede elegir qué dispositivo recibe cual transmisión. La pantalla LCD terminará recibiendo datos que no están destinados a ella, lo que podría ordenarle que pase a un estado desconocido.

Hay formas de implementarlo, usando un poco de hardware adicional, pero esto es tema para otro artículo.

Módulo transmisor de infrarrojo KY-005 (Kit de sensores Keyes 5)

Este módulo de Keyes contiene un led emisor de luz infrarroja y una resistencia limitadora de corriente.

El módulo transmisor de infrarrojo consiste de un led infrarrojo de 5mm y un resistor asociado. Funciona en conjunto con el receptor de infrarrojo KY-022.

Voltaje de Operación: 5V
Corriente Directa: 30 ~ 60 mA
Consumo de energía: 90mW
Temperatura de Operación: -25°C to 80°C
Dimensiones: 18,5mm x 15mm

La línea central del módulo es la alimentación, y se conecta a los +5V del Arduino. La línea marcada con el signo va conectada a GND del Arduino. La línea marcada con la letra S va conectada a la línea digital 2 del Arduino.

Código de ejemplo:

El siguiente programa de Arduino utiliza la biblioteca IRremote para enviar señales de infrarrojos en serie con el KY-005.

La conexión del pin de salida la determina la biblioteca: la entrada digital 3 en Arduino Uno. Depende de la placa que se esté utilizando, de modo que si utiliza otra se debe verificar la documentación de la biblioteca de IRremote. Será necesario un receptor de infrarrojos como el KY-022 para procesar la señal.

Los enlaces a las bibliotecas requeridas para el programa de ejemplo de Arduino con KY-005 se pueden encontrar en los enlaces más abajo.

Este programa envía un código de encendido/apagado de Sony TV cada vez que se envía un caracter al puerto serie, lo que permite que Arduino encienda o apague el televisor. (Tenga en cuenta que los códigos de Sony deben enviarse 3 veces de acuerdo con el diseño del protocolo).

Biblioteca IRremote: una biblioteca remota de infrarrojos multiprotocolo para Arduino

El código más reciente está en github.com/shirriff/Arduino-IRremote

La biblioteca remota IRremote permite enviar y recibir códigos remotos de IR en múltiples protocolos. Es compatible con NEC, Sony SIRC, Philips RC5, Philips RC6 y protocolos sin formato. Si se necesitan protocolos adicionales, son fáciles de agregar. Incluso la biblioteca puede utilizarse para grabar códigos desde su control remoto y retransmitirlos, como un control remoto universal mínimo.

Para usar la biblioteca, descargue desde github y siga las instrucciones de instalación en el archivo readme.

Cómo enviar:

Esta biblioteca remota de infrarrojos consta de dos partes: IRsend transmite paquetes remotos IR, mientras que IRrecv recibe y decodifica un mensaje IR. IRsend utiliza un LED infrarrojo conectado al pin digital 3. Para enviar un mensaje, llame al método de envío para el protocolo deseado con los datos a enviar y la cantidad de bits a enviar. Los ejemplos de la biblioteca proporcionan programas simples que muestran cómo enviar códigos. Uno de ellos es el que está listado más arriba.

Cómo recibir:

IRrecv utiliza un detector de infrarrojos conectado a cualquier pin de entrada digital.

El ejemplo IRrecvDemo en la biblioteca aporta un ejemplo simple de cómo recibir códigos:

La clase IRrecv realiza la decodificación y se inicializa con enableIRIn(). Se llama al método decode() para ver si se ha recibido un código; si es así, devuelve un valor distinto de cero y coloca los resultados en la estructura decode_results. Una vez que se ha descodificado un código, se debe llamar al método resume() para reanudar la recepción de códigos. Tenga en cuenta que decode() no bloquea; el croquis puede realizar otras operaciones mientras espera un código porque los códigos son recibidos por una rutina de interrupción.




Algunos antecedentes sobre los códigos IR

Un control remoto IR funciona encendiendo y apagando el LED en un patrón particular. Sin embargo, para evitar la interferencia de fuentes IR, como la luz solar o las luces, el LED no se enciende de manera constante, sino que se enciende y apaga a una frecuencia de modulación (generalmente 36, 38 o 40 KHz). El tiempo en que se envía una señal modulada se llama “marca”, y cuando el LED está apagado se llama “espacio”.

Cada tecla del control remoto tiene un código particular asociado (generalmente de 12 a 32 bits), y emite este código cuando se presiona la tecla. Si se mantiene presionada la tecla, el control remoto generalmente emite repetidamente el código de la tecla. Para un control remoto NEC, se envía un código especial de repetición cuando se mantiene presionada la tecla, en lugar de enviar el código repetidamente. Para los controles remotos Philips RC5 o RC6, se alterna un poco el código cada vez que se presiona una tecla; el receptor utiliza este bit de conmutación para determinar cuándo se presiona una tecla por segunda vez.

En el extremo receptor, el detector de IR demodula esta señal y emite una señal de nivel lógico que indica si está recibiendo una señal o no. El detector de IR funcionará mejor cuando su frecuencia coincida con la frecuencia del remitente, pero en la práctica no importa mucho.

Enlaces:

Biblioteca IRremote
Módulo de led emisor infrarrojo – KY-005: Dibujo de la pieza para el editor Fritzing

Artículos relacionados:

Módulo sensor de temperatura KY-001 (Kit de sensores Keyes 1)
Módulo detector de vibración KY-002 (Kit de sensores Keyes 2)
Módulo de Sensor Magnético por efecto Hall KY-003 (Kit de sensores Keyes 3)
Módulo de llave pulsadora – KY-004 (Kit de sensores Keyes 4)
Módulo sensor de temperatura KY-005 (Kit de sensores Keyes 5)
Módulo de emisor piezoeléctrico pasivo KY-006 (Kit de sensores Keyes 6)
Módulo codificador rotativo KY-040 [ó KY-007] – (Kit de sensores Keyes 040/007)


ESP8266 (WiFi): Hacer que parpadee un LED desde el IDE de Arduino

¿Qué es un ESP8266?

El ESP8266 es un chip con capacidad Wi-Fi con un stack TCP/IP completo y un microcontrolador, fabricado por Espressif, una empresa China. El primer chip se hizo conocido el mercado con el módulo ESP-01, desarrollado por la empresa AI-Thinker. Este pequeño módulo permite a otros microcontroladores conectarse a una red inalámbrica Wi-Fi y realizar conexiones simples con TCP/IP usando comandos al estilo Hayes (comandos AT).

Diversos modelos de módulos que utilizan el ESP8266

Características

•   CPU RISC de 32-bit: Tensilica Xtensa LX106 con un reloj de 80 MHz. El reloj de la CPU y la memoria flash puede duplicarse por overclocking en algunos dispositivos. La CPU puede funcionar a 160 MHz y la memoria flash puede trabajar entre 40 MHz y 80 MHz. Varía según la versión del chip.
•   RAM de programa de 64 KB, RAM de datos de 96 KB
•   Capacidad de memoria externa flash QSPI de 512 KB a 4 MB (puede manejar hasta 16 MB)
•   IEEE 802.11 b/g/n Wi-Fi
     o Tiene integrados: TR switch, balun, LNA, amplificador de potencia de RF y una red de adaptación de impedancias
     o Soporte de autenticación WEP y WPA/WPA2
•   16 pines GPIO (Entradas/Salidas de propósito general)
•   Interfaces SPI, I²C,
•   Interfaz I²S con DMA (comparte pines con GPIO)
•   Pines dedicados a UART, más una UART únicamente para transmisión que puede habilitarse a través del pin GPIO2
•   1 conversor ADC de 10-bit

El ESP8266 se puede programar desde el IDE de Arduino. Para eso hay que instalar lo que se llama un plugin, en el que está incluido todo lo necesario para compilar y subir programas que fueron escritos tal como si fuesen .INO de Arduino.

Debemos incorporar librerías y los programas de manejo de las placas con el chip ESP8266 a nuestro IDE. Para hacerlo, debemos indicarle la URL desde donde se obtienen.

Para hacerlo, debemos abrir el menú Archivo, y luego Preferencias.

Veremos este panel, en la parte inferior el recuadro de texto rotulado Gestor de URLs Adicionales de Tarjetas. Dentro de él, usando copiar y pegar, se debe introducir el texto indicado aquí:

http://arduino.esp8266.com/stable/package_esp8266com_index.json

(copie y pegue en el recuadro):

Luego pulse en el botón Ok.

Ahora debemos ir al menú Herramientas, luego Placa.

Y finalmente Gestor de Tarjetas, se abrirá una ventana como la que sigue, en la cual escribimos, en el recuadro superior de filtro/busqueda, “ESP8266” (antes de terminar de escribir ya aparecerá el Gestor de Tarjetas que buscamos, que indica que fue creado por “ESP8266 Community”. Allí pulsamos sobre Instalar:

Al abrir nuevamente Herramientas, y luego Placa, deslizamos la lista para ver lo que aparece al final de ella (abajo), y vemos que ya existen las opciones referidas a los ESP8266:

Ejemplo de programa:

Trabajaremos en este ejemplo dos modelos de placa que utilizan el chip ESP8266: ESP-01 y NodeMCU (ESP-12E).

El NodeMCU es una placa de desarrollo que contiene el módulo ESP-12E incorporado, más todos los elementos necesarios de apoyo para comunicarse con ella, entre éstos un conector USB, regulador de voltaje, botón de reinicio, un botón “flash” que se utiliza para programar el módulo, hileras de pines enchufables, etc.

Diseñaremos un circuito simple para hacer parpadear un LED en los ESP utilizando el IDE de Arduino para programarlos. La pregunta que uno se puede hacer es ¿por qué siempre lo primero que se enseña es a hacer que parpadee un LED? Y no es mala pregunta. La respuesta es que si podemos hacer parpadear un LED usando un pin de salida de un dispositivo, quiere decir que podemos encender o apagar cualquier dispositivo electrónico. Sólo es necesario, si conectamos algo a ese pin, que el consumo que necesita ese aparato para funcionar no supere lo que puede entregar el pin de salida de nuestro sistema. Pero esto no es condicionante: se soluciona —como en cualquier circuito electrónico— adaptando el voltaje y la corriente con componentes simples, como transistores, MOSFET o relés. Y entonces ya estamos encendiendo y apagando ya sea un LED, una lámpara o un horno eléctrico.

En los ESP, a las entradas y salidas se les llama GPIO, sigla que viene de las palabras en inglés General Purpuse Input/Output, en castellano Entrada/Salida de Propósito General.

Acerca de la asignación de GPIOs, la siguiente tabla es una referencia rápida sobre cómo asignar los GPIOs de ESP8266 en el código Arduino.

Aquí está la ubicación de cada pin la placa física:

ESP-01

NodeMCU / ESP-12E

Importante: en la siguiente sección, llamada «Cómo escribir el programa en el IDE de Arduino», cuando definimos: salida = 0 nos referimos al GPIO 0, y si definimos: salida = 2 nos referimos a GPIO 2. En el firmare interno del ESP se define así. No hay que preocuparse por esto, simplemente recordar que 0 se refiere a GPIO 0 y 2 se refiere a GPIO 2.

Cómo escribir el programa en el IDE de Arduino

El programa para hacer parpadear un LED es muy simple:

Cómo funciona el programa:

  • 1. Creamos una variable entera (int) llamada salida = 2 que hace referencia a GPIO 2
  • 2. En setup(), usamos la función pinMode(salida, OUTPUT) para configurar el GPIO 2 como una SALIDA (OUTPUT). Este código de inicialización se ejecuta una sola vez.
  • 3. A continuación, en loop() (función bucle), utilizamos dos funciones digitalWrite() y delay().
    Es una sección de código que se repite una y otra vez hasta que se quite la alimentación del ESP o se le cambie el programa.
  • 4. Enciende el LED durante 1 segundo (1000 milisegundos) usando digitalWrite(salida, HIGH) y espera de 1 segundo con delay(1000).
  • 5. Luego apaga el LED usando digitalWrite(salida, LOW) y espera de 1 segundo con delay(1000).
  • 6. El programa continúa indefinidamente, repitiendo los pasos 4. y 5.

Veremos que el LED parpadea, un segundo encendido, un segundo apagado.




Escribiendo el programa en el ESP8266

La opción más fácil es cuando se escribe código para el ESP8266 dentro del NodeMCU/ESP-12E, que tiene implementada la comunicación USB, y por lo tanto la manera de programar el chip. En cambio, al trabajar con el módulo ESP-01 (o algún otro modelo de ESP) es necesario tener un módulo conversor de USB a TX/RX, como un FTDI.

NodeMCU con ESP12E:

Subir código en este módulo es mucho más simple, ya que tiene incorporados los circuitos auxiliares necesarios para la programación. Sólo hay que enchufar el módulo a través del cable USB a la computadora sin que sea necesaria ninguna conexión adicional.

En el menú Herramientas del IDE de Arduino seleccione como Placa “NodeMCU 1.0 (ESP-12E Module)” y a continuación, también en el menú Herramientas, elegir el COM a que esté conectado el NodeMCU. No es necesaria más configuración. Se verá así (observar la línea debajo de todo en la ventana, que indica el dispositivo y el puerto COM):

El COM en su computadora no va a ser exactamente el COM9, aunque se puede dar la casualidad que lo sea. Será el COM virtual que el sistema operativo haya creado al conectar el módulo de ESP a su USB.

Después de comprobar estos detalles de configuración del IDE, utilice el botón “Subir” en el IDE y espere hasta que indique que ya ha completado la programación.

Para conectar el LED al NodeMCU utilice el siguiente circuito. El LED lleva un resistor de 220 Ohm en serie. La conexión va a GND y a la pata D4 del NodeMCU (GPIO 2).

NOTA: EL CIRCUITO A CONTINUACIÓN ES UN EJEMPLO EN EL QUE SE CONECTA ALGO A UN PIN EXTERNO. EL MODELO MÁS HABITUAL DE NODEMCU EN EL MERCADO YA TIENE UN LED CONECTADO EN EL GPIO 2 Y OTRO EN GPIO 16, INCLUIDOS EN LA PLACA. SI LO DESEA, ANTES DE ARMAR EL CIRCUITO PRUEBE CON LA PLACA SOLA. PRUEBE UNA VEZ USANDO salida = 2, Y OTRA USANDO salida = 16. FUNCIONARÁ EN AMBOS CASOS, CON DOS LEDS DISTINTOS SI SU MODELO NO TIENE ESTE LED INCORPORADO, CABLEE EL CIRCUITO DE ABAJO.

Luego de cargar el programa al ESP8266, si todo salió bien veremos parpadear el LED cada 1 segundo.

Parpadeo con GPIO 2

 

Parpadeo con GPIO 16

 

Prueba usando el módulo ESP-01

Para subir código a un ESP-01 hay que establecer una comunicación USB a través de un conversor de USB a niveles TTL (que maneje voltajes de 3,3V) a la conexión serie TX/RX del ESP8266, con un módulo como el que se ve en la figura. Hay muchos modelos, pero es recomendable buscar uno que tenga un chip FTDI y que en su placa facilite la conversión de voltajes de 5V a 3,3V (que es el voltaje con el que funciona el ESP8266).

Es importante remarcar que lo primero que debemos hacer, al comprarlo, y antes de conectarlos, es buscar el selector de voltajes de 5V a 3,3V. Debemos asegurarnos de que el módulo FTDI esté fijado en el modo de operación a 3,3V, como muestra la imagen de abajo.

El circuito de abajo indica las conexiones que debemos hacer para establecer la comunicación del ESP-01, a través del módulo FTDI, hacia el conector USB, para lograr la comunicación serie.

La conexiones son:

      • RX ► TX
      • TX ► RX
      • CH_PD ► 3,3V
      • GPIO 0 ► GND
      • VCC ► 3,3V
      • GND ► GND

Nota: en el circuito de la imagen de arriba, GPIO 0 está conectado a GND. Esto es porque queremos subir código. Al subir un programa por primera vez desde el IDE del Arduino se requiere que el ESP grabe en su flash un nuevo firmware —firmware es un software de bajo nivel, interno, que permite controlar circuitos eléctricos—. En uso normal (cuando no estamos grabando en la memoria flash un firmware nuevo) el pin GPIO 0 se conecta a VCC (3,3V).

En el caso de que usted tenga necesidad de instalar un driver en una PC con Windows porque no le reconoce el módulo en un puerto COM, sea este u otro con chip FTDI, el sitio oficial para conseguirlos es: http://www.ftdichip.com/Drivers/VCP.htm. Si compra uno nuevo, pregunte siempre al vendedor. Muchas veces tienen las soluciones en un enlace en su página web de ventas.

Normalmente, si usted está conectado online, el driver se instala automáticamente.

Preparando su IDE de Arduino

Una vez que conectamos el ESP8266 a través del módulo FTDI a su computadora, corra el IDE de Arduino. Abra el menú Herramientas y seleccione la Placa: “Generic ESP8266 Module”. Las configuraciones estándar deberían verse así:

El número de puerto COM que aparezca listado va a depender de cada computadora, e incluso puede cambiar alguna otra vez que conecte otro ESP, ya que ese número lo determina dinámicamente el sistema operativo.

En este momento ya se puede pulsar “Subir” en el IDE Arduino. Pasará un tiempo hasta que aparezca la indicación de que el programa ha sido subido.

El funcionamiento final: Circuito para el ESP-01 y el LED

Luego de haber subido el código al módulo, desconecte de la computadora y recablee siguiendo el diagrama a continuación:

Al conectar los 3,3V de alimentación al ESP-01, todo estará listo. Si las cosas salieron bien, el LED debería parpadear encendiéndose y apagándose cada 1 segundo.


Para cualquier consulta, comuníquese conmigo en el grupo de facebook https://www.facebook.com/groups/GrupoRobotsDidacticos/

Arduino: Comunicación inalámbrica con NRF24L01

La función de este artículo es ofrecer una explicación sobre cómo establecer una comunicación inalámbrica entre dos placas Arduino usando el módulo transceptor NRF24L01.

La primera comunicación inalámbrica que explicaré será básica: enviar un simple mensaje de texto, tipo «Hola Mundo», de un Arduino a otro.

A continuación podremos extender este ejemplo de comunicación al envío de comandos de texto —usando el mismo circuito y estructura de programa— para controlar un sistema cualquiera ubicado en el extremo receptor.

Más adelante ofreceré un artículo con un ejemplo de comunicación bidireccional entre placas Arduino. Un Arduino tiene conectado un potenciómetro con el que se controla un servo en el segundo Arduino. Y en el otro sentido, unos interruptores en el segundo Arduino servirán para controlar LEDs en el primero.

Módulo transceptor NRF24L01

En la imagen se observa el módulo transceptor NRF24L01. Utiliza la banda de 2,4 GHz y puede operar con velocidades de transmisión de 250 kbps hasta 2 Mbps. Si se usa en espacios abiertos y, con menor velocidad de transmisión, su alcance puede llegar hasta los 100 metros. Para mayores distancias, hasta 1000 metros, existen módulos provistos con una antena externa en lugar de una antena trazada sobre la misma placa, como se observa en la imagen.

El módulo puede usar 125 canales diferentes, lo que da la posibilidad de tener una red de 125 módems que funcionen con independencia uno de otro en un solo lugar. Cada canal puede tener hasta 6 direcciones, es decir, cada unidad puede comunicarse con hasta otras 6 unidades al mismo tiempo.

El consumo de este módulo es de alrededor de 12 mA durante la transmisión, un valor menor al de un LED encendido. El voltaje de operación del módulo es de 1,9 a 3,6V, pero lo bueno es que los demás pines toleran la lógica de 5V, por lo que podemos conectarlo sin problemas a un Arduino sin necesidad de un convertidor de niveles lógicos.

Tres de estos pines son para la comunicación SPI: MOSI, MISO y SCK, que deben conectarse a los pines de la interfaz SPI del Arduino. Se debe tener en cuenta que diferentes placas Arduino pueden tener los pines del interfaz SPI en diferentes posiciones. Los pines CSN y CE se pueden conectar a cualquier pin digital de la placa Arduino, y su función es configurar el módulo en modo de espera o activo, así como para alternar entre modo de transmisión o de comando. El último pin, IRQ, es un pin de interrupción que no es necesario utilizar.

Una vez conectados los módulos NRF24L01 a las placas Arduino, llegará el momento de escribir los programas para el transmisor, y para el receptor.

Conexionado para utilizar Arduinos Uno R3 en ambos lados de la comunicación:

Código para los Arduino

Primero debemos descargar e instalar la librería RF24.

Aquí están los dos códigos para la comunicación inalámbrica y abajo, en los archivos, hay amplias explicaciones. He puesto la mayor parte de las explicaciones dentro del programa, como comentarios.

Código del Transmisor

Código del receptor

Una vez cargados ambos programas, podemos abrir el monitor serie en el Arduino receptor y observaremos la aparición del mensaje «Hola Mundo» cada 1 segundo.






CONTROL INALÁMBRICO A DISTANCIA

Esta prueba consiste en tener un Arduino (con el programa TRANSMISOR listado más abajo) conectado a la PC a través de USB / Conexión Serie, con el Monitor Serie del IDE de Arduino abierto (Herramientas > Monitor Serie) y asignado en el COM que corresponde, y transmitiendo en forma inalámbrica los caracteres que son tipeados dentro de este Monitor.

Nota: Un defecto que tiene el Monitor Serie del IDE del Arduino es que para que se transmita un caracter, o una serie de caracteres, hay que tipearlo y pulsar ENTER (ENTRAR). Eso es incómodo para controlar un equipo remoto pulsando teclas. Por eso recomiendo utilizar un programa simple y gratuito de terminal. Quizás usted ya tenga uno. En mi caso utilizo el programa Parallax Serial Terminal (PST.EXE), que se puede bajar de aquí (Página de manual de uso).

El otro Arduino lleva grabado el programa RECEPTOR, y en ese Arduino se ha agregado un pequeño servo al diagrama estándar, como muestra la figura más abajo.

El funcionamiento será básico: pulsando los números de 1 a 0 ubicados en la hilera superior del teclado, o si lo desea y lo tiene, en el teclado numérico a la derecha. Para cada uno de estos números el servo se ubicará en 10 posiciones diferentes, separadas 20º. Desde 0 a 180º, que es el rango que tiene todo servo, y más aún estos pequeños. Los servos mayores se pueden mover 270º. La selección de acciones que corresponden a cada comando se realiza por medio de comparaciones IF en el primer programa ejemplo de RECEPTOR, y por medio de una estructura SWICH-CASE en el segundo programa ejemplo. El primero es así porque puede resultar más comprensible para los recién iniciados, y el segundo ejemplo es más simple, elegante y profesional. Puse enlaces en los nombres de las estructuras de programa que apuntan a la sección de REFERENCIA del sitio oficial de Arduino.

La elección de cuál programa RECEPTOR desea usar queda a su gusto. En realidad, es conveniente probar ambos. En lo funcional se comportarán igual.

DIAGRAMA

TRANSMISOR

RECEPTOR – Basado en elección de comandos por IF

RECEPTOR – Basado en elección de comandos por SWITCH-CASE


AQUÍ LOS ARDUINOS ARMADOS

En breve: Comunicación bidireccional simultánea con NRF24L01

Descripción y funcionamiento del Bus I2C

Introducción

DEFINICIÓN DE I2C (I2C): Abreviatura de Inter-IC (inter integrated circuits), un tipo de bus diseñado por Philips Semiconductors a principios de los 80s, que se utiliza para conectar circuitos integrados (ICs). El I2C es un bus con múltiples maestros, lo que significa que se pueden conectar varios chips al mismo bus y que todos ellos pueden actuar como maestro, sólo con iniciar la transferencia de datos. Este bus se utiliza dentro de una misma placa de un dispositivo.

El bus I2C, un estándar que facilita la comunicación entre microcontroladores, memorias y otros dispositivos con cierto nivel de «inteligencia», sólo requiere de dos líneas de señal y un común o masa. Fue diseñado a este efecto por Philips y permite el intercambio de información entre muchos dispositivos a una velocidad aceptable, de unos 100 Kbits por segundo, aunque hay casos especiales en los que el reloj llega hasta los 3,4 MHz.

La metodología de comunicación de datos del bus I2C es en serie y sincrónica. Una de las señales del bus marca el tiempo (pulsos de reloj) y la otra se utiliza para intercambiar datos.

Descripción de las señales

  • SCL (System Clock) es la línea de los pulsos de reloj que sincronizan el sistema.
  • SDA (System Data) es la línea por la que se mueven los datos entre los dispositivos.
  • GND (Masa) común de la interconexión entre todos los dispositivos «enganchados» al bus.

Las líneas SDA y SCL son del tipo drenaje abierto, es decir, un estado similar al de colector abierto, pero asociadas a un transistor de efecto de campo (o FET). Se deben polarizar en estado alto (conectando a la alimentación por medio de resistores «pull-up») lo que define una estructura de bus que permite conectar en paralelo múltiples entradas y salidas.

El diagrama es suficientemente autoexplicativo. Las dos líneas del bus están en un nivel lógico alto cuando están inactivas. En principio, el número de dispositivos que se puede conectar al bus no tiene límites, aunque hay que observar que la capacidad máxima sumada de todos los dispositivos no supere los 400 pF. El valor de los resistores de polarización no es muy crítico, y puede ir desde 1K8 (1.800 ohms) a 47K (47.000 ohms). Un valor menor de resistencia incrementa el consumo de los integrados pero disminuye la sensibilidad al ruido y mejora el tiempo de los flancos de subida y bajada de las señales. Los valores más comunes en uso son entre 1K8 y 10K.

Protocolo de comunicación del bus I2C

Habiendo varios dispositivos conectados sobre el bus, es lógico que para establecer una comunicación a través de él se deba respetar un protocolo. Digamos, en primer lugar, lo más importante: existen dispositivos maestros y dispositivos esclavos. Sólo los dispositivos maestros pueden iniciar una comunicación.

La condición inicial, de bus libre, es cuando ambas señales están en estado lógico alto. En este estado cualquier dispositivo maestro puede ocuparlo, estableciendo la condición de inicio (start). Esta condición se presenta cuando un dispositivo maestro pone en estado bajo la línea de datos (SDA), pero dejando en alto la línea de reloj (SCL).

El primer byte que se transmite luego de la condición de inicio contiene siete bits que componen la dirección del dispositivo que se desea seleccionar, y un octavo bit que corresponde a la operación que se quiere realizar con él (lectura o escritura).

Si el dispositivo cuya dirección corresponde a la que se indica en los siete bits (A0-A6) está presente en el bus, éste contesta con un bit en bajo, ubicado inmediatamente luego del octavo bit que ha enviado el dispositivo maestro. Este bit de reconocimiento (ACK) en bajo le indica al dispositivo maestro que el esclavo reconoce la solicitud y está en condiciones de comunicarse. Aquí la comunicación se establece en firme y comienza el intercambio de información entre los dispositivos.

Si el bit de lectura/escritura (R/W) fue puesto en esta comunicación a nivel lógico bajo (escritura), el dispositivo maestro envía datos al dispositivo esclavo. Esto se mantiene mientras continúe recibiendo señales de reconocimiento, y el contacto concluye cuando se hayan transmitido todos los datos.

En el caso contrario, cuando el bit de lectura/escritura estaba a nivel lógico alto (lectura), el dispositivo maestro genera pulsos de reloj para que el dispositivo esclavo pueda enviar los datos. Luego de cada byte recibido el dispositivo maestro (quien está recibiendo los datos) genera un pulso de reconocimiento.

El dispositivo maestro puede dejar libre el bus generando una condición de parada (o detención; stop en inglés).

Si se desea seguir transmitiendo, el dispositivo maestro puede generar otra condición de inicio en lugar de una condición de parada. Esta nueva condición de inicio se denomina «inicio reiterado» y se puede emplear para direccionar un dispositivo esclavo diferente o para alterar el estado del bit de lectura/escritura.

Definición de términos:

  • Maestro (Master): Dispositivo que determina los tiempos y la dirección del tráfico en el bus. Es el único que aplica los pulsos de reloj en la línea SCL. Cuando se conectan varios dispositivos maestros a un mismo bus la configuración obtenida se denomina «multi-maestro».
  • Esclavo (Slave): Todo dispositivo conectado al bus que no tiene la capacidad de generar pulsos de reloj. Los dispositivos esclavos reciben señales de comando y de reloj generados desde el maestro.
  • Bus libre (Bus Free): Estado en el que ambas líneas (SDA y SCL) están inactivas, presentando un estado lógico alto. Es el único momento en que un dispositivo maestro puede comenzar a hacer uso del bus.
  • Comienzo (Start): Se produce cuando un dispositivo maestro ocupa el bus, generando la condición. La línea de datos (SDA) toma un estado bajo mientras que la línea de reloj (SCL) permanece alta.
  • Parada (Stop): Un dispositivo maestro puede generar esta condición, dejando libre el bus. La línea de datos y la de reloj toman un estado lógico alto.
  • Dato válido (Valid Data): Situación presente cuando un dato presente en la línea SDA es estable al tiempo que la línea SCL está a nivel lógico alto.
  • Formato de Datos (Data Format): La transmisión de un dato a través de este bus consiste de 8 bits de dato (1 byte). A cada byte transmitido al bus le sigue un noveno pulso de reloj durante el cual el dispositivo receptor del byte debe generar un pulso de reconocimiento.
  • Reconocimiento (Acknowledge): El pulso de reconocimiento, conocido como ACK (del inglés Acknowledge), se logra colocando la línea de datos a un nivel lógico bajo durante el transcurso del noveno pulso de reloj.
  • Dirección (Address): Todo dispositivo diseñado para funcionar en este bus posee su propia y única dirección de acceso, preestablecida por el fabricante. Hay dispositivos que permiten definir externamente parte de la dirección de acceso, lo que habilita que se pueda conectar en un mismo bus un conjunto de dispositivos del mismo tipo, sin problemas de identificación. La dirección 00 es la denominada «de acceso general»; a ésta responden todos los dispositivos conectados al bus.
  • Lectura/Escritura (Bit R/W): Cada dispositivo tiene una dirección de 7 bits. El octavo bit (el menos significativo) que se envía durante la operación de direccionamiento, completando el byte, indica el tipo de operación a realizar. Si este bit es alto el dispositivo maestro lee información proveniente de un dispositivo esclavo. Si este bit es bajo, el dispositivo maestro escribe información en un dispositivo esclavo.

La comunicación en más detalle

Cuando el dispositivo maestro quiere comunicarse con un esclavo, produce una secuencia de inicio en el bus. La secuencia de inicio es una de las dos secuencias especiales que se han definido en el bus I2C; la otra es la secuencia de parada. Las secuencias de inicio y la de parada son especiales porque son los dos únicos casos en que se permite que la línea de datos (SDA) cambie cuando la línea de reloj (SCL) está alta. Cuando se están transmitiendo datos, la línea SDA debe permanecer estable, y jamás cambiar, mientras la línea SCL está alta. Las secuencias de inicio y de parada señalan el comienzo y el final de una transacción con los dispositivos esclavos.

Los datos se transfieren en secuencias de 8 bits. Estos bits se colocan en la línea SDA comenzando por el bit de más peso (o más significativo). Una vez puesto un bit en SDA, se lleva la línea SCL a alto. Debemos recordar que el chip no puede llevar la línea a un estado alto, en realidad, lo que hace es «soltarla», y el que la pone en nivel lógico alto es el resistor de polarización. Por cada 8 bits que se transfieren, el dispositivo que recibe el dato envía de regreso un bit de reconocimiento, de modo que en realidad por cada byte de dato se producen 9 pulsos sobre la línea SCL (es decir, 9 pulsos de reloj por cada 8 bits de dato). Si el dispositivo que recibe envía un bit de reconocimiento bajo, indica que ha recibido el dato y que está listo para aceptar otro byte. Si retorna un alto, lo que indica es que no puede recibir más datos y el dispositivo maestro debería terminar la transferencia enviando una secuencia de parada.

Direccionamiento de dispositivos en el bus I2C

Lo más común en los dispositivos para el bus I2C es que utilicen direcciones de 7 bits, aunque existen dispositivos de 10 bits. Este último caso es raro.

Una dirección de 7 bits implica que se pueden poner hasta 128 dispositivos sobre un bus I2C, ya que un número de 7 bits puede ir desde 0 a 127. Cuando se envían las direcciones de 7 bit, de cualquier modo la transmisión es de 8 bits. El bit extra se utiliza para informarle al dispositivo esclavo si el dispositivo maestro va a escribir o va a leer datos desde él. Si el bit de lectura/escritura (R/W) es cero, el dispositivo maestro está escribiendo en el esclavo. Si el bit es 1 el maestro está leyendo desde el esclavo. La dirección de 7 bit se coloca en los 7 bist más significativos del byte y el bit de lectura/escritura es el bit menos significativo.

El hecho de colocar la dirección de 7 bits en los 7 bits más significativos del byte produce confusiones entre quienes comienzan a trabajar con este bus. Si, por ejemplo, se desea escribir en la dirección 21 (hexadecimal), en realidad se debe enviar un 42, que es un 21 desplazado un bit hacia arriba. También se pueden tomar las direcciones del bus I2C como direcciones de 8 bit, en las que las pares son de sólo escritura y las impares son de sólo lectura. Para dar un ejemplo, el integrado de brújula magnética CMPS03 es fijado en fábrica en la dirección 0xC0 ($C0). La dirección 0xC0 se utiliza para escribir en él y la dirección 0xC1 es para leer de él.

Protocolo de programación para el bus I2C

Lo primero que ocurre en un bus I2C es que el dispositivo maestro envía una secuencia de inicio. Esto alerta a los dispositivos esclavos, poniéndolos a la espera de una transacción. Éstos quedan atentos para ver si se trata de una solicitud para ellos. A continuación el dispositivo maestro envía la dirección de dispositivo. El dispositivo esclavo que posee esa dirección continuará con la transacción, y los otros ignorarán el resto de los intercambios, esperando la próxima secuencia de inicio.

Habiendo direccionado ya el dispositivo esclavo, lo que debe hacer ahora el maestro es enviar la ubicación interna o número de registro desde el que desea leer o al que va a escribir. La cantidad depende, obviamente, de qué dispositivo es y de cuántos registros internos posee. Algunos dispositivos muy simples no tienen ninguno, pero la mayoría sí los poseen.

Siguiendo con el ejemplo del CMPS03, éste posee 16 ubicaciones internas, numeradas desde el 0 al 15. Otro dispositivo, el medidor ultrasónico de distancia SRF08, tiene 36 registros.

Una vez que el maestro ha enviado la dirección del dispositivo en el bus I2C y la dirección del registro interno del dispositivo, puede enviar ahora el byte o bytes de datos. El dispositivo maestro puede seguir enviando bytes al esclavo, que normalmente serán puestos en registros con direcciones sucesivas, ya que el esclavo incrementa automáticamente la dirección del registro interno después de recibir cada byte. Cuando el maestro ha terminado de escribir datos en el esclavo, envía una secuencia de parada que concluye la transacción.

Escritura en un dispositivo esclavo:

  • 1. Enviar una secuencia de inicio
  • 2. Enviar la dirección de dispositivo con el bit de lectura/escritura en bajo
  • 3. Enviar el número de registro interno en el que se desea escribir
  • 4. Enviar el byte de dato
  • 5. [Opcionalmente, enviar más bytes de dato]
  • 6. Enviar la secuencia de parada

Como ejemplo, veamos un SRF08, que tiene una dirección de bus fijada en fábrica de 0xE0. Para comenzar una medición de distancia con el SRF08 se debe escribir 0x51 en el registro de comando, ubicado en la dirección interna 0x00. La secuencia es la que sigue:

  • 1. Enviar una secuencia de inicio
  • 2. Enviar 0xE0 (La dirección de dispositivo del SRF08 con el bit de lectura/escritura en bajo)
  • 3. Enviar 0x00 (dirección interna del registro de comando)
  • 4. Enviar 0x51 (el comando para comenzar la medición del SRF08)
  • 5. Enviar la secuencia de parada

Lectura desde un dispositivo esclavo:

Esta operación es algo más complicada, pero no demasiado. Antes de leer datos desde el dispositivo esclavo, primero se le debe informar desde cuál de sus direcciones internas se va a leer. De manera que una lectura desde un dispositivo esclavo en realidad comienza con una operación de escritura en él. Es igual a cuando se desea escribir en él: Se envía la secuencia de inicio, la dirección de dispositivo con el bit de lectura/escritura en bajo y el registro interno desde el que se desea leer. Ahora se envía otra secuencia de inicio nuevamente con la dirección de dispositivo, pero esta vez con el bit de lectura/escritura en alto. Luego se leen todos los bytes necesarios y se termina la transacción con una secuencia de parada.

Volviendo al ejemplo del módulo de brújula CMPS03, veamos cómo se lee el registro de ángulo:

  • 1. Enviar una secuencia de inicio
  • 2. Enviar 0xC0 (La dirección de dispositivo del CMPS03 con el bit de lectura/escritura en bajo)
  • 3. Enviar 0x01 (dirección interna del registro de ángulo en valor 0-255)
  • 4. Enviar una secuencia de inicio (inicio reiterado)
  • 5. Enviar 0xC1 (La dirección de dispositivo del CMPS03 con el bit de lectura/escritura en alto)
  • 6. Leer un byte de dato desde el CMPS03
  • 7. Enviar la secuencia de parada

La secuencia se verá así:


Un caso un poco más complicado

Esto es todo cuando se trata de comunicaciones simples, pero debemos considerar una posible complicación: Cuando el dispositivo maestro está leyendo desde el esclavo, quien pone los datos en la línea SDA del bus es el dispositivo esclavo, y el maestro es el que controla el pulso de reloj. ¿Qué pasa si el esclavo no está listo para enviar un dato? Con dispositivos como una EEPROMs esto no sería problema, pero si el dispositivo esclavo es un microprocesador, que tiene otras tareas que realizar, pueden surgir inconvenientes.

Para atender la transacción, el microprocesador debe pasar a una rutina de interrupción, guardar sus registros de trabajo, determinar qué dirección desea leer el dispositivo maestro, obtener el dato y ponerlo en su registro de transmisión. Esto puede llevar varios microsegundos, lo que implica que el dispositivo maestro podría estar enviando pulsos de reloj ciegamente por la línea SCL sin que el dispositivo esclavo pueda responderle. El protocolo I2C ofrece una solución para esto: el esclavo puede mantener la línea SCL en bajo. A esto se le llama estiramiento del reloj. Cuando el esclavo recibe el comando de lectura lo primero que hace es poner la línea de reloj en bajo. Entonces sí, obtiene el dato solicitado, lo pone en el registro de transmisión, y recién entonces libera la línea de reloj, que pasará de inmediato a alto debido al nivel que aporta el resistor de polarización.

Desde el punto de vista del dispositivo maestro, éste tratará de enviar el primer pulso de reloj para la lectura de datos liberando la línea SCL para que pase a alto, pero antes de continuar comprobará que ésta realmente haya ido al nivel lógico 1. Si la línea SCL permanece en bajo, el dispositivo maestro interpreta que el esclavo la mantiene así y espera a que SCL vaya a alto antes de continuar. Por suerte, la mayoría de los puertos I2C de los microprocesadores manejan esto de manera automática.

Sin embargo, a veces el manejo de I2C en el dispositivo maestro no está implementado por circuito, sino que es un juego de subrutinas que maneja dos líneas de un puerto. Algunas implementaciones ignoran este estiramiento del reloj. Estas soluciones trabajarán bien con dispositivos tales como las EEPROM, pero no podrán intercambiar datos correctamente con microprocesadores esclavos que utilizan el estiramiento del pulso de reloj. Como resultado, se obtendrán datos erróneos.

Especificaciones de Philips sobre el bus I2C (PDF)