Plataformas y familias

01 · Punto de partida

Miles de chips, pocas familias

En los temas anteriores trabajamos con ejemplos concretos, como el STM32F103 o el ATmega328P. Pero en un proyecto real alguien tiene que decidir qué chip usar, y el catálogo de cualquier fabricante tiene cientos de modelos. La buena noticia es que esa variedad se organiza en familias: grupos de chips que comparten núcleo, periféricos, herramientas y filosofía, y que difieren solo en cantidad de memoria, número de pines y algunos extras.

Elegir una familia es una decisión mayor que elegir un modelo. El modelo se puede cambiar con relativo poco esfuerzo dentro de la familia (más memoria, otro encapsulado); cambiar de familia suele significar reescribir la capa de bajo nivel, reaprender las herramientas y revalidar el producto. Por eso conviene pensarlo bien al principio.

Una advertencia sobre los números: los valores de memoria, consumo y precio de este tema son órdenes de magnitud típicos y cambian con cada modelo y con el tiempo. Sirven para comparar familias, no para dimensionar un diseño: eso se hace con la hoja de datos del chip concreto.

02 · Criterios

Qué comparar

Las hojas de datos tienen docenas de parámetros, pero casi toda la decisión se apoya en un puñado de criterios. Los técnicos son los que ya viste en el tema 2; a ellos se suman otros que no figuran en el datasheet y que a menudo pesan más:

Los últimos criterios se subestiman. Un chip excelente en el papel pero con documentación pobre, herramientas inestables o escasez crónica puede costar meses. Y el criterio más importante en la práctica es el segundo bloque: el ecosistema y el conocimiento del equipo. Cada familia que sigue se entiende mejor mirando qué tiene de excepcional en esos aspectos.

03 · Familia 1

AVR: la sencillez de 8 bits

Los AVR (hoy de Microchip, que compró Atmel en 2016) son microcontroladores de 8 bits con arquitectura Harvard y un rendimiento cercano a una instrucción por ciclo de reloj. Se hicieron famosos con el Arduino Uno, que usa un ATmega328P: 32 KB de flash, 2 KB de SRAM, 1 KB de EEPROM, hasta 20 MHz (16 MHz en la placa) y un ADC de 10 bits.

• Fortalezas. Muy simples de entender: pocos registros y periféricos claros. Tolerantes: admiten alimentación de 1,8 a 5,5 V y manejan 5 V directamente. Consumo en reposo muy bajo (del orden de décimas de microamperio en el sueño más profundo). Barato, abundante, con muchísima documentación y bibliotecas.
• Límites. Poca RAM y flash; sin punto flotante por hardware y aritmética de 32 bits lenta. Pocos núcleos de comunicación avanzados y sin USB ni red integrados en el ATmega328P. Reloj modesto.
• Variantes. Los ATtiny son versiones de 6 a 20 pines por centavos para tareas mínimas; las series AVR más nuevas (como AVR128DA) amplían memoria y periféricos.

Cuándo conviene. Aprendizaje, productos sencillos y de bajo volumen (un temporizador, un controlador de riego), y diseños que necesitan 5 V y robustez. Cuándo no: cuando se necesitan comunicaciones complejas, más de unos pocos KB de RAM o cálculo numérico exigente.

04 · Familia 2

ARM Cortex-M: el estándar de 32 bits

ARM no fabrica chips: licencia el diseño del núcleo (los Cortex-M0+, M3, M4, M7 del tema 3) a decenas de fabricantes, que le agregan memoria y periféricos. El resultado es la familia más grande y más usada en productos nuevos: STM32 (STMicroelectronics), nRF52 (Nordic), SAM (Microchip), LPC y Kinetis (NXP), RA (Renesas) y muchos otros.

Su ventaja distintiva es la compatibilidad entre fabricantes. Todos comparten el mismo núcleo, el mismo controlador de interrupciones (NVIC), el mismo temporizador del sistema, la misma interfaz de depuración (SWD) y las mismas bibliotecas base (CMSIS, definidas por ARM). El código de bajo nivel y las herramientas son en gran parte reutilizables. Esa uniformidad es la razón por la cual este curso usa Cortex-M como ejemplo principal.

• Fortalezas. Enorme variedad: desde el Cortex-M0+ de centavos hasta el M7 de cientos de MHz. Herramientas profesionales y gratuitas. Ecosistema inmenso de RTOS, pilas de comunicaciones y bibliotecas. Buenos modos de bajo consumo en las series diseñadas para eso.
• Límites. Complejidad: manuales de referencia de más de mil páginas, relojes y periféricos con muchas opciones. Cada fabricante tiene su propio SDK (HAL de ST, SDK de Nordic) con filosofías distintas, de modo que el código de alto nivel no es portable entre fabricantes sin una capa de abstracción propia.

Dentro de ST, por ejemplo, la familia STM32 se divide en subfamilias: F0 y G0 (económicas, M0/M0+), F1 (M3, la del «Blue Pill»), F4 (M4F, con punto flotante), L (bajo consumo), H7 (alto rendimiento) y las de conectividad inalámbrica. Nordic se especializa en Bluetooth Low Energy con la serie nRF52, muy usada en dispositivos a pila.

Cuándo conviene. Casi siempre que el producto va a escala o vive muchos años: la combinación de variedad, herramientas y continuidad es difícil de igualar. Cuándo no: prototipos muy rápidos donde la curva de aprendizaje pesa más que todo lo demás.

05 · Familia 3

ESP32: la conectividad integrada

La familia ESP32, de Espressif, trajo el Wi-Fi y el Bluetooth al precio de un microcontrolador común. El modelo original (2016) tiene dos núcleos Xtensa a 240 MHz, unos 520 KB de SRAM, flash externa (típicamente 4 MB), Wi-Fi y Bluetooth clásico más BLE. Hoy hay una familia completa:

• Fortalezas. Conectividad integrada a bajo precio, mucha RAM y velocidad, un SDK maduro (ESP-IDF, basado en FreeRTOS) y compatibilidad con Arduino y MicroPython. Se vende en módulos ya certificados para radio, lo que ahorra meses de homologación.
• Límites. Su consumo en sueño profundo (del orden de 10 µA) es mayor que el de las series ultrabajas, y con la radio activa se miden decenas a cientos de miliamperios. El conversor analógico del ESP32 original es poco lineal y ruidoso. Algunos pines tienen restricciones (pines que condicionan el arranque, otros solo de entrada, un ADC que no funciona con el Wi-Fi activo). Y la flash externa vuelve la arquitectura más lenta de lo que sugiere la frecuencia.

Cuándo conviene. Productos conectados a Wi-Fi o Bluetooth, prototipos de IoT, domótica, dispositivos con interfaz web. Cuándo no: dispositivos a pila que deben durar años, o diseños sin conectividad, donde se paga una radio que no se usa.

06 · Familia 4

RP2040: potencia barata y el bloque PIO

El RP2040 es el primer microcontrolador propio de Raspberry Pi (2021), llegó con la placa Pico. Tiene dos núcleos Cortex-M0+ a 133 MHz, 264 KB de SRAM, USB 1.1, un ADC de 12 bits, 30 pines de propósito general y cuesta alrededor de un dólar. No incluye flash: usa una memoria externa por bus QSPI (2 MB en la Pico, hasta 16 MB) y su bootloader grabado en ROM aparece en el PC como una unidad USB a la que se copia un archivo UF2 (tema 5).

Su rasgo más original es el PIO (programmable I/O): ocho pequeñas máquinas de estados programables, en dos bloques de cuatro, que ejecutan un mini programa de instrucciones propias directamente sobre los pines. Permiten implementar protocolos que el chip no trae (un bus de LED WS2812, VGA, un protocolo serie particular) con temporización exacta y sin cargar los núcleos.

• Fortalezas. Mucha RAM y velocidad por poco dinero, el PIO, SDK en C/C++ muy claro, MicroPython de primera clase, documentación excelente, y una placa con depuración SWD barata.
• Límites. Sin radio integrada (la Pico W agrega un módulo Wi-Fi externo). Sin unidad de punto flotante (la ROM trae rutinas rápidas). Su consumo en reposo (cientos de microamperios) es mucho mayor que el de las series de bajo consumo, por lo que no es la mejor opción para pilas. Sin flash propia: depende de un chip externo.

En 2024 apareció el RP2350, sucesor con dos núcleos Cortex-M33 (o RISC-V, a elección), 520 KB de SRAM y funciones de seguridad. Cuándo conviene: proyectos de aprendizaje, producción de bajo costo con mucha E/S o protocolos especiales, instrumentos y dispositivos conectados por USB. Cuándo no: dispositivos a batería de larga duración.

07 · Otras opciones

Otras opciones

Las cuatro familias anteriores no agotan el mercado. Conviene conocer de nombre otras que aparecen en productos y en ofertas de trabajo:

• PIC (Microchip): muy extendidos en la industria, con una enorme variedad de modelos de 8, 16 y 32 bits y una larga trayectoria.
• MSP430 (Texas Instruments): 16 bits, diseñado desde el comienzo para consumo ultrabajo.
• RISC-V: una arquitectura de juego de instrucciones abierta, sin licencia. Cada vez más presente (ESP32-C, CH32V, GD32V y otros), gana terreno en chips económicos.
• Renesas RA, RL78 y RX: fuertes en automoción e industria.
• SoC con Linux: los procesadores de aplicaciones (Cortex-A) del tema 4, cuando el producto lo necesita.

Para el aprendizaje de este curso nos alcanza con las cuatro de las secciones anteriores: la lógica de elección es la misma para cualquier otra.

08 · Resumen

Cuadro comparativo

Dos cosas llaman la atención. Primero, no hay una fila ganadora: cada familia gana en una cosa y pierde en otra. Segundo, los mejores valores no coinciden con lo que muchos esperan: el chip más viejo y más pequeño (AVR) es el que menos consume dormido, y el más potente en frecuencia (ESP32) no lo es en reposo. El «mejor microcontrolador» no existe: existe el más adecuado para cada producto.

09 · Criterios no técnicos

Más allá de la hoja de datos

Cuando varios chips cumplen los requisitos técnicos, la decisión se apoya en factores que no están en las tablas:

• Disponibilidad y cadena de suministro. Entre 2020 y 2022 la escasez mundial de componentes dejó proyectos parados porque un chip concreto no se conseguía durante un año. Hoy se consideran un criterio de diseño: ¿cuántos distribuidores lo venden, hay varias fuentes, existe un reemplazo compatible?
• Longevidad. Para productos que viven 10 o 15 años (medidores, industria, automoción), muchos fabricantes publican programas que garantizan la producción de ciertas familias durante una década o más. Un chip «de moda» puede quedar discontinuado antes.
• Ecosistema y herramientas. Un depurador barato, ejemplos que funcionan, una comunidad que contesta y bibliotecas mantenidas valen semanas de trabajo.
• Del prototipo a la producción. Un prototipo en una placa de desarrollo (Arduino Uno, Blue Pill, una placa Nucleo de ST con depurador incluido, un ESP32 DevKit, una Pico) no es el producto. En producción se diseña la placa propia alrededor del chip, con los componentes del tema 3, y se cambia de un módulo cómodo a un chip suelto más barato. Conviene elegir una familia que ofrezca ese camino sin reescribir todo.
• Certificaciones. Un módulo de radio precertificado (Wi-Fi, Bluetooth) evita meses y mucho dinero de homologación; un chip de radio suelto, no.
• Seguridad. Si el producto debe resistir ataques o actualizarse de forma segura, necesita arranque seguro, almacenamiento de claves y protección de lectura (temas 42 y 43).

10 · Práctica en C

La misma idea en cuatro SDK

Para ver cuánto cambia el código entre plataformas, este es el mismo trabajo (encender un LED) en el entorno de cada una:

// Arduino (AVR y muchas otras placas)
pinMode(LED_BUILTIN, OUTPUT);
digitalWrite(LED_BUILTIN, HIGH);

// SDK de la Raspberry Pi Pico (RP2040)
gpio_init(25);
gpio_set_dir(25, GPIO_OUT);
gpio_put(25, 1);

// ESP-IDF (ESP32)
gpio_reset_pin(GPIO_NUM_2);
gpio_set_direction(GPIO_NUM_2, GPIO_MODE_OUTPUT);
gpio_set_level(GPIO_NUM_2, 1);

// HAL de STM32 (Blue Pill: LED en PC13, enciende con nivel bajo)
__HAL_RCC_GPIOC_CLK_ENABLE();
GPIO_InitTypeDef g = { .Pin = GPIO_PIN_13, .Mode = GPIO_MODE_OUTPUT_PP, .Speed = GPIO_SPEED_FREQ_LOW };
HAL_GPIO_Init(GPIOC, &g);
HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);

La estructura se repite en los cuatro: configurar el pin como salida y escribir su nivel. Lo que cambia son los nombres, la forma de designar el pin (un número, una constante, un puerto y un bit) y los detalles, como el paso previo de darle reloj al puerto en STM32, que ya conocés del tema 3. Fijate que el ejemplo de Arduino oculta justamente eso. Esa diferencia es el motivo por el cual conviene envolver estas llamadas en una capa propia:

// interfaz de la capa de abstracción de hardware (hal_led.h)
void led_iniciar(void);
void led_encender(void);
void led_apagar(void);

// La aplicación solo usa estas tres funciones. Cada plataforma las implementa
// en su propio archivo: hal_led_avr.c, hal_led_pico.c, hal_led_esp32.c...

Con esa separación, migrar el producto a otro chip es escribir un archivo nuevo con las mismas tres funciones, y compilar el que corresponda. Es la base de lo que veremos en los temas 10 y 11.

11 · Analogía con programación

Un selector de plataforma en Python

Elegir plataforma es, en buena parte, filtrar una tabla por requisitos y desempatar por costo. El programa guarda las siete plataformas del laboratorio (con valores aproximados), define los requisitos de un sensor de campo con Bluetooth y a pila, y lista qué requisito incumple cada candidata. Al final elige la más barata entre las que cumplen todo.

PLATAFORMAS = [   # flash y RAM en KB; sleep en µA; precio en US$ (aproximados)
    dict(nombre="ATmega328P",        flash=32,   ram=2,   radio="ninguna", usb=False, fpu=False, sleep=0.1, precio=2.0),
    dict(nombre="STM32F103",         flash=64,   ram=20,  radio="ninguna", usb=True,  fpu=False, sleep=2,   precio=2.5),
    dict(nombre="STM32 bajo consumo",flash=256,  ram=64,  radio="ninguna", usb=True,  fpu=True,  sleep=1,   precio=4.0),
    dict(nombre="RP2040",            flash=2048, ram=264, radio="ninguna", usb=True,  fpu=False, sleep=200, precio=1.0),
    dict(nombre="ESP32",             flash=4096, ram=520, radio="wifi",    usb=False, fpu=True,  sleep=10,  precio=3.0),
    dict(nombre="ESP32-C3",          flash=4096, ram=400, radio="wifi",    usb=False, fpu=False, sleep=5,   precio=2.0),
    dict(nombre="nRF52840",          flash=1024, ram=256, radio="ble",     usb=True,  fpu=True,  sleep=2,   precio=5.0),
]
REQ = dict(flash=64, ram=16, radio="ble", usb=False, fpu=False, sleep=5, precio=6.0)
NIVEL_RADIO = {"ninguna": 0, "ble": 1, "wifi": 2}      # el Wi-Fi también trae BLE


def faltas(p, r):
    f = []
    if p["flash"] < r["flash"]:
        f.append("flash")
    if p["ram"] < r["ram"]:
        f.append("RAM")
    if NIVEL_RADIO[p["radio"]] < NIVEL_RADIO[r["radio"]]:
        f.append("conectividad")
    if r["usb"] and not p["usb"]:
        f.append("USB")
    if r["fpu"] and not p["fpu"]:
        f.append("punto flotante")
    if p["sleep"] > r["sleep"]:
        f.append("reposo")
    if p["precio"] > r["precio"]:
        f.append("precio")
    return f


cumplen = []
for p in PLATAFORMAS:
    f = faltas(p, REQ)
    print(f"{p['nombre']:20s}", "cumple" if not f else "falla: " + ", ".join(f))
    if not f:
        cumplen.append(p)

if cumplen:
    mejor = min(cumplen, key=lambda p: (p["precio"], p["sleep"]))
    print(f"\nLa más barata que cumple todo: {mejor['nombre']} (US$ {mejor['precio']})")
else:
    print("\nNinguna cumple todo: hay que relajar algún requisito.")

Resultado: el ATmega328P falla en flash, RAM y conectividad; el STM32F103 y el STM32 de bajo consumo, en conectividad; el RP2040, en conectividad y reposo; el ESP32, en reposo (10 µA contra el límite de 5). Cumplen el ESP32-C3 y el nRF52840, y se elige el ESP32-C3 por precio (US$ 2 contra 5). Probá sleep=10 en los requisitos: el ESP32 también cumple, pero el C3 sigue ganando. Probá radio="ninguna", flash=16, ram=2 y sleep=1000: cumplen las siete y gana el RP2040. Probá radio="wifi" junto con usb=True: no queda ninguna, porque el ESP32-S3 (que sí tiene ambos) no está en la lista.

La última prueba es la más instructiva: los datos que cargás determinan el resultado. Un selector es tan bueno como la tabla en la que se apoya, y también tan bueno como los requisitos que le das. Si olvidás un requisito (la temperatura de trabajo, la disponibilidad), el programa elegirá sin ese criterio, igual que una persona.

12 · Exploración interactiva

Elegir la plataforma

Definí los requisitos de tu producto y el laboratorio filtra las siete plataformas. Las que cumplen todo aparecen resaltadas y se marca la más barata; las que no, indican qué requisito incumplen. Los datos son aproximados y sirven para entrenar el criterio, no para elegir un componente real.

Recorrido guiado

1. Con los valores iniciales (BLE, 64 KB, 16 KB de RAM, 5 µA, US$ 6) cumplen el ESP32-C3 y el nRF52840, y se marca el C3 por precio. Fijate por qué falla cada una de las otras.
2. Bajá el reposo máximo a 1 µA: ni el C3 ni el nRF cumplen, y no queda ninguna con BLE. Para ese consumo hay que relajar la conectividad, o buscar un chip de radio ultrabajo que esta lista no incluye.
3. Poné Wi-Fi y dejá el reposo en 5 µA: solo el ESP32-C3 lo logra. Subí el reposo a 20 µA y se suma el ESP32.
4. Elegí No necesito conectividad, reposo indiferente, 16 KB de flash y 2 KB de RAM: cumplen las siete. La más barata es el RP2040, pero el ATmega328P también sirve: acá el criterio decisivo ya no es técnico sino el ecosistema y el conocimiento del equipo.
5. Pedí Wi-Fi y USB a la vez: ninguna cumple. Es una combinación real que existe (el ESP32-S3 tiene ambos), pero no está en la lista: relajá un requisito o ampliá la búsqueda.
6. Marcá punto flotante con precio de US$ 1,50: no queda ninguna. Con US$ 3, cumple el ESP32 si el reposo lo permite. Cada requisito que agregás achica la lista.

13 · Método de trabajo

Método para elegir

1. Escribí los requisitos medibles (tema 2): memoria con margen, plazos, consumo, conectividad, entorno, costo objetivo y volumen.
2. Descartá por requisitos duros. Sin radio integrada no hay Wi-Fi sin módulo externo; sin USB no hay dispositivo USB; con un reposo mayor que el presupuesto de la batería no hay vuelta atrás.
3. Armá una lista corta de dos o tres candidatas, de familias distintas si es posible.
4. Compará lo no técnico: disponibilidad en el volumen previsto, longevidad, herramientas, ejemplos, conocimiento del equipo, certificaciones y seguridad.
5. Hacé una prueba de concepto con una placa de desarrollo de cada candidata: lo más riesgoso del proyecto (la radio, el consumo, la lectura del sensor) corriendo en horas y no en semanas.
6. Calculá el costo total: chip, componentes de apoyo, módulos externos, desarrollo y certificación, no solo el precio del microcontrolador.
7. Prevé la salida. Anotá qué se reescribe si hay que cambiar de chip y cuál sería el reemplazo.
8. Documentá la decisión con las alternativas descartadas y por qué.

Si hay empate técnico, desempatá con una regla práctica: la plataforma que tu equipo ya domina. El tiempo de aprender un chip nuevo rara vez se compensa con una diferencia de un dólar.

14 · Comprensión

Confusiones frecuentes

15 · Práctica guiada

Predecí antes de comprobar

1. Una familia para cada producto

Proponé una familia para cada producto y justificá: (a) un temporizador de riego a pila que debe durar 5 años; (b) un sensor ambiental que publica datos por Wi-Fi cada minuto, alimentado por enchufe; (c) un adaptador USB que implementa un protocolo serie inusual con temporización exacta; (d) un controlador de motor industrial que debe producirse y mantenerse 15 años.

2. Autonomía con reposo alto

Un sensor a pila de 1000 mAh pasa casi todo el tiempo dormido. Con un chip que consume 200 µA dormido, ¿cuánto dura la pila (ignorando la actividad)? ¿Y con uno que consume 2 µA?

3. ¿Alcanza la RAM?

Un producto necesita 40 KB de RAM con un margen del 25 %. ¿Cuánta RAM mínima debe tener el chip? ¿Alcanza un STM32F103 de 20 KB? ¿Y un nRF52840 de 256 KB?

4. Costo total de un prototipo a producción

Un chip A cuesta US$ 1,00 pero requiere un módulo de radio externo de US$ 2,50. El chip B cuesta US$ 3,20 e incluye la radio. ¿Cuál es más barato por unidad? ¿Qué otro factor puede inclinar la balanza?

5. Elegir con restricciones contradictorias

Un cliente pide Wi-Fi, 3 años con una pila de botón y un precio de US$ 2 por chip. Con los datos del laboratorio, ¿qué ocurre? ¿Qué alternativas le plantearías?

6. Aislar la plataforma

Escribí la interfaz mínima en C (solo las declaraciones) para que una aplicación pueda leer un botón y encender un LED sin saber en qué chip corre.

16 · Síntesis

Ideas para recordar

¿Listo para el tema 7?

Antes de avanzar, elegí un producto que te interese y justificá la familia que usarías con tres razones técnicas y una no técnica; explicá por qué un chip de bajo costo con reposo alto no es adecuado para una pila; y dibujá la interfaz mínima de una capa de hardware para tu producto. Si podés justificar las tres respuestas, cerraste el bloque de fundamentos.

En el próximo bloque entramos en el firmware propiamente dicho. El tema 7 empieza por preguntar qué es: de main() al binario, qué secciones lo forman y cómo se lee el archivo de mapa que genera el enlazador.