Por qué se comunican los dispositivos

01 · Punto de partida

Ningún chip trabaja solo

En los cursos anteriores hiciste que un microcontrolador leyera un sensor y moviera un motor. Ahora mirá cualquier placa real y contá las conversaciones que ocurren dentro de ella: el microcontrolador le pide la temperatura a un sensor, le manda a una pantalla lo que debe dibujar, guarda un dato en una memoria, recibe una orden desde la computadora por el cable USB y, quizá, publica un valor en un servidor por Wi-Fi. Cada una de esas conversaciones es una comunicación entre dispositivos.

Desde la programación, es un problema conocido. Dos procesos que se envían datos necesitan acordar un formato, saber a quién le hablan y decidir qué hacer si un mensaje se pierde. Un endpoint HTTP, una cola de mensajes o un archivo compartido resuelven eso con convenciones. La diferencia es que acá los «procesos» son chips separados y lo que los une son cables, tensiones y tiempos: hasta el último bit debe viajar por un medio físico imperfecto.

Este curso recorre los medios y protocolos más usados, desde los dos hilos de un bus I²C hasta una conexión Wi-Fi. Antes de entrar en cada uno, conviene tener el mapa conceptual común a todos.

02 · Vocabulario

Emisor, receptor, canal y mensaje

Toda comunicación, entre chips o entre personas, se describe con los mismos elementos:

• El emisor (o transmisor) es el dispositivo que origina la información y la envía.
• El receptor es el dispositivo que la recibe y la interpreta.
• El canal (o medio) es el camino físico por el que viaja la señal: un par de cables, una pista del circuito impreso, una fibra, el aire.
• El mensaje es la información que se quiere transmitir: una temperatura, una orden, un byte de configuración, un archivo.
• El protocolo es el conjunto de reglas que emisor y receptor siguen para que el mensaje se entienda.

Un mismo dispositivo suele cumplir los dos papeles en distinto momento: el microcontrolador es receptor cuando recibe el dato del sensor y emisor cuando le manda una orden. En muchos enlaces, además, uno de los extremos es quien inicia la conversación y el otro solo responde; esos roles (maestro y esclavo, cliente y servidor) se estudian en el tema 6.

03 · El panorama completo

El modelo básico de comunicación

El mensaje no viaja como lo imagina el programador. En el camino pasa por etapas que lo transforman en señales y, del otro lado, lo reconstruyen. Cada etapa puede fallar, y saber en cuál ocurre un error es la mitad de la depuración.

Seguí un ejemplo concreto: un termómetro digital le informa «25,4 °C» a un microcontrolador por un bus I²C.

1. El sensor mide y guarda el resultado en un registro interno como un número de 16 bits.
2. Cuando el microcontrolador lo pide, el sensor divide ese número en bytes y el codificador los convierte en bits, uno por vez.
3. Cada bit se transforma en una tensión sobre la línea de datos: nivel alto o bajo en el momento marcado por el reloj.
4. El canal (dos cables de unos centímetros) propaga esas tensiones. En el camino, un motor cercano puede inducir ruido.
5. El decodificador del microcontrolador muestrea la línea en cada pulso de reloj y reconstruye los bits.
6. El programa junta los bytes, los interpreta como temperatura y, si el sensor lo permite, confirma la recepción con una señal de reconocimiento (ACK).

Los pasos 2, 3, 5 y 6 los hace casi siempre un periférico del chip (UART, SPI, I²C) y no tu código. Aun así, es tu responsabilidad configurarlo con los mismos parámetros que el otro lado, y por eso este curso se detiene en cada uno.

04 · Dónde aparece

Qué se comunica y con qué

No existe un medio de comunicación mejor que los demás: cada escenario impone distancia, velocidad, cantidad de dispositivos y condiciones eléctricas distintas, y hay una solución adaptada a cada uno. Este es el mapa del curso:

Observá que una misma placa puede usar varios a la vez: un ESP32 que lee un sensor por I²C, muestra datos en una pantalla por SPI, depura por UART y los envía por Wi-Fi. En un sistema real, el trabajo del programador es elegir y combinar el medio adecuado para cada tramo.

05 · Reglas del juego

Los acuerdos que forman un protocolo

Dos cables conectados no bastan para que dos chips se entiendan. Si uno envía bits a un ritmo y el otro los lee a otro, o si no saben dónde empieza un mensaje, lo que llega es basura. Un protocolo es el conjunto de acuerdos que evita eso. Casi todos responden a las mismas seis preguntas:

La tabla permite ver una diferencia importante. UART resuelve los tres primeros acuerdos y casi nada más: el resto queda a cargo del programador. I²C resuelve cinco de los seis y deja solo el significado de los datos. Cuanto más completo es el protocolo, menos tenés que programar, pero menos libertad tenés para adaptarlo.

06 · Ordenar la complejidad

El modelo de capas

Los acuerdos del apartado anterior son demasiados para tratarlos juntos, así que se organizan en capas. Cada capa resuelve un problema con la ayuda de la capa inferior y le ofrece un servicio a la superior, sin necesitar conocer los detalles de las demás. Es la misma idea de abstracción que en el software: una función usa a otra a través de su interfaz, sin mirar su implementación.

Los modelos teóricos (OSI tiene siete capas, TCP/IP cuatro) se pueden resumir en cinco niveles para fines prácticos:

Los buses sencillos de placa se limitan a las capas 1 y 2: SPI y UART casi solo definen la parte física y una forma elemental de enviar bytes, mientras que I²C agrega direcciones y confirmaciones. Todo lo demás lo pone la aplicación. En cambio, un mensaje MQTT sobre Wi-Fi atraviesa las cinco capas y cada una de ellas la maneja un componente distinto: la radio, el controlador Wi-Fi, la pila IP, la biblioteca TCP y tu programa.

Las capas traen dos beneficios muy concretos:

• Intercambiabilidad. Un mensaje HTTP viaja igual sobre Ethernet que sobre Wi-Fi, porque las capas superiores no dependen de la física.
• Diagnóstico ordenado. Si algo no funciona, se revisa de abajo hacia arriba: ¿hay señal?, ¿llegan tramas?, ¿la dirección es correcta?, ¿se entiende el contenido?

07 · Cómo viaja un mensaje

Encapsulación: mensajes dentro de mensajes

Para atravesar las capas, el mensaje se va envolviendo. Cada capa recibe de la superior un bloque de datos (su carga útil), le agrega un encabezado con información propia (destinatario, longitud, tipo) y, a veces, un final con una verificación. El resultado pasa como carga útil a la capa de abajo. Del otro lado se hace lo contrario: cada capa retira su envoltorio y entrega el contenido hacia arriba.

En este ejemplo, el mensaje útil ocupa seis bytes, pero la trama completa ocupa diez: cuatro bytes son sobrecarga (overhead) que no transporta información propia, pero que permite que el mensaje llegue al destinatario correcto, con la longitud correcta y verificable. Esa relación se puede calcular:

La eficiencia mejora con mensajes largos, porque el encabezado y el final son fijos. Es un compromiso clásico de las comunicaciones: cuanto más protección y direccionamiento se agregan, más datos «inútiles» viajan. Por eso un protocolo para enviar un solo byte de un sensor (como en I²C) tiene muy poca sobrecarga, y uno diseñado para atravesar Internet (Ethernet + IP + TCP + HTTP) puede superar los 50 bytes de encabezados antes de llegar al primer dato.

08 · Comparar enlaces

Qué distingue a un enlace de otro

Antes de estudiar cada tecnología conviene saber con qué criterios compararlas. Son pocos y reaparecen en todo el curso, hasta llegar al tema 50, donde los usamos para elegir el protocolo adecuado:

• Velocidad. Cuántos bits por segundo se pueden mover.
• Distancia. Hasta dónde se puede llegar sin perder la señal.
• Cantidad de dispositivos. Si el enlace es entre dos o admite muchos.
• Cableado. Cuántos hilos hacen falta, o si no hay ninguno.
• Robustez frente al ruido. Cómo se comporta en un entorno eléctricamente hostil.
• Consumo y costo. Importantes en equipos a batería y de producción masiva.
• Complejidad. Cuánto software requiere y qué tan fácil es depurarlo.

Dos tendencias saltan a la vista: casi siempre a mayor distancia, menor velocidad, y a mayor cantidad de nodos, más reglas para compartir el medio. No hay tecnología que gane en todos los criterios, y por eso hay tantas.

09 · Analogía con programación

Una trama con verificación, en Python

El código para una UART o un bus real depende del microcontrolador, así que usamos Python para explorar las ideas del tema. El programa arma la trama de la figura (destino, origen, longitud, carga útil y checksum), simula un canal que invierte bits en posiciones elegidas y deja que el receptor la valide. Los casos prueban qué ocurre si el canal es perfecto, si cambia un bit y si cambia dos.

def checksum(datos):
    """Suma de todos los bytes, módulo 256 (cabe en un byte)."""
    return sum(datos) % 256


def armar_trama(destino, origen, texto):
    carga = texto.encode("utf-8")
    cuerpo = bytes([destino, origen, len(carga)]) + carga
    return cuerpo + bytes([checksum(cuerpo)])


def canal(trama, bits_alterados):
    """Canal con ruido: invierte los bits de las posiciones indicadas."""
    datos = bytearray(trama)
    for pos in bits_alterados:
        datos[pos // 8] ^= 1 << (pos % 8)
    return bytes(datos)


def recibir(trama, mi_direccion):
    cuerpo, recibido = trama[:-1], trama[-1]
    if checksum(cuerpo) != recibido:
        return "descartada: error de checksum"
    if cuerpo[0] != mi_direccion:
        return "ignorada: no es para mí"
    largo = cuerpo[2]
    return "entregada: " + cuerpo[3:3 + largo].decode("utf-8", errors="replace")


trama = armar_trama(0x12, 0x01, "OK 25C")
print("trama enviada:", trama.hex(" "), f"({len(trama)} bytes)")

casos = {
    "canal perfecto": [],
    "un bit alterado": [24],
    "dos bits alterados": [28, 52],
}
for nombre, alterados in casos.items():
    llegada = canal(trama, alterados)
    print(f"{nombre:20s} {llegada.hex(' ')}  -> {recibir(llegada, 0x12)}")

Resultado: sin errores, el receptor entrega «OK 25C». Con un bit alterado (el último bit del primer carácter pasa de 1 a 0, de «O» a «N»), la suma ya no coincide y la trama se descarta: el error se detecta. Con los dos bits de las posiciones 28 y 52, uno sube 16 unidades y el otro las baja, la suma queda igual y el receptor entrega «_K "5C» sin darse cuenta. Probá con otras posiciones y buscá más combinaciones que engañen al checksum.

Este último caso es una lección central: una verificación simple detecta la mayoría de los errores, pero no todos. Por eso existen métodos más fuertes, como el CRC, que vamos a implementar más adelante (tema 44). El modelo, además, supone que el canal solo invierte bits; los canales reales también pueden perder, repetir o desordenar mensajes.

10 · Exploración interactiva

Un canal con ruido, de extremo a extremo

Este laboratorio manda un mensaje por un canal imperfecto. Escribí un texto corto, elegí qué tan ruidoso es el canal (la probabilidad de que cada bit se invierta, o tasa de error de bit) y decidí si la trama lleva checksum y cuántas veces se puede reintentar. Cada envío construye la trama, la hace pasar por el canal y deja que el receptor decida si la acepta. Los bytes alterados se resaltan.

Limpiar estadísticas pone en cero los contadores; el mensaje y las opciones se conservan. El checksum de la simulación es la suma de los bytes módulo 256, igual que en el código Python.

Recorrido guiado

1. Con ruido en 0 %, enviá el mensaje varias veces: siempre llega intacto en un solo intento. Anotá el tamaño de la trama y la eficiencia.
2. Cambiá el ruido a 2 % y desmarcá el checksum. Enviá unas diez veces. Algunas veces el texto llega alterado y el receptor lo acepta igual: sin verificación, los errores pasan inadvertidos.
3. Marcá el checksum y poné los reintentos en 0. Los mensajes dañados ahora aparecen como no entregados: el receptor detecta el error y descarta la trama. Ya no recibe datos erróneos, pero pierde algunos mensajes.
4. Subí los reintentos a 3. La mayoría de los envíos se entrega intacta, a costa de varios intentos. Observá que el contador de intentos crece cuando el ruido aumenta.
5. Subí el ruido a 10 % con 3 reintentos. Con 10 bytes por trama, hay 80 bits, y la probabilidad de que lleguen todos bien es 0,9⁸⁰, es decir, casi 0,02 %: ningún reintento alcanza. Un mensaje más largo se vuelve imposible de entregar. Este es el límite de los canales muy ruidosos.
6. Escribí un mensaje de una sola letra y otro de 24 caracteres. Compará la eficiencia: la sobrecarga fija pesa mucho más en el mensaje corto.
7. Con checksum y 5 % de ruido, enviá 50 mensajes y buscá si aparece algún «entregado dañado». Es poco frecuente, pero posible: un checksum no detecta todos los errores.

11 · Método de trabajo

Cómo analizar un enlace de comunicación

Cada vez que debas conectar dos dispositivos, o entender por qué no se entienden, recorré estas preguntas en orden:

1. Identificá a los participantes y sus roles. ¿Quién inicia la comunicación, quién responde, cuántos son?
2. Definí el mensaje. ¿Qué datos viajan, de qué tamaño, con qué frecuencia y en qué sentido?
3. Elegí el canal. Distancia, velocidad necesaria, ruido ambiental, cantidad de cables disponibles y consumo.
4. Revisá la capa física. Niveles de tensión compatibles, masa común, resistencias requeridas y velocidad coincidente.
5. Revisá el encuadre. ¿Cómo sabe el receptor dónde empieza y termina cada mensaje?
6. Definí el direccionamiento. Si hay más de dos nodos, ¿cómo se identifica el destinatario?
7. Decidí qué hacer con los errores. ¿Se detectan?, ¿se reenvía?, ¿se ignora el dato perdido?
8. Documentá el significado. Una tabla con campos, unidades y rangos evita que los dos extremos interpreten distinto los mismos bytes.

Cuando algo falla, avanzá en sentido contrario, de abajo hacia arriba: primero la masa y las tensiones con el multímetro, luego los tiempos con el osciloscopio o el analizador lógico, después las tramas en el monitor serie y por último el significado de los datos. En la práctica, la mayoría de las fallas de comunicación se concentran en las capas más bajas: un cable cruzado, una velocidad distinta o una masa sin unir.

12 · Comprensión

Confusiones frecuentes

13 · Práctica guiada

Predecí antes de comprobar

1. Identificar los elementos

Un teclado inalámbrico envía las pulsaciones a una computadora por Bluetooth. Indicá el emisor, el receptor, el canal, el mensaje y el protocolo.

2. ¿Qué acuerdo falta?

Dos microcontroladores se conectan por dos cables y uno envía el texto «23.5» en una línea serie. El otro lo recibe como «ÿÿ¿ñ». Todo está bien cableado. ¿Qué acuerdo probablemente no se cumple y cómo se corrige?

3. Eficiencia de una trama

Una trama tiene 2 bytes de encabezado, 1 byte de longitud y 2 bytes de CRC. ¿Qué eficiencia tiene al enviar una carga de 4 bytes? ¿Y con 100 bytes?

4. Ubicar en capas

Ubicá cada elemento en su capa del modelo de cinco niveles: un cable de par trenzado, un mensaje MQTT, una dirección IP, una dirección MAC, el protocolo TCP.

5. Probabilidad de una trama limpia

Una trama de 20 bytes se envía por un canal en el que cada bit falla con probabilidad 0,1 %. ¿Qué probabilidad hay de que llegue sin errores?

6. Diagnóstico por capas

Un sensor I²C no responde. Ordená estas comprobaciones de la primera a la última: (a) verificar que los registros se interpretan bien; (b) comprobar que SDA y SCL tienen 3,3 V en reposo; (c) revisar que la dirección usada es la del chip; (d) confirmar que la masa de ambas placas está unida.

14 · Síntesis

Ideas para recordar

¿Listo para el tema 2?

Antes de avanzar, describí de memoria una comunicación de tu proyecto con sus cinco elementos, enumerá los seis acuerdos de un protocolo con un ejemplo de cada uno y explicá por qué un checksum no asegura que los datos sean correctos. Si podés justificar las tres respuestas, tenés el vocabulario del curso.

En el próximo tema estudiamos la comunicación serie y paralela: por qué mandar los bits de a uno terminó imponiéndose sobre mandarlos todos a la vez, y qué problemas de sincronización aparecen en cada caso.