Para comunicar dispositivos con el ESP8266 podemos usar diversos protocolos serie. En este artículo veremos el protocolo serie por excelencia TTL y dos más elaborados: I2C y SPI.

En todos estos casos se trata de comunicaciones entre dispositivos con cableado muy corto.

Comparativa I2C, SPI y TTL

El ESP8266 soporta el protocolo SPI por hardware, pero no soporta el I2C, por lo que lo tiene que emular por software. Para el I2C, al ser emulado por soft, es posible cambiar los pines, siempre que la librería que dependa de Wire.h haya sido programada permitiendo esto.

La ventaja de I2C es que sólo necesito 2 pines y que, además, podemos cambiarlos, permitiendo mucha más flexibilidad. La desventaja es que es algo más lento que SPI, ya que es emulado por software en el ESP.

Por su parte I2C y SPI son protocolos de comunicación en BUS, es decir, podemos conectar varios dispositivos a la misma linea de datos, mientras que la comunicación TTL, al ser más básica, sólo soporta dos dispositivos en ambos extremos de la linea.

TTL (transistor-transistor logic)

TTL es el protocolo más simple, pero también el más limitado y el que más trabajo requerirá a la hora de establecer un protocolo. A diferencia de SPI y de I2C es asíncrono, es decir, no tiene un reloj que paute las comunicaciones. Tampoco permite más de 2 dispositivos.

TTL funciona a través del puerto UART, pines RX y TX:

SPI (Serial Peripheral Interface)

La ventaja de SPI es la rapidez, mucho más importante en dispositivos con gran cantidad de intercambio de datos, como en LCDs de cierto tamaño. Por eso pequeños dispositivos suelen ser I2C, mientras que los mayores presentan comunicación SPI.

La desventaja de SPI es que utiliza 3 cables. Y por cada dispositivo que añadamos, otro cable más, el CS (Chip Select).

Cableado: SPI pinout

Los cables necesarios para una comunicación SPI son:

  • CLK (CLocK), señal de reloj para sincronizar la comunicación. No se negocia ni se establece velocidad alguna, es el reloj el que marca los tiempos.
  • MOSI (Master Out – Slave In), envío de datos del maestro (ESP8266) al esclavo. Dependiendo del dispositivo, este cable podría no ser necesario, ejemplo: termómetro.
  • MISO (Master In – Slave Out), envío de datos del esclavo al maestro (ESP8266). Dependiendo del dispositivo, este cable podría no ser necesario, ejemplo: pantalla.
  • CS (Chip Select) o SS (Slave Select), por aquí viaja la señal enviada por el maestro que activa al esclavo para enviar/recibir y utilizar el canal de manera exclusiva, desactivando al resto de miembros del bus.

Pines SPI en un ESP8266

Pines SPI en Nodemcu. Fuente.

En la imagen vemos los pines SPI de un ESP8266. Los de la izquierda están reservados. Los de la derecha son los Hardware SPI y son los que podemos utilizar. En la web de la imagen hay un magnífico ejemplo sobre cómo comunicar un Arduino con un ESP8266 por SPI.

Lineas MOSI, MISO y SCK

Un esquema básico de la comunicación con las lineas SCK, MISO y MOSI quedaría así. Las últimas dedicadas en exclusiva a enviar o recibir datos, la primera en pautar la velocidad del envío. De esta manera SPI no necesita declarar velocidad (bps) y además es full-dúplex, lo que lo hace potente y sencillo.

Comunicación SPI de dos dispositivos. Fuente.

Aunque se pueden fijar por software y utilizar cualquier pin, lo lógico es usar los que ya están destinados al efecto por hardware. Las librerías normalmente dan por sentado que se usarán estos pines.

Como apunte adicional, la velocidad se puede fijar a través de la librería SPI.h en un divisor de los Megahercios del reloj interno del ESP8266.

Linea CS

El cable CS (Chip Select), también llamado SS (Slave Select) se necesita para cada esclavo, multiplicando el número de cables necesarios para este protocolo. Se mantiene en HIGH cuando el esclavo no puede usar las lineas MISO y MOSI para comunicar. Por el contrario se activa el esclavo al pasarla a LOW, permitiendo al esclavo usar las lineas de comunicación para él solo.

El papel de la linea CS. Fuente.

Obviamente el primer dispositivo SPI, el que más velocidad precise, usará el pin destinado al efecto por hardware. El resto deberán fijar por soft dicho pin.

Linea RST

Sirve para resetear el dispositivo y el comportamiento varía de uno a otro. No forma parte del protocolo y normalmente con conectarlo al pin RST del ESP8266 es más que suficiente.

Recordemos que el pin RST del ESP8266 está en estado HIGH en modo normal. Si lo pasamos brevemente a LOW se resetea. Si lo dejamos en LOW permanentemente el ESP8266 estará en modo programación para volcar nuestro código.

Con esto quiero decir que el pin RST del dispositivo RST normalmente también se podrá conectar a 3.3V.

Este pin se fija por software.

Linea DC

Adicionalmente a las anteriores líneas MOSI, MISO y SCK (comunes a todo el bus SPI) y a la linea CS (por cada dispositivo SPI) suele existir otra linea, etiquetada normalmente como DC, que tampoco forma parte del protocolo SPI pero que algunos dispositivos (p.e. displays) precisan para diferenciar órdenes de datos.

Esta linea, al no formar parte del protocolo, también se puede fijar por software.

De existir DC, el número de pines necesarios para mantener un bus SPI sería de:

3 + 2 * n

Siendo «n» el número de dispositivos SPI conectados al bus.

El bus SPI

El gran problema de SPI es que debe disponer de una linea CS para cada esclavo, lo cual no es un problema si sólo hay un esclavo. Cuando hay más, y más con los pequeños microcontroladores IoT actuales, es un problema. Este sería el esquema del bus:

El bus SPI. Fuente.

I2C (Inter-Integrated Circuit)

I2C es un protocolo muy sencillo que sólo utiliza dos cables. Sin embargo ESP8266 no lo soporta por hardware, debiendo emularse por soft.

Cableado: I2C pinout

Los cables necesarios para una comunicación I2C son (se pueden configurar por soft en el ESP8266):

  • SDA (Serial DAta). Linea para la transmisión de datos.
  • SCL (Serial CLock). Señal de reloj para sincronizar la comunicación.

A diferencia de SPI, I2C no contiene un linea CS que active al esclavo para monopolizar el canal de comunicaciones (SDA), por lo que esta carencia debe ser solventada por el propio protocolo. De hecho I2C identifica a cada esclavo con una dirección exclusiva, usada para comunicarle que monopolizará el canal de datos iniciando una conversación.

Lineas SDA y SCL

Lineas SDA y SCL del protocolo. Wikipedia.

Según la documentación tanto SDA como SCL precisan estar en estado HIGH mediante resistencias pull-up, aunque yo raramente las he montado.

Un esquema de comunicación por I2C quedaría así:

Comunicación I2C. Fuente.

Enlaces y referencias

Serial Peripheral Interface (SPI).

Artículo sobre la comunicación SPI en Arduino.

Artículo comunicación entre un Arduino y un ESP8266 por SPI.

El Bus SPI en Arduino.