Módulo 0.3

El problema de la complejidad

¿Por qué necesitamos un RTOS?

Santi Scagliusi, PhD

Comenzar arrow_downward
loop
Bare-metal
El bucle infinito
schedule
RTOS
Multitarea real
air
Zephyr
RTOS moderno
compare
Comparación
Visualización

El problema del bare-metal

Cuando programas sin sistema operativo, todo es secuencial. Una tarea bloquea a todas las demás.

sync

Super Loop

Todo el código en un único bucle while(1). Las tareas se ejecutan una tras otra, siempre en el mismo orden.

hourglass_top

Bloqueos

Si una tarea tarda mucho (leer sensor, esperar comunicación), todas las demás quedan bloqueadas.

priority_high

Sin prioridades

No puedes dar más importancia a tareas críticas. Un LED parpadeando tiene la misma prioridad que una alarma.

timer_off

Timing impredecible

El tiempo de respuesta depende de que estén haciendo las otras tareas. Imposible garantizar latencias.

error Problema visual

t=0ms
Tarea 1 (10ms)
t=10ms
Tarea 2 (5ms)
t=15ms
Tarea 3 - BLOQUEADA (500ms!)
warning Consecuencia

Tarea 1 no puede ejecutarse de nuevo hasta t=515ms. Si era crítica (alarma, comunicación), el sistema falla.

El super loop típico

Este patrón es común en sistemas embedded simples, pero escala muy mal.

main.c - Bare-metal
int main(void) {
// Inicialización
init_hardware();
init_peripherals();
while(1) {
read_sensors(); // 10ms
process_data(); // 5ms
send_bluetooth(); // 500ms!
update_display(); // 20ms
check_buttons(); // 1ms
}
return 0;
}

dangerous Problemas de este código

  • close Tiempo de ciclo: 536ms mínimo por iteración. Los botones solo se leen cada medio segundo.
  • close Bloqueo BLE: Mientras se envia por Bluetooth, todo lo demás está parado.
  • close Sin prioridades: check_buttons() es tan importante como send_bluetooth().
  • close Difícil de escalar: Agregar una nueva tarea afecta a todas las demás.

lightbulb La solución

Necesitamos un mecanismo que permita ejecutar múltiples tareas de forma "simultánea", dando prioridad a las más importantes y sin que unas bloqueen a otras.

Multitarea con RTOS

Un Sistema Operativo en Tiempo Real (RTOS) permite ejecutar múltiples tareas de forma concurrente.

account_tree

Threads independientes

Cada tarea es un "hilo" separado con su propio contexto y pila. Se ejecutan de forma independiente.

low_priority

Sistema de prioridades

Las tareas críticas tienen mayor prioridad y pueden interrumpir a las menos importantes.

schedule

Scheduler inteligente

El kernel decide qué tarea ejecutar en cada momento, optimizando el uso de la CPU.

¿Cómo funciona?

sensors
Thread 1
Sensores
Alta
bluetooth
Thread 2
BLE
Media
arrow_forward
hub
Scheduler
RTOS Kernel

El scheduler reparte el tiempo de CPU entre los threads según sus prioridades

swap_horiz

Preemptivo

El scheduler interrumpe al thread actual si aparece uno de mayor prioridad. El thread no decide cuándo ceder la CPU.

Thread A (prio 5) ejecutando...
→ Llega Thread B (prio 2) ← ¡preemptado!
Thread B toma la CPU inmediatamente
front_hand

Cooperativo

El thread cede voluntariamente la CPU (con k_yield() o k_sleep()). Nadie lo puede interrumpir.

Thread A (cooperativo) ejecutando...
→ Llega Thread B, pero espera
Thread A llama k_yield() → ahora B ejecuta
lightbulb
Zephyr soporta ambos: Threads con prioridad negativa son cooperativos (no interrumpibles). Threads con prioridad ≥ 0 son preemptivos. Esto se verá en detalle en la Parte 1.

Bare-metal (Super Loop)

Ejecución secuencial: cada tarea bloquea a las demás.

loop

Bare-metal (Super Loop)

Ejecución secuencial
Línea de tiempo (0-1000ms)
T1
T2
BLE (bloqueado)
T3
T1
0ms 250ms 500ms 750ms 1000ms
536ms
Tiempo de respuesta
11%
Uso efectivo CPU

Problema: Durante los 500ms de BLE, ninguna otra tarea puede ejecutarse. El sistema está "muerto" para el usuario.

RTOS (Multitarea)

Ejecución concurrente: todas las tareas avanzan en paralelo.

schedule

RTOS (Multitarea)

Ejecución concurrente
Threads (0-1000ms)
Sensores
T1
T1
T1
T1
T1
T1
T1
T1
T1
T1
Display
T2
T2
T2
T2
T2
BLE
BLE
BLE
BLE
BLE
BLE
BLE
BLE
BLE
BLE
BLE
0ms 250ms 500ms 750ms 1000ms
100ms
Tiempo de respuesta
85%
Uso efectivo CPU

Ventaja: BLE se ejecuta en segundo plano mientras sensores y display responden cada 100ms. El usuario percibe el sistema fluido.

¿Qué es Zephyr?

Zephyr es un RTOS moderno, open source, soportado por la Linux Foundation y usado por Nordic Semiconductor.

verified

Open Source

Licencia Apache 2.0

Codigo completamente abierto. Puedes estudiarlo, modificarlo y usarlo en productos comerciales sin restricciones.

groups

Linux Foundation

Proyecto de nivel platinum

Respaldado por Intel, Nordic, NXP, Texas Instruments y otras grandes empresas. Desarrollo activo y soporte a largo plazo.

developer_board

Soportado por Nordic

nRF Connect SDK

Nordic usa Zephyr como base de su SDK. Todos los ejemplos y librerias están diseñados para funcionar con el.

bluetooth BLE Stack
wifi WiFi/Thread

Arquitectura de Zephyr

apps
Tu aplicación
Threads de usuario
extension
Subsistemas
BLE, WiFi, USB, FS
hub
Kernel
Scheduler, IPC, Sync
memory
HAL / Drivers
Abstracción hardware

Ventajas de usar un RTOS

Aunque añadir un RTOS aumenta la complejidad inicial, las ventajas superan los inconvenientes.

layers

Abstracción del hardware

Zephyr proporciona APIs unificadas para GPIO, I2C, SPI, UART, etc. Escribes código una vez y funciona en diferentes microcontroladores.

swap_horiz

Portabilidad

Tu aplicación puede migrar entre Nordic, STM32, ESP32 u otros con cambios mínimos. No estás atado a un fabricante.

build

Herramientas profesionales

Sistema de build CMake, DeviceTree para configuración, Kconfig para opciones. Herramientas de debug y profiling incluidas.

group

Comunidad activa

Miles de desarrolladores contribuyendo. Documentación extensa, foros activos, ejemplos para casi cualquier caso de uso.

security

Seguridad integrada

Soporte para TrustZone, secure boot, criptografía por hardware. Certificaciones de seguridad industriales.

trending_up

Escalabilidad

Desde microcontroladores de 8KB hasta sistemas complejos con WiFi, BLE y más. Añadir funcionalidad no rompe lo existente.

Resumen: ¿Cuando usar cada enfoque?

Bare-metal es suficiente cuando:

  • check Aplicación muy simple (1-2 tareas)
  • check No hay requisitos de tiempo real estrictos
  • check Memoria extremadamente limitada (<32KB)

Usa RTOS cuando:

  • check Múltiples tareas con diferentes prioridades
  • check Comunicaciones (BLE, WiFi, USB)
  • check Necesitas garantías de tiempo de respuesta
check_circle

Lo que aprendiste hoy

Concepto 1

El problema del super loop

Bare-metal ejecuta tareas secuencialmente. Una tarea lenta bloquea a todas las demás.

Concepto 2

RTOS y multitarea

Un RTOS permite ejecutar múltiples threads con prioridades. El scheduler reparte el tiempo de CPU.

Concepto 3

Zephyr RTOS

Zephyr es un RTOS moderno, open source, soportado por Nordic y la Linux Foundation.

tips_and_updates

"Un RTOS no hace tu código más rápido, pero sí más predecible"

La multitarea y las prioridades garantizan que las tareas críticas siempre respondan a tiempo.

Siguiente: Capas de abstracción

Ahora que entiendes por qué necesitamos un RTOS, vamos a ver cómo se organizan las capas de abstracción en firmware moderno: desde el hardware hasta tu aplicación.

Continuar al Módulo 0.4 arrow_forward