Cierre y puente a la comunicación

01 · Punto de partida

Lo que recorrimos

El curso siguió el camino de una señal, primero hacia el software y después de vuelta al mundo. Nueve bloques:

Lo que une los nueve bloques no es una lista de componentes (las hojas de datos cambian cada año), sino un modo de pensar: cada pieza física tiene un modelo con límites; esos límites se calculan antes de soldar; el software debe desconfiar de lo que lee, no bloquear mientras espera y llevar el sistema a un estado seguro cuando algo falla; y todo se verifica con números, no a ojo. Esa cadena de ideas es lo que se repasa ahora.

02 · El mapa

La cadena completa

Tres aspectos transversales atraviesan toda la cadena: el tiempo (tareas periódicas, millis(), planificación; tema 41), la arquitectura (drivers, interfaces, configuración; tema 40) y la seguridad (validación, límites, perro guardián, modos; tema 44). Cuando algo no anda, el diagnóstico es recorrer la cadena de izquierda a derecha y preguntar en cada etapa: ¿qué entra?, ¿qué sale?, ¿cuál es su límite? La mayoría de los fallos del curso se resolvieron así: un valor que sale del ADC antes de culpar al programa, un pico de corriente antes de culpar al microcontrolador, un tiempo de espera oculto antes de culpar al sensor.

03 · Entradas

Sensores: repaso por magnitud

Tres reglas valen para todos: calibrar contra una referencia (offset y ganancia, tema 5), filtrar sin retardar de más (la mediana para picos, el exponencial para ruido) y validar antes de usar (rango, tasa, congelamiento, edad; tema 44). Y a la hora de elegir un sensor, el orden de las preguntas es: ¿qué rango y qué resolución necesito?, ¿qué exactitud?, ¿qué tiempo de respuesta?, ¿qué interfaz (analógica, digital, bus)?, ¿qué ambiente (humedad, sol, polvo, temperatura)? y ¿qué pasa cuando falla?

04 · Salidas

Actuadores: repaso por carga

Las reglas comunes: el pin da señal, no potencia (unos 20 mA); cada carga inductiva lleva su diodo de rebote; el reposo se escribe antes de ser salida; cada actuador tiene un estado seguro y un tiempo máximo si puede hacer daño; y cada orden se verifica con su efecto (si se manda calentar y no sube la temperatura, algo falla).

05 · Software

Patrones de software

La arquitectura del curso se resume en una frase: una aplicación que solo conoce interfaces, drivers que esconden el hardware, un lazo que no espera, y una capa de seguridad que no depende de lo que protege.

06 · Lecciones

Los errores más caros

De todo lo visto, estos diez errores son los que más tiempo, componentes o seguridad cuestan; casi todos los proyectos que fallan terminan en alguno de ellos:

1. Un LED o una carga conectados al pin sin resistencia o sin driver (temas 27 y 35): se queman el LED o el pin. Un pin da unos 20 mA.
2. Una carga inductiva sin diodo de rebote (temas 27, 28 y 29): el pico de tensión mata al transistor o reinicia el microcontrolador.
3. Un delay() en medio del programa (tema 41): un sensor de 750 ms bloquea 75 ciclos de un lazo de 10 ms.
4. Comparar millis() con un instante absoluto (tema 41): falla a los 49,7 días, cuando ya nadie está mirando.
5. Un valor centinela tomado por un dato (temas 40 y 44): el 85 °C de arranque del DS18B20 o el −127 por falta de sensor se leen como temperaturas reales.
6. Una integral sin anti-windup (tema 43): la temperatura se pasa 13 °C al arrancar el horno.
7. Un control todo o nada sin histéresis y con ruido (tema 42): el relé conmuta más de mil veces por hora y muere en semanas.
8. Un límite de seguridad que depende de lo que protege (tema 44): el límite por software con el mismo sensor no ve al sensor que miente, ni abre un relé pegado.
9. Pines flotantes al reiniciar (tema 44): los actuadores reciben niveles indefinidos hasta que arranca el programa.
10. Creer que lo que funciona en el escritorio funciona en el campo (todo el curso): sin calibrar, sin ruido real, sin batería baja, sin fallas inyectadas y sin ensayo largo con registro.

07 · Antes de encender

Lista de verificación de diseño

Una lista corta que se repasa antes de conectar la alimentación por primera vez y antes de dar por terminado un proyecto:

Y algunos números del curso que conviene tener presentes: un pin da unos 20 mA; un ADC de 10 bits con 5 V resuelve 4,88 mV (uno de 12 bits con 3,3 V, 0,806 mV); un PWM de 8 bits avanza de a 0,39 %; un LED rojo a 5 V y 10 mA pide 330 Ω; millis() da la vuelta a los 49,7 días; un relé de 100 000 ciclos con una ventana de 10 s dura 278 horas (con 600 s, 1,9 años); 300 LEDs WS2812 tardan 9,3 ms por trama y a blanco pleno piden 18,3 A; una pantalla OLED completa por I2C a 400 kHz son unos 26 ms.

08 · El puente

Cuando los dispositivos se hablan

Hasta ahora todo estaba en una placa o a pocos centímetros: el microcontrolador leía sensores y movía actuadores por pines y buses cortos. Pero un sistema real crece: el sensor está a 20 metros del controlador, hay veinte nodos que reportar a una central, el robot se maneja desde un teléfono, el invernadero manda sus datos a la nube, dos microcontroladores se reparten el trabajo. Eso es comunicación, y es el tema del próximo curso.

Lo importante es que los principios no cambian, se trasladan. Casi todo lo aprendido tiene su equivalente en un enlace:

Y aparecen problemas nuevos: la latencia (un dato llega tarde: un lazo de control por red necesita cuentas del retardo, tema 42), la pérdida, duplicación y corrupción de mensajes, la pérdida de sincronía (media trama recibida), el ancho de banda limitado, el ruido en cables largos y la seguridad (¿quién puede mandarle una orden al robot o al calefactor?). La regla de diseño más importante se hereda del tema 44: la red es un extra, no una dependencia de la seguridad; el sistema debe poder quedar solo y estar seguro.

09 · Los cables

Buses: comparación, presupuesto y límites

Ya usamos cuatro buses sin detenernos (I2C para sensores y pantallas, SPI para pantallas TFT, 1-Wire para el DS18B20, UART para el puerto serie). Esta es la comparación que sirve para elegir (valores de referencia, que dependen de los componentes y del cableado):

El presupuesto de un bus es una cuenta de bytes: el tiempo que cuesta un mensaje por la cantidad de mensajes por segundo es la ocupación del bus, y no debería pasar de un 50 a 60 %. Con un UART a 115 200 baudios (10 bits por byte), la capacidad útil es de 11 520 B/s; un I2C cuesta 20 tiempos de bit por transacción más 9 por byte; un SPI, 8 por byte:

La tabla enseña por qué los datos de pocos bytes y baja frecuencia van por cualquier cosa (el invernadero), y por qué los flujos altos exigen un bus rápido (una IMU a 1 kHz no cabe en un UART de 115 200 baudios ni en un I2C de 100 kHz; una pantalla completa pide SPI). Dos límites físicos merecen atención:

• I2C: las resistencias de pull-up y la capacidad del bus. La señal sube con una constante R·C: tsubida ≈ 0,8473 · Rp · Cb, y la norma exige menos de 1000 ns a 100 kHz, 300 ns a 400 kHz y 120 ns a 1 MHz, con un máximo de 400 pF. El pull-up tiene un máximo (para que suba a tiempo) y un mínimo (para que el dispositivo pueda bajarla con 3 mA: (VDD − 0,4 V) / 3 mA, 967 Ω con 3,3 V). Con 100 pF a 400 kHz, la ventana es de 967 a 3541 Ω; con 400 pF a 400 kHz, no hay ninguna resistencia que sirva (hay que bajar la velocidad, acortar los cables o usar un amplificador de bus). Con 4,7 kΩ y 100 pF, la subida es de 398 ns; con 10 kΩ y 400 pF, 3389 ns: demasiado lenta para cualquier modo.
• UART: los baudios no coinciden exactamente. Cada byte se muestrea al medio de cada bit, y el error se acumula a lo largo de los 10 bits de un byte (8N1): el desajuste entre los dos relojes no puede superar 0,5 / 9,5 = 5,26 % (4,76 % con paridad), y en la práctica conviene tener menos de un 2 a 3 %. Un AVR de 16 MHz genera 115 200 baudios con un divisor entero: 111 111 (−3,55 %) o, con U2X, 117 647 (+2,12 %); un AVR sin U2X hablando con otro con U2X tiene un desajuste de −5,6 %, ya fuera de límite. A 9600 baudios, el error es de apenas +0,16 %, por eso es la velocidad «que siempre anda».

10 · Programación

Una trama con CRC y supervisión del enlace

Un enlace serie entrega bytes sueltos, sin límites de mensaje ni garantías. Hay que agregar una trama: un delimitador de inicio, la longitud, la carga útil, una suma de verificación y un delimitador de fin. El receptor la procesa byte a byte con una máquina de estados (sin bloquear, tema 41), recupera la sincronía si se corta una trama, aplica solo las tramas completas con CRC correcto, ignora las repetidas (número de secuencia) y limita lo que recibe antes de usarlo. Si pasan más de 500 ms sin una trama válida, el enlace se da por caído y el robot queda detenido (tema 44).

// ---------- Una trama simple: STX | longitud | carga útil | CRC16 | ETX ----------
constexpr uint8_t STX = 0x02, ETX = 0x03, MAX_CARGA = 32;

uint16_t crc16(const uint8_t *d, uint8_t n) {                    // CRC-16/CCITT-FALSE: polinomio 0x1021, valor inicial 0xFFFF
    uint16_t crc = 0xFFFF;
    while (n--) {
        crc ^= (uint16_t)(*d++) << 8;
        for (uint8_t i = 0; i < 8; i++) crc = (crc & 0x8000) ? (crc << 1) ^ 0x1021 : (crc << 1);
    }
    return crc;
}

void enviar(const uint8_t *carga, uint8_t n) {                   // telemetría: unos 2 ms para 24 bytes a 115 200 baudios
    uint16_t crc = crc16(carga, n);
    Serial.write(STX); Serial.write(n); Serial.write(carga, n);
    Serial.write((uint8_t)(crc >> 8)); Serial.write((uint8_t)(crc & 0xFF)); Serial.write(ETX);
}

// ---------- Recepción sin bloqueos: una máquina de estados que consume byte a byte ----------
enum class Rx : uint8_t { ESPERA_STX, LONGITUD, CARGA, CRC_ALTO, CRC_BAJO, ESPERA_ETX };
Rx rx = Rx::ESPERA_STX;
uint8_t carga[MAX_CARGA], largo = 0, indice = 0;
uint16_t crcRecibido = 0;
uint32_t ultimoByteMs = 0, ultimaTramaValidaMs = 0;

struct Comando { uint8_t secuencia; int16_t vIzq, vDer; };         // lo que llega por el enlace: velocidades en mm/s
uint8_t secuenciaPrevia = 0;

void tramaValida() {
    ultimaTramaValidaMs = millis();
    if (largo != sizeof(Comando)) return;                         // longitud inesperada: se ignora
    Comando c; memcpy(&c, carga, sizeof c);
    if (c.secuencia == secuenciaPrevia) return;                   // repetida: ya se aplicó
    secuenciaPrevia = c.secuencia;
    consignaIzq = constrain(c.vIzq, -400, 400);                   // nunca se confía en un dato remoto: se limita
    consignaDer = constrain(c.vDer, -400, 400);
}

void procesarByte(uint8_t b) {
    switch (rx) {
        case Rx::ESPERA_STX:  if (b == STX) rx = Rx::LONGITUD; break;
        case Rx::LONGITUD:    if (b == 0 || b > MAX_CARGA) rx = Rx::ESPERA_STX; else { largo = b; indice = 0; rx = Rx::CARGA; } break;
        case Rx::CARGA:       carga[indice++] = b; if (indice == largo) rx = Rx::CRC_ALTO; break;
        case Rx::CRC_ALTO:    crcRecibido = (uint16_t)b << 8; rx = Rx::CRC_BAJO; break;
        case Rx::CRC_BAJO:    crcRecibido |= b; rx = Rx::ESPERA_ETX; break;
        case Rx::ESPERA_ETX:
            if (b == ETX && crc16(carga, largo) == crcRecibido) tramaValida();      // solo una trama completa y con CRC correcto
            rx = Rx::ESPERA_STX;
            break;
    }
}

void tareaComunicacion() {                                        // cada vuelta del lazo; lee solo lo que ya llegó
    uint32_t ahora = millis();
    while (Serial.available()) { procesarByte(Serial.read()); ultimoByteMs = ahora; }
    if (rx != Rx::ESPERA_STX && (uint32_t)(ahora - ultimoByteMs) > 50) rx = Rx::ESPERA_STX;   // trama a medias: resincronizar
    if ((uint32_t)(ahora - ultimaTramaValidaMs) > 500) {          // enlace caído: sin órdenes recientes, estado seguro (tema 44)
        consignaIzq = consignaDer = 0;
    }
}

Una suma de verificación detecta los errores de transmisión; no los corrige. Un CRC de 16 bits detecta todos los errores en ráfaga de hasta 16 bits y, en errores aleatorios, deja pasar uno de cada 65 536. Para corregir, hay que retransmitir (con confirmaciones y tiempos límite) o usar códigos correctores, y para que nadie ajeno mande órdenes hace falta autenticación: todo eso es materia del curso de Comunicación.

11 · Analogía con programación

Presupuestos de bus, pull-ups, baudios y CRC

Calculamos los cuatro elementos del puente: la ocupación de cada bus con distintos flujos, las ventanas de resistencias de pull-up del I2C, el error de baudios de un AVR y la probabilidad de que un error de transmisión pase sin detectar según el tamaño del CRC. Al final, algunos de los números del curso.

import math

# ---- 1. Presupuesto de un bus: ¿cabe el tráfico? ----
def t_uart(baudios, n):
    return n * 10 / baudios                                # 8N1: 10 bits por byte


def t_i2c(frecuencia, n):
    return (20 + 9 * n) / frecuencia                       # inicio, dirección, parada y 9 tiempos de bit por byte


def t_spi(frecuencia, n):
    return (n + 1) * 8 / frecuencia                        # un byte de comando y los datos


buses = (("UART 115 200", lambda n: t_uart(115200, n)), ("I2C 100 kHz", lambda n: t_i2c(100e3, n)),
         ("I2C 400 kHz", lambda n: t_i2c(400e3, n)), ("SPI 8 MHz", lambda n: t_spi(8e6, n)))
flujos = (("invernadero: 30 B cada 10 min", 30, 1 / 600), ("robot: telemetría de 24 B a 50 Hz", 24, 50),
          ("IMU de 6 ejes: 12 B a 1 kHz", 12, 1000), ("OLED completa: 1024 B a 30 cuadros/s", 1024, 30))
print("flujo                                     " + "".join(f"{nombre:>14s}" for nombre, _ in buses))
for nombre, n, tasa in flujos:
    celdas = []
    for _, tiempo in buses:
        uso = tasa * tiempo(n) * 100
        celdas.append(f"{uso:12.1f} %" if uso < 1000 else "      no cabe")
    print(f"{nombre:40s}" + "".join(f"{c:>14s}" for c in celdas))
print(f"capacidad útil de un UART a 115 200 baudios: {115200 / 10:.0f} B/s; un mensaje de 24 B tarda {t_uart(115200, 24) * 1000:.2f} ms")

# ---- 2. I2C: resistencias de pull-up y capacidad del bus ----
print()
for modo, t_max in (("100 kHz", 1000e-9), ("400 kHz", 300e-9), ("1 MHz", 120e-9)):
    for c_pf in (100, 200, 400):
        for vdd in (3.3, 5.0):
            r_max = t_max / (0.8473 * c_pf * 1e-12)
            r_min = (vdd - 0.4) / 0.003
            estado = f"{r_min:5.0f} a {r_max:6.0f} ohm" if r_max >= r_min else "imposible con una sola resistencia"
            if vdd == 3.3:
                print(f"{modo:8s} con {c_pf:3d} pF a {vdd} V: {estado}")
print("subida con 4,7 kΩ y 100 pF: %.0f ns; con 10 kΩ y 400 pF: %.0f ns" % (0.8473 * 4700 * 100e-12 * 1e9, 0.8473 * 10000 * 400e-12 * 1e9))

# ---- 3. UART: error de baudios ----
print()
print("error del divisor en un AVR (8N1):")
for f_mcu in (16e6, 8e6):
    for baudios in (9600, 57600, 115200, 230400):
        fila = []
        for u2x in (False, True):
            ubrr = round(f_mcu / ((8 if u2x else 16) * baudios) - 1)
            real = f_mcu / ((8 if u2x else 16) * (ubrr + 1))
            fila.append(f"{'U2X' if u2x else 'normal'}: {real:9.0f} baud ({(real / baudios - 1) * 100:+5.2f} %)")
        print(f"{f_mcu / 1e6:2.0f} MHz, {baudios:6d} baudios -> " + "   ".join(fila))
for nombre, bits in (("8N1", 10), ("8E1", 11)):
    print(f"desajuste máximo entre extremos con {nombre}: {0.5 / (bits - 0.5) * 100:.2f} % (en la práctica, menos del 2 al 3 %)")

# ---- 4. Mensajes con errores: la suma de verificación ----
print()
n, tasa = 24, 10                                           # bytes por mensaje, mensajes por segundo
for ber in (1e-5, 1e-6):
    p_mal = 1 - (1 - ber) ** (8 * n)
    for crc in (0, 8, 16):
        sin_detectar = p_mal * (2.0 ** -crc)
        por_hora = tasa * 3600 * sin_detectar
        print(f"BER {ber:.0e}, {n} B, {tasa} mensajes/s, CRC de {crc:2d} bits: {p_mal * 100:6.3f} % de mensajes con errores; sin detectar por hora: {por_hora:10.4f}")

# ---- 5. Algunos números del curso ----
print()
print(f"ADC de 10 bits con 5 V: {5 / 1024 * 1000:.2f} mV por cuenta; de 12 bits con 3,3 V: {3.3 / 4096 * 1000:.3f} mV")
print(f"millis() da la vuelta a los {2 ** 32 / 86_400_000:.2f} días; micros(), a los {2 ** 32 / 1e6 / 60:.1f} minutos")
print(f"PWM de 8 bits: paso de {100 / 255:.2f} %; LED rojo a 5 V y 10 mA: {(5 - 2.0) / 0.010:.0f} Ω (normalizada: 330 Ω)")
print(f"relé de 100 000 ciclos con una ventana de 10 s: {100_000 / (3600 / 10):.0f} h; con 600 s: {100_000 / (3600 / 600) / 24 / 365:.2f} años")
print(f"300 LEDs WS2812: {(300 * 24 * 1.25e-6 + 300e-6) * 1000:.1f} ms por trama; a blanco pleno, {300 * 0.060 + 0.3:.1f} A")

Resultado: una IMU de 6 ejes a 1 kHz ocupa el 104,2 % de un UART de 115 200 baudios, el 128,0 % de un I2C de 100 kHz y el 32,0 % de uno de 400 kHz; una OLED completa a 30 cuadros por segundo no cabe en los dos primeros y ocupa el 69,3 % del I2C rápido y el 3,1 % del SPI. Con 100 pF a 400 kHz y 3,3 V, el pull-up debe estar entre 967 y 3541 Ω; con 400 pF, no hay ninguno. Un AVR de 16 MHz a 115 200 baudios tiene un error de −3,55 % sin U2X y de +2,12 % con U2X; el desajuste máximo es del 5,26 % con 8N1. Con 24 bytes por mensaje, una tasa de error de bit de 10⁻⁵ y 10 mensajes por segundo, el 0,192 % de los mensajes llega con errores: sin CRC pasan 69 por hora; con CRC de 8 bits, 0,27; con CRC de 16 bits, 0,0011 por hora (uno cada 40 días).

12 · Exploración interactiva

Bus, I2C, UART y errores

El primer instrumento calcula la ocupación de un bus para un flujo de mensajes. El segundo, la ventana de resistencias de pull-up de un bus I2C. El tercero, el error de baudios entre dos extremos de un enlace UART. El cuarto, cuántos mensajes llegan con errores y cuántos pasan sin que se detecten según el CRC.

Recorrido guiado

1. Con UART a 115 200 baudios, 24 bytes y 50 mensajes por segundo: 2,08 ms por mensaje y un 10,4 % de ocupación. Subí a 500 mensajes por segundo: no cabe, y el estado lo avisa.
2. Con 12 bytes a 1000 mensajes por segundo (una IMU): 104 % por UART a 115 200 y 128 % por I2C de 100 kHz; con I2C de 400 kHz, 32 %; con SPI de 8 MHz, 1,3 %.
3. Con 1024 bytes a 30 mensajes por segundo (una pantalla): por UART no cabe; por I2C de 400 kHz, 69 %; por SPI de 8 MHz, 3,1 %. (Con las transacciones cortas de las bibliotecas del tema 38, el I2C es algo más lento.)
4. En el I2C, con 100 pF, 4,7 kΩ, 100 kHz y 3,3 V: subida de 398 ns y ventana de 967 a 11 802 Ω: correcto. Pasá a 400 kHz: 398 ns superan los 300 ns, y el estado avisa; la ventana es de 967 a 3541 Ω y 2,2 kΩ sirve.
5. Con 400 pF y 400 kHz: la ventana no existe (el máximo, 885 Ω, es menor que el mínimo, 967 Ω): ningún pull-up alcanza. Hay que bajar la velocidad, acortar el bus o aislarlo con un amplificador de bus.
6. En el UART, a 16 MHz y 115 200 baudios sin U2X: el AVR genera 111 111 baudios (−3,55 %), con margen bajo. Activá U2X: 117 647 (+2,12 %). Poné el otro extremo en +2,1 % con U2X desactivado: el desajuste (−5,6 %) pasa el límite del 5,26 % y hay errores de trama.
7. A 9600 baudios el error es de +0,16 % con 8 o 16 MHz: es la velocidad que casi siempre funciona.
8. En los errores de transmisión, con 24 bytes, tasa de error 10⁻⁵, 10 mensajes por segundo: 0,192 % de mensajes con errores (6,9 por hora). Sin CRC pasan todos sin detectar (69 por hora); con CRC de 8 bits, 0,27 por hora; con 16 bits, uno cada 40 días.

13 · Próximos pasos

Cómo seguir

1. Construí los dos proyectos (el invernadero y el robot), aunque sea en versión reducida: nada reemplaza ver oscilar un lazo mal ajustado o un relé pegado en una prueba segura.
2. Usá la lista de verificación en cada proyecto nuevo, antes de encenderlo, y guardá un registro de lo que falló: es el mejor material de aprendizaje.
3. Armá tu propia biblioteca de drivers con las interfaces del tema 40, probados con sensores simulados; en unos pocos proyectos, rinde más que cualquier biblioteca de terceros que no conozcas.
4. Medí antes de optimizar: el máximo del lazo, la ocupación de los buses, la corriente real, la temperatura de los transistores.
5. Experimentá con las fallas (sensor desconectado, batería baja, programa colgado) mientras es barato y seguro hacerlo.
6. Pasá al curso de Comunicación, donde se estudian en profundidad los buses y los protocolos: UART, I2C y SPI a fondo, RS-485 y CAN, Bluetooth, Wi-Fi y redes, y cómo proteger, confirmar y sincronizar los datos.
7. Después, Sistemas Embebidos (el ciclo de vida de un producto), IoT (conectar todo a la red) y Robótica (el siguiente paso del robot móvil).

Si algo no anda, recorré la cadena (sección 2) etapa por etapa; si un proyecto crece, separá en capas; si no estás seguro de que es seguro, probá la falla.

14 · Comprensión

Confusiones frecuentes

15 · Práctica guiada

Predecí antes de comprobar

1. Ocupación

Un sensor manda 16 bytes a 200 Hz por un UART a 57 600 baudios. ¿Qué ocupación tiene el enlace?

2. Pull-up

Un bus I2C de 5 V a 100 kHz tiene 250 pF. ¿Entre qué valores debe estar el pull-up?

3. Baudios

Un AVR de 16 MHz genera 115 200 baudios con el divisor entero 8 (sin U2X): 16 000 000 / (16 × (8 + 1)). ¿Qué error tiene y se comunica con una PC exacta?

4. CRC

Un mensaje de 32 bytes sobre un enlace con tasa de error de bit de 10⁻⁶, a 20 mensajes por segundo, con CRC de 16 bits. ¿Cuántos mensajes llegan con errores por hora y cuántos pasan sin detectar?

5. Diseño

Un nodo manda una temperatura y una humedad (4 bytes) cada 30 s por un bus de 1 km. ¿Qué bus elegís y qué protecciones agregás?

6. Diagnóstico

Un robot comandado por Bluetooth sigue avanzando unos segundos después de que se apaga el teléfono. ¿Qué principio del curso falta y cómo se corrige?

16 · Síntesis

Ideas para recordar

¿Listo para el curso 9?

Antes de cerrar, comprobá que podés justificar tres cosas: por qué un límite de seguridad por software con el mismo sensor no protege del sensor, cuántos bytes por segundo ocupa una IMU de 12 bytes a 1 kHz y por qué un robot por Bluetooth debe detenerse solo si se corta el enlace. Si podés, ya sabés percibir y actuar sobre el mundo con un programa, y estás listo para hacer que esos dispositivos se hablen.

El siguiente paso del camino es el curso 9, Comunicación: buses y protocolos entre microcontroladores y periféricos, redes inalámbricas y cableadas, y cómo hacer que los datos lleguen completos, a tiempo y seguros. Gracias por llegar hasta aquí.