Restricciones y requisitos

01 · Punto de partida

Programar con el presupuesto en la mano

En el tema anterior viste que un sistema embebido es una computadora dedicada a una función dentro de un producto. Esa «dentro de un producto» tiene una consecuencia práctica: alguien decidió cuánto puede gastar en el chip, cuánto espacio tiene en la placa y cuánta energía le entrega la fuente antes de que escribas la primera línea de código. Tu trabajo es hacer que el programa quepa en ese marco.

Para un programador acostumbrado a las aplicaciones, es un cambio fuerte. Si una aplicación necesita más memoria, se agrega; si es lenta, se compra un procesador mejor. En un producto que se fabrica por miles, cada centavo del chip, cada kilobyte de memoria y cada microamperio de consumo se multiplican por el volumen y por los años de uso. Por eso un buen diseñador de firmware piensa en recursos como un contador piensa en dinero: con un presupuesto.

Distinguimos dos tipos de exigencias. Las restricciones son límites que impone el producto o el hardware (memoria, costo, tamaño). Los requisitos son lo que el sistema debe cumplir (qué hace y con qué calidad). Las restricciones acotan el espacio de soluciones; los requisitos dicen qué buscar dentro de él.

02 · Recursos limitados

Memoria, velocidad y energía

Cuatro recursos concentran casi todas las decisiones de un firmware:

• Memoria de programa (flash). Guarda el código y las constantes. Si el firmware no entra, no se puede grabar; ninguna optimización posterior arregla un chip demasiado chico.
• RAM. Guarda variables, pila y buffers mientras el programa corre. Suele ser mucho más escasa que la flash (entre 4 y 16 veces menos, según el chip) y su agotamiento causa fallas difíciles de rastrear.
• Capacidad de cálculo. Cuántas instrucciones por segundo puede ejecutar el procesador. Si el trabajo exigido supera esa capacidad, se pierden plazos.
• Energía. Cuánta corriente consume y de dónde sale: red eléctrica, batería recargable o pila que debe durar años.

Los recursos no son independientes: se compensan entre sí. Un cálculo ahorra memoria si se hace en cada ejecución, pero gasta CPU; una tabla precalculada ahorra CPU pero ocupa memoria. Un reloj más rápido libera tiempo, pero consume más energía. Optimizar es mover el problema de un recurso a otro, y por eso hace falta saber cuál es el escaso en cada producto.

Por último, el consumo de energía depende sobre todo de cuánto tiempo está despierto el procesador. Un microcontrolador puede consumir miles de veces menos dormido que activo. Si un dispositivo a pila trabaja el 0,1 % del tiempo y duerme el resto, su autonomía la determina el consumo dormido y no el activo. Ese es el centro del bloque de bajo consumo.

03 · Economía

Costo y volumen de producción

El costo es una restricción tan técnica como la memoria. Se compone de dos partes: el costo unitario (materiales y fabricación de cada equipo) y el costo de ingeniería no recurrente, o NRE (diseño, desarrollo del firmware, certificaciones y herramientas), que se paga una sola vez y se reparte entre todas las unidades.

Con 4,50 dólares de materiales y 60.000 de NRE: fabricando 10.000 unidades cada una cuesta 4,50 + 6,00 = 10,50; fabricando un millón, 4,50 + 0,06 = 4,56. La conclusión cambia la estrategia según el volumen:

• En series chicas, el NRE domina. Conviene gastar más en un chip cómodo, con memoria de sobra, que ahorre semanas de ingeniería.
• En series enormes, el material domina. Conviene invertir ingeniería en un firmware muy ajustado que entre en el chip más barato, porque cada centavo se multiplica por millones.

Es la razón por la cual el mismo problema (un termostato) se resuelve con un microcontrolador sin pantalla en un electrodoméstico de millones de unidades y con una placa generosa en un equipo industrial de cien. Ninguna de las dos decisiones es «mejor» en sí misma: depende del volumen.

04 · Mundo físico

Tamaño, entorno y vida útil

Un firmware vive dentro de un objeto físico, y ese objeto impone más restricciones que no tienen que ver con el código:

• Tamaño y peso. Un auricular inalámbrico o un parche médico dejan unos milímetros cuadrados para el procesador, la antena y la batería.
• Temperatura de trabajo. Los componentes se venden en grados: el comercial suele cubrir de 0 a 70 °C, el industrial de −40 a 85 °C y el automotriz llega a 125 °C. Un dispositivo a la intemperie no puede usar un chip de grado comercial.
• Ruido eléctrico y humedad. Un motor o un relé cercano perturban las señales; la humedad y el polvo atacan los contactos. El firmware debe tolerar lecturas ruidosas y comunicaciones con errores.
• Vibración y golpes. Pueden provocar falsos contactos y reinicios intermitentes, que el software tiene que detectar y recuperar.
• Vida útil. Un juguete tiene un par de años, un medidor de energía quince, una central industrial treinta. Cuanto más larga, más importa que el dispositivo se pueda mantener y actualizar.
• Normas y certificaciones. Compatibilidad electromagnética, seguridad eléctrica, normas médicas o automotrices. Condicionan el hardware, el proceso de desarrollo y la forma de documentar el firmware.

Muchas de estas restricciones se traducen directamente en tareas de software. El ruido pide filtrar lecturas. La vibración pide reintentos y verificación de conexiones. Las normas piden trazabilidad entre requisito, código y prueba. Aprender a leerlas en la hoja de especificaciones del producto es una habilidad tan importante como programar.

05 · Plazos

Requisitos de tiempo

El tiempo es la restricción que más distingue un firmware de una aplicación común. Cada acción del sistema tiene un plazo: el máximo que puede pasar entre un evento y su respuesta. Lo que importa no es la velocidad promedio sino el peor caso.

El tiempo de un byte a 115200 baudios sale de que cada byte ocupa 10 bits en el cable (inicio, 8 de datos y parada): 10 / 115200 ≈ 87 µs. Si tu código está ocupado haciendo otra cosa más de ese tiempo y el hardware no tiene almacenamiento intermedio, el dato siguiente pisa al anterior.

Se distingue entre sistemas de tiempo real duro (perder un plazo es una falla del sistema) y blando (perderlo degrada la calidad pero se tolera, como un cuadro de video descartado). Ese vocabulario, y las técnicas para cumplir los plazos, se desarrolla en el bloque de tiempo real a partir del tema 13. Por ahora basta con incorporar el hábito: para cada respuesta importante, anotá el plazo y qué pasa si se pierde.

06 · Especificar

Escribir requisitos medibles

Los requisitos se dividen en funcionales (qué hace: «mide la temperatura y activa el calefactor») y no funcionales (con qué calidad lo hace: velocidad, consumo, confiabilidad, costo). Los primeros suelen ser fáciles de anotar. Los segundos son los que el producto más sufre cuando están mal escritos.

La regla es que todo requisito debe poder verificarse con una medición. «Que sea rápido» no se puede probar; «responde a la pulsación en menos de 100 ms» sí.

Observá la última columna: si no sabés cómo vas a verificarlo, todavía no es un requisito. Un buen requisito tiene un valor, una condición y un método de verificación. Además, los requisitos entran en conflicto: bajar el consumo suele subir el tiempo de respuesta, y más funciones empujan el costo. Detectar esos choques temprano es parte del diseño, y la forma de documentarlos la vemos en el bloque final del curso.

07 · Prudencia

Márgenes de diseño

Una estimación de recursos nunca es exacta. El código crece durante el desarrollo, aparece una función que no estaba prevista, una biblioteca resulta más grande de lo que decía la documentación. Por eso nunca se diseña al 100 %: se deja un margen.

La actualización remota del firmware agrega una exigencia: si el dispositivo guarda la versión nueva mientras sigue corriendo la vieja (esquema de dos copias, que vemos en el bloque de actualización), la flash necesaria casi se duplica. Es mejor planear eso desde el principio que descubrirlo cuando el producto ya está fabricado, porque la memoria de un chip no se agranda después.

Ese es uno de los pocos aspectos del firmware que no se puede corregir con una actualización: el hardware que fabricaste es el que tendrás durante toda la vida del producto. Equivocarse por poco en un chip que ya está soldado en cien mil placas es mucho más caro que elegir uno de la siguiente categoría desde el comienzo.

08 · Medir en la práctica

Medir lo que ocupa el firmware

Estimar está bien al comienzo, pero después hay que medir. El compilador y el enlazador informan cuánto ocupa el firmware en cada memoria. Con las herramientas de ARM (la misma idea vale para AVR y otros), el comando size muestra:

$ arm-none-eabi-size firmware.elf
   text    data     bss     dec     hex filename
  41236     812    5380   47428    b944 firmware.elf

Cada columna corresponde a una sección del programa (las estudiamos en el tema 7 y el 28):

• text: el código y las constantes. Vive en la flash.
• data: variables globales con valor inicial. Ocupan flash (el valor inicial guardado) y RAM (la variable en uso).
• bss: variables globales sin valor inicial, que arrancan en cero. Ocupan solo RAM.

La RAM estática no incluye la pila ni el heap, que crecen mientras el programa corre. Por eso un chip con 8 KB de RAM no queda «con 1,8 KB libres» en este caso: la pila y la memoria dinámica deben caber en ese resto, y ese resto hay que dimensionarlo con cuidado (tema 29).

Otra costumbre que ahorra memoria es elegir el tamaño justo de los tipos de datos. Un ejemplo con un buffer de muestras de un sensor, en un chip de 2 KB de RAM:

float    muestras_a[500];   // 500 × 4 bytes = 2000 bytes → 98 % de los 2048 bytes de RAM
uint16_t muestras_b[500];   // 500 × 2 bytes = 1000 bytes → 49 %
uint8_t  muestras_c[500];   // 500 × 1 byte  =  500 bytes → 24 %, si el sensor entrega 8 bits

Los tres arreglos guardan 500 muestras; la diferencia está en cuánta información real tiene cada una. Si el conversor del sensor entrega 10 o 12 bits, uint16_t alcanza y ahorra la mitad respecto de float. Usar float por costumbre es un lujo que en un microcontrolador chico, sin unidad de punto flotante, también cuesta tiempo de cálculo.

09 · Analogía con programación

Presupuesto de recursos en Python

Dimensionar un producto es, en el fondo, una cuenta. El programa compara los requisitos de un sensor de campo a pila (180 KB de flash, 40 KB de RAM, 0,3 millones de instrucciones por segundo y una batería de 2000 mAh) con cuatro chips, calcula el porcentaje de cada recurso, estima la corriente media suponiendo que el procesador duerme cuando no trabaja, y elige el más barato que cumple con margen. Los valores de los chips son didácticos: órdenes de magnitud y no datos de un modelo concreto.

CHIPS = {   # flash y RAM en KB, mips = millones de instrucciones/s, corrientes en mA
    "8 bits, 16 MHz":         dict(flash=32,   ram=2,   mips=16,  act=8,  sleep=0.002, precio=1.50),
    "Cortex-M0+, 48 MHz":     dict(flash=64,   ram=8,   mips=40,  act=6,  sleep=0.002, precio=0.80),
    "Cortex-M4, 80 MHz":      dict(flash=256,  ram=64,  mips=100, act=15, sleep=0.003, precio=3.00),
    "SoC con radio, 240 MHz": dict(flash=4096, ram=520, mips=400, act=80, sleep=0.010, precio=3.50),
}
PRODUCTO = dict(flash=180, ram=40, mips=0.3, bateria=2000)   # sensor de campo a pila
UNIDADES = 100_000


def evaluar(chip, dormir=True):
    pf = PRODUCTO["flash"] / chip["flash"] * 100
    pr = PRODUCTO["ram"] / chip["ram"] * 100
    pc = PRODUCTO["mips"] / chip["mips"] * 100
    activo = min(1, PRODUCTO["mips"] / chip["mips"])      # fracción del tiempo despierto
    if dormir:
        corriente = activo * chip["act"] + (1 - activo) * chip["sleep"]
    else:
        corriente = chip["act"]
    dias = PRODUCTO["bateria"] / corriente / 24
    cumple = pf <= 75 and pr <= 75 and pc <= 60       # con margen
    return pf, pr, pc, dias, cumple


candidatos = []
for nombre, chip in CHIPS.items():
    pf, pr, pc, dias, cumple = evaluar(chip)
    estado = "cumple" if cumple else "NO cumple"
    print(f"{nombre:24s} flash {pf:5.0f} %  RAM {pr:5.0f} %  CPU {pc:4.1f} %  "
          f"{dias:5.0f} días  {estado}")
    if cumple:
        candidatos.append((chip["precio"], nombre))

precio, elegido = min(candidatos)
print(f"\nMás barato que cumple: {elegido}, US$ {precio * UNIDADES:,.0f} para {UNIDADES:,} unidades")

dias_sin_dormir = evaluar(CHIPS[elegido], dormir=False)[3]
dias_durmiendo = evaluar(CHIPS[elegido], dormir=True)[3]
print(f"Autonomía durmiendo: {dias_durmiendo:.0f} días; sin dormir nunca: {dias_sin_dormir:.0f} días")

Resultado: el chip de 8 bits y el Cortex-M0+ no cumplen (563 % y 281 % de la flash; 2000 % y 500 % de la RAM). Cumplen el Cortex-M4 (70 % de flash, 63 % de RAM, 0,3 % de CPU, unos 1736 días) y el SoC con radio (4 %, 8 %, 0,1 % y unos 1191 días). El más barato que cumple es el Cortex-M4, con US$ 300.000 para 100.000 unidades. Su autonomía cae de unos 1736 días a unos 6 si el procesador nunca duerme. Probá subir flash del producto a 200: el Cortex-M4 pasa al 78 % y deja de cumplir con margen, así que el programa elegirá el SoC aunque cueste más.

Observá cuánto pesa una sola decisión de firmware: dormir mientras no hay trabajo cambia la autonomía en un factor de unas 300 veces. Con un buen diseño, el consumo lo domina la corriente dormida; con uno malo, el procesador es un calefactor de pila. Y fijate en que la elección del chip depende del conjunto de requisitos: la flash eliminó los dos primeros, y el costo decidió entre los dos restantes.

10 · Exploración interactiva

¿Entra en este chip?

Elegí un producto, un microcontrolador y un volumen de fabricación. El laboratorio calcula qué porcentaje de la flash, la RAM y la capacidad de cálculo ocupa el firmware, estima la corriente media y la autonomía y suma el costo de los chips. Un resultado en naranja indica que el recurso quedó ajustado o que no alcanza. Los números son didácticos; sirven para entrenar el criterio y no para elegir un componente real.

La autonomía solo se calcula para los productos con batería. El resultado «holgado» corresponde a una flash o una RAM de hasta el 75 % y una CPU de hasta el 60 %; «ajustado», a hasta el 100 % de la memoria o el 85 % de la CPU; por encima de eso, no cumple.

Recorrido guiado

1. Con el termostato de heladera y el chip de 8 bits: unos 38 % de flash, 40 % de RAM y 3 % de CPU. Cumple con margen, con un costo de US$ 150.000 para 100.000 unidades.
2. Cambiá al Cortex-M0+: también cumple (19 % de flash) y el costo baja a US$ 80.000. Un chip más nuevo puede ser a la vez más capaz y más barato; la elección no es solo «el más chico».
3. Elegí el sensor de campo con el chip de 8 bits: 563 % de la flash y 2000 % de la RAM. No cumple y ninguna optimización lo arregla. Probá con el Cortex-M0+: tampoco.
4. Con el sensor y el Cortex-M4: cumple con margen y la autonomía ronda los 4,8 años. Desmarcá «Dormir cuando no hay trabajo»: cae a unos 6 días. La misma lógica, el mismo hardware, un diseño que no duerme.
5. Con el sensor y el SoC con radio: cumple con una holgura enorme, pero cuesta más (US$ 350.000 contra 300.000) y gasta algo más en reposo, así que la autonomía baja a unos 3,3 años.
6. Pasá al control de motor con PID. Con 8 bits, la flash (125 %), la RAM (300 %) y la CPU (125 %) fallan a la vez. Con el Cortex-M0+ cumple: la carga de CPU es de 50 %, cerca del límite del margen.
7. Elegí el reloj de pulsera con el Cortex-M0+: la flash queda ajustada (94 %) y la RAM no cumple (125 %). Un solo recurso alcanza para descartar el chip.

11 · Método de trabajo

Método para dimensionar un sistema

Para decidir si un producto entra en un microcontrolador, o para entender por qué uno existente quedó corto, seguí estos pasos:

1. Listá las funciones y para cada una estimá flash, RAM y tiempo de cálculo. Sumá bibliotecas de terceros (comunicaciones, pantalla, seguridad), que suelen ocupar más que tu propio código.
2. Anotá los plazos de cada evento y el peor caso de ejecución de cada respuesta.
3. Calculá el consumo medio con un perfil de tiempos: cuánto está despierto, cuánto duerme, qué periféricos están encendidos.
4. Sumá el entorno: temperatura, tamaño, normas y vida útil del producto.
5. Aplicá los márgenes y comprobá cada recurso contra la capacidad del chip candidato.
6. Mirá el costo total, con el volumen de fabricación y el NRE.
7. Descartá y elegí: quedate con el chip más chico que cumple con margen y anotá qué requisito lo eligió.
8. Medí durante el desarrollo: tamaño en cada compilación, corriente con un instrumento, tiempos con un analizador lógico. Corregí el presupuesto con datos reales.

El último paso es el que más se olvida. Una estimación del primer día sirve para elegir el chip; la medición continua sirve para no llegar al final con un firmware que no entra. Una buena práctica es registrar el tamaño del firmware en cada versión y vigilar que no crezca de golpe.

12 · Comprensión

Confusiones frecuentes

13 · Práctica guiada

Predecí antes de comprobar

1. Funcional o no funcional

Clasificá cada requisito: (a) «lee la temperatura cada 10 s»; (b) «la lectura tiene una precisión de ±0,5 °C»; (c) «envía los datos por Wi-Fi»; (d) «la batería dura al menos 2 años»; (e) «se reinicia solo si se cuelga».

2. Autonomía de una pila

Un dispositivo con pila de 1000 mAh consume 5 mA cuando está activo y 5 µA dormido. Trabaja el 2 % del tiempo. ¿Cuánta corriente media consume y cuánto dura?

3. ¿Entra en la RAM?

Un programa guarda 200 registros de 12 bytes en una tabla en RAM. El chip tiene 2 KB de RAM. ¿Entra? ¿Qué podrías hacer?

4. Carga del procesador

Una tarea ocupa 12.000 ciclos de reloj y se ejecuta cada 1 ms. El procesador corre a 16 MHz. ¿Qué carga produce? ¿Es aceptable?

5. Volumen y costo

Un producto tiene 4,50 dólares de materiales y 60.000 de NRE. ¿Cuánto cuesta cada unidad al fabricar 10.000 y al fabricar 1.000.000? Un chip alternativo ahorra 0,20 dólares por unidad pero agrega 30.000 dólares de ingeniería: ¿conviene en cada caso?

6. Grado de temperatura

Un sensor se instala a la intemperie en una zona donde la temperatura varía de −20 °C a 45 °C. ¿Alcanza un componente de grado comercial (0 a 70 °C)?

14 · Síntesis

Ideas para recordar

¿Listo para el tema 3?

Antes de avanzar, elegí un producto de tu casa y escribí tres requisitos no funcionales medibles; calculá qué porcentaje de CPU ocupa una tarea de 3000 ciclos cada 1 ms a 8 MHz; y explicá por qué elegir el chip más barato puede salir caro en un volumen bajo. Si podés justificar las tres respuestas, ya pensás en términos de presupuesto.

En el próximo tema abrimos el chip y estudiamos la arquitectura de hardware: el microcontrolador, sus periféricos, la memoria, los buses y los componentes que lo rodean, para entender de dónde salen los números que usamos hoy.