Qué es un sistema embebido

01 · Punto de partida

Computadoras que no parecen computadoras

Pensá en todo lo que usaste hoy desde que te levantaste: el despertador, la cafetera, el microondas, el semáforo que cruzaste, el molinete del transporte, el auto o la bicicleta eléctrica, el control del aire acondicionado. En cada uno hay un chip que ejecuta un programa. Una casa común tiene decenas de procesadores y, con suerte, una o dos computadoras «de verdad»; un auto moderno supera con facilidad los cien procesadores repartidos en sus módulos de control.

En los cursos anteriores aprendiste a programar un microcontrolador, a leer sensores, a mover actuadores y a hacer que dos dispositivos se comuniquen. Ahora damos el paso que falta: pasar de hacer que algo funcione sobre la mesa a diseñar el software de un producto que se fabrica, se instala y debe seguir andando años después, sin supervisión y con recursos muy ajustados.

Este curso recorre todo lo que rodea al código de un dispositivo así: cómo arranca, cómo reacciona a tiempo, cómo ordena su lógica, cómo cuida su memoria y su batería, cómo se protege de sus propias fallas y cómo se actualiza. Este primer tema arma el mapa conceptual común.

02 · Definición

Definición de sistema embebido

Un sistema embebido (o empotrado, o incrustado) es un sistema de cómputo diseñado para cumplir una función específica y que forma parte de un producto o sistema mayor. El procesador está «embebido» dentro del equipo: el usuario usa un lavarropas, no una computadora que lava.

De esa definición se desprenden cinco rasgos que reaparecen en todo el curso:

• Función dedicada. Hace una tarea, o un conjunto pequeño y fijo de tareas, y el programa se escribe a la medida de esa tarea.
• Interacción con el mundo físico. Lee sensores y gobierna actuadores; su entrada y su salida son magnitudes reales (temperatura, posición, tensión) y no solo archivos o pantallas.
• Restricciones de recursos. Memoria, velocidad, energía, tamaño y costo están limitados por el producto, y casi siempre al límite.
• Exigencias de tiempo. Muchas respuestas tienen un plazo: frenar, abrir una válvula o apagar un motor tarde no es «lento», es incorrecto.
• Autonomía y confiabilidad. Arranca solo, trabaja sin operador y debe recuperarse sola de las fallas.

Notá que la definición habla de la función y no del chip. Un sistema embebido puede usar un microcontrolador de 8 bits o un procesador de varios núcleos con Linux; lo que lo define es su papel dentro de un producto. Por eso una placa de desarrollo sobre tu escritorio es, en sentido estricto, una herramienta de aprendizaje, y se vuelve un sistema embebido cuando queda dentro de un equipo cumpliendo su tarea.

El firmware es el programa que reside de forma permanente en la memoria del dispositivo y lo hace funcionar. Se llama así porque queda «a medio camino» entre el hardware (fijo) y el software (que se cambia con facilidad). En el tema 7 estudiamos qué contiene y cómo se genera.

03 · Contraste

Un sistema embebido no es una PC

Si venís de programar aplicaciones, la manera más rápida de entender el terreno es comparar. Una computadora de propósito general está hecha para correr cualquier programa que el usuario instale; un sistema embebido corre un único programa, que ya viene decidido.

Cada fila de la tabla se vuelve un tema del curso. Que no haya sistema operativo explica la inicialización del hardware; las exigencias de tiempo, las interrupciones y los temporizadores; la poca memoria, la gestión de memoria; la batería, el consumo energético; que nadie reinicie el equipo, el watchdog; y que se actualice sin supervisión, la actualización segura del firmware.

04 · Estructura básica

El lazo sentir, decidir y actuar

Casi todos los sistemas embebidos, por distintos que sean, hacen lo mismo en un ciclo continuo: sentir el estado del mundo con sensores, decidir qué hacer con un programa y actuar sobre el mundo con actuadores. Como la acción modifica lo que se vuelve a sentir, el ciclo se cierra: es un lazo de control.

Un ejemplo concreto: el termostato de una heladera. El sensor mide la temperatura interior (sentir). El firmware la compara con la temperatura deseada y decide si el compresor debe arrancar o detenerse (decidir). El relé conecta o corta el compresor (actuar). Al enfriarse el interior, el sensor mide otro valor, y el ciclo continúa. El mismo esquema describe un control de crucero, un cargador de batería, una impresora 3D o el piloto automático de un dron.

Aparecen tres componentes más que no cierran el lazo pero lo vuelven útil. La comunicación lo conecta con otros equipos y con el usuario (el tema que cerró el curso anterior). La memoria guarda el programa, las variables de trabajo y la configuración. La alimentación sostiene todo, y define cuánta energía hay para gastar.

05 · Dónde aparece

Dónde viven los sistemas embebidos

Los sistemas embebidos son la mayor parte de los procesadores que se fabrican, y cada sector pone el acento en una exigencia distinta. Conocerlas ayuda a entender por qué una misma técnica sirve en un caso y es un error en otro.

Una misma pregunta de diseño tiene respuestas distintas. En un juguete de pocos dólares, ahorrar un centavo en memoria es una ganancia enorme y un fallo ocasional se tolera. En una bomba de insulina, el costo de una falla es inaceptable y se paga por componentes, diseño y verificación redundantes. El contexto del producto decide cómo se programa.

06 · Cómo se construye

Del chip de centavos al mini Linux

No todos los sistemas embebidos usan el mismo tipo de procesador. Se agrupan en familias según su capacidad, y elegir una buena familia es una de las primeras decisiones de diseño.

Dos comparaciones ayudan a dimensionar. Una PC tiene millones de veces más RAM que un ATmega328P, pero ese pequeño chip basta para manejar una cerradura, un reloj o un controlador de riego, y cuesta una fracción de lo que cuesta una PC. Y la diferencia no es solo de tamaño: un microcontrolador integra en un solo chip el procesador, la memoria y los periféricos (temporizadores, conversores, puertos de comunicación), mientras que un procesador de aplicaciones suele necesitar memoria y almacenamiento externos.

En este curso trabajamos sobre todo con microcontroladores de 32 bits y con sistemas pequeños con RTOS, que son el centro del mercado, aunque casi todo lo que veamos (interrupciones, memoria, estados, bajo consumo, watchdog) se aplica también a los de 8 bits, y gran parte a Linux embebido.

07 · Cambio de forma de pensar

El programa que nunca termina

Una de las primeras diferencias que notás al programar un sistema embebido es que el programa principal no termina. Una aplicación de consola lee datos, calcula, muestra el resultado y sale. Un firmware, en cambio, arranca cuando se enciende el equipo y trabaja hasta que se apaga: si main() retornara, el procesador quedaría sin nada que ejecutar, o saltaría a código cualquiera.

El esquema más simple, que ya usaste en Arduino con setup() y loop(), se llama superloop (bucle infinito):

int main(void) {
    hardware_init();            // una sola vez: relojes, pines, periféricos

    while (1) {                 // para siempre
        float temp = leer_temperatura();     // sentir
        bool encender = decidir(temp);       // decidir
        escribir_rele(encender);             // actuar
    }
}

La estructura es la del lazo del apartado anterior: una parte de inicialización que corre una vez y un cuerpo que se repite. Esta forma sencilla alcanza para muchos productos, pero tiene límites que vamos a estudiar: no controla cuándo se ejecuta cada paso, la lectura del sensor puede retrasar la acción, y el procesador no descansa nunca, ni siquiera cuando no hay nada para hacer. Los temas 13 a 23 muestran cómo resolver cada uno con interrupciones, temporizadores y planificación.

Otra consecuencia: no podés suponer que un error se resuelve solo. Mirá este fragmento, que en una PC pasaría desapercibido:

while (1) {
    char *mensaje = malloc(32);      // reserva memoria...
    formatear(mensaje, leer_temperatura());
    enviar(mensaje);
    // ...pero nunca la libera: en cada vuelta se pierden 32 bytes
}

Con 2 KB de RAM, 32 bytes por vuelta agotan la memoria en menos de un minuto si el lazo corre varias veces por segundo. Una PC con 16 GB tardaría semanas y el sistema operativo la salvaría cerrando el proceso. En un dispositivo así, el equipo se cuelga en la heladera de alguien. Este tipo de error es la razón por la cual el curso dedica un bloque a la memoria y otro a la confiabilidad.

08 · Analogía con programación

Simular el lazo en Python

Para ver el lazo sentir-decidir-actuar funcionando no necesitamos hardware: basta con simular el mundo físico. El programa modela una habitación que se calienta cuando el calefactor está encendido y pierde calor hacia el exterior. Cada segundo avanza la física; cada PERIODO_S segundos corre el firmware, que lee el «sensor», decide con una banda de histéresis (para no conmutar el relé a cada instante) y actúa sobre el calefactor.

CONSIGNA = 22.0       # temperatura deseada (°C)
HISTERESIS = 0.5      # banda alrededor de la consigna (±°C)
PERIODO_S = 10        # cada cuántos segundos corre el lazo de control
POTENCIA = 0.045      # °C por segundo que sube con el calefactor encendido
PERDIDA = 0.002       # fracción de la diferencia con el exterior que se pierde por segundo
EXTERIOR = 10.0       # temperatura exterior (°C)
DURACION_S = 1800     # 30 minutos


def leer_sensor(temp_real):
    return temp_real              # en un equipo real: leer el conversor analógico-digital


def decidir(temp, calefactor):
    if temp <= CONSIGNA - HISTERESIS:
        return True               # demasiado frío: encender
    if temp >= CONSIGNA + HISTERESIS:
        return False              # demasiado caliente: apagar
    return calefactor             # dentro de la banda: no cambiar nada


temp = 18.0                       # el mundo físico
calefactor = False                # el actuador
conmutaciones = 0
segundos_encendido = 0
ejecuciones = 0
minimo, maximo = 99.0, -99.0

for segundo in range(DURACION_S):
    if segundo % PERIODO_S == 0:              # el firmware corre cada PERIODO_S
        ejecuciones += 1
        nuevo = decidir(leer_sensor(temp), calefactor)
        if nuevo != calefactor:
            conmutaciones += 1
        calefactor = nuevo
    # física: la habitación se calienta y pierde calor
    temp += (POTENCIA if calefactor else 0) - PERDIDA * (temp - EXTERIOR)
    segundos_encendido += calefactor
    if segundo >= DURACION_S - 600:            # últimos 10 minutos
        minimo, maximo = min(minimo, temp), max(maximo, temp)

print(f"temperatura final: {temp:.2f} °C")
print(f"últimos 10 min: de {minimo:.2f} a {maximo:.2f} °C")
print(f"veces que corrió el lazo: {ejecuciones}")
print(f"conmutaciones del relé: {conmutaciones}")
print(f"calefactor encendido: {100 * segundos_encendido / DURACION_S:.0f} % del tiempo")

Resultado con los valores iniciales: la temperatura final es 22,64 °C, en los últimos diez minutos oscila entre 21,31 y 22,66 °C, el lazo corre 180 veces, el relé conmuta 31 veces y el calefactor está encendido el 58 % del tiempo. Probá HISTERESIS = 0: el relé conmuta unas 154 veces, porque cada vuelta cruza la consigna. Probá PERIODO_S = 60: se conmuta menos, pero la temperatura se pasa de la banda (entre 20,4 y 23,2 °C). Y con EXTERIOR = -10 la habitación nunca llega a 22 °C: ningún programa puede pedirle al hardware más de lo que da.

El programa deja ver tres compromisos del diseño embebido: una banda de histéresis más estrecha da un control más fino pero desgasta el relé; un período de muestreo más largo ahorra procesador y energía pero reacciona tarde; y el límite físico del actuador acota lo que el firmware puede lograr. Vamos a volver a esas tensiones en cada bloque del curso.

09 · Exploración interactiva

Un termostato embebido, de extremo a extremo

Este laboratorio ejecuta el mismo modelo del código anterior y dibuja la temperatura durante 30 minutos. Elegí la consigna, la histéresis, cada cuántos segundos corre el lazo y la temperatura exterior, y observá qué pasa con la estabilidad, el desgaste del relé y la carga del procesador. La banda amarilla es la zona de histéresis y la línea punteada, la consigna.

Recorrido guiado

1. Con los valores iniciales, simulá. La temperatura sube hasta la banda y queda oscilando alrededor de 22 °C. Anotá las conmutaciones y el porcentaje de CPU ocupada: es mínimo, el procesador casi todo el tiempo no hace nada.
2. Poné la histéresis en 0 °C. El relé pasa de unas 30 a más de 150 conmutaciones en media hora. Con un relé mecánico de decenas de miles de ciclos de vida, durará pocos meses.
3. Con histéresis 0,5 °C, cambiá el período a 60 segundos. Hay menos conmutaciones, pero la temperatura sale de la banda y oscila más de 2,5 °C: el lazo reacciona tarde.
4. Probá 1 segundo. La temperatura queda casi clavada dentro de la banda, a costa de ejecutar el lazo 1800 veces. Aun así la CPU se ocupa una fracción mínima del tiempo.
5. Con consigna 25 °C y exterior 5 °C, el calefactor trabaja casi siempre; con exterior de -10 °C, nunca llega a la consigna. El hardware limita lo que el firmware puede lograr.
6. Subí la histéresis a 2 °C con período de 10 segundos: pocas conmutaciones, pero la temperatura varía varios grados. Compará con la de 0,5 °C y decidí qué importa más en una heladera y qué en un horno.

10 · Método de trabajo

Cómo analizar un sistema embebido

Frente a un producto nuevo, sea uno propio o uno que debas mantener, recorré estas preguntas en orden. Sirven para entenderlo antes de tocar una línea de código:

1. ¿Cuál es su función? Escribila en una frase. Si necesita dos, quizá son dos sistemas.
2. ¿Qué siente y qué controla? Listá sensores y actuadores, y de qué magnitud física se trata cada uno.
3. ¿Qué plazos tiene? Para cada respuesta, ¿cuánto tiempo hay y qué pasa si se pierde?
4. ¿Con qué recursos cuenta? Memoria de programa, RAM, velocidad, energía disponible y presupuesto de costo.
5. ¿Qué interfaces tiene? Con el usuario y con otros equipos, por qué medios de comunicación.
6. ¿Qué entorno soporta? Temperatura, ruido eléctrico, humedad, vibración.
7. ¿Qué pasa cuando falla? Cuál es el estado seguro y cómo se recupera sin intervención.
8. ¿Cómo se actualiza y se mantiene? Si hay que corregir un error en campo, ¿cómo llega el cambio?

Muchas de estas respuestas se contradicen entre sí (más funciones piden más memoria, más memoria sube el costo, más velocidad sube el consumo) y diseñar es negociar. En el tema 2 formalizamos estas restricciones y en el bloque final las convertimos en requisitos medibles.

11 · Comprensión

Confusiones frecuentes

12 · Práctica guiada

Predecí antes de comprobar

1. ¿Es o no es embebido?

Decidí cuáles de estos son sistemas embebidos y justificá: (a) el controlador de un ascensor; (b) una notebook; (c) un reloj inteligente; (d) un servidor en la nube; (e) la computadora de una máquina de café.

2. Sentir, decidir y actuar

Para un riego automático que riega cuando la tierra está seca, indicá el sensor, la decisión y el actuador.

3. El costo de un chip

Un producto se fabrica en 500.000 unidades. Pasar de un microcontrolador de 1,20 dólares a uno de 0,90 dólares exige reescribir parte del firmware para que entre en menos memoria, con un costo de ingeniería de 40.000 dólares. ¿Conviene?

4. Un lazo sin histéresis

Un termostato sin histéresis enciende y apaga el compresor cada vez que la temperatura cruza la consigna. ¿Qué problemas trae y cómo se resuelven?

5. Memoria que se agota

Un lazo corre 20 veces por segundo y pierde 16 bytes en cada vuelta. La RAM libre es de 4 KB. ¿Cuánto tarda en agotarse?

6. Ordenar prioridades

Ordená de mayor a menor importancia, para el firmware de un marcapasos, estos criterios: (a) bajo costo; (b) confiabilidad; (c) bajo consumo; (d) facilidad de programación.

13 · Síntesis

Ideas para recordar

¿Listo para el tema 2?

Antes de avanzar, definí «sistema embebido» con tus palabras, dibujá de memoria el lazo sentir-decidir-actuar de un producto de tu casa y explicá por qué el programa principal de un firmware no termina. Si podés justificar las tres respuestas, tenés la base del curso.

En el próximo tema estudiamos las restricciones y los requisitos: cuánta memoria, velocidad y energía tiene realmente un sistema embebido, qué significan el costo, el tamaño y el tiempo real, y cómo se traducen en decisiones concretas de diseño.