Protocolos de Comunicación

Protocolos#

A continuación veremos cómo funcionan ciertos protocolos de comunicación serial. Estos se utilizan para comunicar dispositivos directamente, mediante un bus de datos. El bus de datos suele tomar la forma de cables conectando directamente a los dispositivos, y cumlpen ciertas condiciones para lograr establecer la comunicación.

UART#

Uno de los protocolos de comunicación de bajo nivel más utilizados y antiguos es el Universal Asynchronous Receiver - Transmitter (UART). Es un tipo de comunicación serial y bidireccional (full-duplex) entre 2 dispositivos, utilizando únicamente 2 cables: Transmitter (Tx) y Receiver (Rx). Notar que el Tx de un dispositivo es el Rx del otro, y viceversa.

La frecuencia de transmisión, llamada Baud rate y medida en bits-per-second (bps), debe acordarse previamente entre los dispositivos. En teoría no hay restricciones (aparte de físicas) en la frecuencia que pueden tomar, pero en la práctica hay tan solo unas pocas frecuencias que se utilizan: 1200, 2400, 4800, 9600, 19200, 38400, 57600, y 115200 bps. Dentro de estas, 9600 bps es la más común.

Los datos se envían en frames de entre 5 y 9 bits. Cada frame lleva adicionalmente bits de inicio y término, y opcionalmente un bit de paridad. El flujo completo es el siguiente:

1. Bit de inicio (start bit): Indica el inicio de una transmisión.
2. Bits de datos (data bits): Entre 5 y 9 bits con los datos transmitidos.
3. Bit de paridad (parity bit, opcional): Indica la paridad de los bits de datos. Se utiliza para detectar cambios en la transmisión.
4. Bit de término (stop bit): Indica el fin de una transmisión.

Se envía tantos frames como sea necesario para transmitir toda la información. Cada frame enviado puede representar un caracter, un número, o incluso datos binarios. La siguiente imagen, obtenida de Wikipedia, explica bastante bien el proceso. Notar que el BCLK es la frecuencia de transmisión acordada previamente entre los dispositivos.

I2C#

Inter-Integrated Circuit (I2C) también utiliza 2 cables, pero este protocolo es solo half-duplex. Es decir que los dispositivos deben tomar turnos para transmitir. Adicionalmente, se permiten más de dos dispositivos conectados, con uno funcionando como transmisor y el resto como receptores.

Para la comunicación, la información es enviada a través de la línea de datos SDA, mientras que el reloj que coordina a los dispositivos se transmite en la línea SCL. Luego, y a diferencia de UART, no se necesita información adicional para establecer la comunicación.

Dado que I2C utiliza solo un canal para la comunicación entre múltiples dispositivos, el protocolo es un poco más complejo que UART. Requiere de secuencias de sincronización para determinar quién puede transmitir en cada momento, bytes de ACK y NACK, para indicar si se recibió correctamente cada parte del mensaje, direcciones de destino, para saber a cuál de los dispositivos se está transmitiendo, entre otras cosas. No entraremos en más detalle para este protocolo, dado que puede variar significativamente entre implementaciones.

SPI#

Por último, tenemos el Serial Peripheral Interface (SPI), también llamado four-wire serial bus (bus de comunicación de cuatro cables), el cual fue diseñado para comunicación a distancias cortas. Este permite una transferencia de datos mucho más alta que los protocolos anteriores, de aproximadamente 250 Mbps. La comunicación es de tipo síncrona, full-duplex y permite a más de dos dispositivos conectados, pero por simplicidad, solo veremos el caso de un master y un slave.

El protocolo requiere de cuatro señales para establecer comunicación:

• SCLK: Serial Clock, señal de reloj utilizada para sincronizar los dispositivos.
• MOSI: Master Out Slave In, los datos enviados desde el controlador (master), hacia el dispositivo periférico (slave).
• MISO: Master In Slave Out, los datos enviados desde el dispositivo periférico hacia el controlador.
• SS: Slave Select, funciona como una señal de enable. Le indica al dispositivo periférico que el controlador está enviando datos.

La transmisión de datos suele consistir en palabras (words) de 8 bits, aunque algunos dispositivos soportan hasta 12 o 16 bits. A diferencia de UART, SPI no requiere de bits de inicio ni término de la transmisión, lo que le permite una mayor densidad de datos transmitidos. Tampoco interrumpe la transmisión para verificar la recepción ni para coordinar a los dispositivos. Esto último puede significar que el controlador transmita al vacío sin saberlo.

Debido a la alta flexibilidad de SPI, no existe una única forma de transmitir la información. Esto es altamente dependiente de la implementación en particular, y los datos pueden ir codificados de diferentes formas. Debido a esto, no entraremos en más detalle sobre el protocolo.

Herramientas#

Para efectos de este ramo, utilizaremos las herramientas desarrolladas por Saleae para decodificar y leer señales UART, I2C y SPI. Existen otras herramientas con diferentes funcionalidades, capacidades y propósitos, pero no serán necesarias para este curso. Estas herramientas permiten decodificar directamente la información enviada por medio de los protocolos mencionados anteriormente, extrayendo automáticamente el mensaje.

Logic 1#

Logic 1 es una herramienta de legado, la cual ya no se actualiza. Sin embargo, sirve para leer y visualizar archivos .logicdata. Las funcionalidades de esta versión son relativamente limitadas, pero permite trabajar con diferentes tipos de señales.

Como ejemplo, decodificaremos una señal I2C usando Logic 1. Primero abrimos el archivo .logicdata usando Logic 1.

Seleccionamos el analyzer de I2C.

Lo configuramos de la siguiente manera. Sabemos previamente que las direcciones son solo de 7 bits, por lo que usamos esa configuración.

Finalmente, exportamos el resultado. En este caso no tienen mucho sentido los datos, dado que deben ser procesados luego de la exportación.

Logic 2#

Logic 2 es la versión soportada del software, y lee archivos .sal. Los desarrolladores de Saleae no disponen de una herramienta para exportar ni convertir formatos entre las versiones de su software. Esta versión cuenta con muchas más funcionalidades que Logic 1; permite instalar extensiones, realizar análisis más complejos, visualizar los datos de una mejor manera, entre otras cosas.

A continuación analizaremos el contenido de una transmisión UART. En este caso solo tenemos los datos enviados a través de un cable y no conocemos el baud rate. Primero abrimos Logic 2 e importamos el archivo .sal.

De ser necesario, instalamos las extensiones Baud rate estimate y UART HIC Decoder de la pestaña de extensiones.

Luego, vamos a la pestaña de mediciones y medimos la señal completa, para encontrar que el baud rate estimado es de 31.23 kHz.

Finalmente, vamos a la pestaña de analyzers, y seleccionamos un async serial.

Lo configuramos con la frecuencia que encontramos y usamos los valores estándar para el resto de los parámetros.

Con esto logramos decodificar la señal y obtener su contenido. Los datos pueden ser exportados a un archivo CSV o copiados directamente del programa.

Editar en GitHub Modificado por última vez el 18/06/2023 a las 14:08:44 hrs.