RTIC: concurrencia por interrupciones con garantías en compilación

En un microcontrolador la concurrencia no llega por hilos: llega por interrupciones. Un temporizador vence, un pin cambia, un byte entra por el bus, y cada evento desvía la CPU hacia un manejador que corre a mitad de otra cosa. En cuanto dos de esos manejadores tocan el mismo dato, tienes una carrera —la misma que en un servidor, pero sobre registros de hardware y sin un Mutex de la biblioteca estándar a mano—. La respuesta tosca es desactivar todas las interrupciones alrededor de cada acceso, matando la latencia que en tiempo real es sagrada. RTIC —Real-Time Interrupt-driven Concurrency— ofrece la respuesta fina: hace que tus tareas sean manejadores de interrupción, deja que el controlador de interrupciones del chip las planifique por prioridad, y añade un análisis en compilación que demuestra, antes de flashear, que no hay carreras de datos ni interbloqueos posibles. Es la concurrencia sin miedo de Rust descendiendo hasta el mismísimo controlador de interrupciones.

El problema: interrupciones que comparten estado

Imagina un contador que una interrupción de botón incrementa y que el bucle principal lee. En bare-metal ingenuo, ese contador es una variable global static mut, y tocarla desde dos contextos que se interrumpen entre sí es comportamiento indefinido: la lectura puede capturar el valor a medio actualizar. Es la carrera de datos de siempre, ahora entre un manejador y el hilo de fondo.

El remedio clásico de C es la sección crítica: desactivar todas las interrupciones mientras tocas el dato. Funciona, pero es un mazazo. Al silenciar el sistema entero para proteger un contador, retrasas también la interrupción crítica del control de motor que no tenía nada que ver. En tiempo real, donde lo que importa es la latencia del peor caso, apagar todo indiscriminadamente es inaceptable. Necesitas exclusión selectiva: bloquear solo a quien podría tocar ese recurso, y a nadie más.

El modelo de RTIC: el hardware es el planificador

RTIC parte de una idea radical: no escribas un planificador en software: usa el que ya llevas en el chip. Todo Cortex-M incluye un NVIC (Nested Vectored Interrupt Controller) que gestiona interrupciones con prioridades y preempción anidada por hardware. RTIC hace que cada tarea sea un manejador enganchado a un vector, le asigna una prioridad, y deja que el NVIC haga lo que sabe hacer: cuando llega un evento de mayor prioridad, interrumpe al de menor; cuando termina, reanuda. Sin bucle de planificación, sin cambios de contexto en software, sin kernel.

Todo se declara dentro del macro #[app], que en compilación teje el arranque, los vectores y el análisis de recursos:

#![no_std]
#![no_main]
use panic_halt as _;

#[rtic::app(device = stm32f4xx_hal::pac, dispatchers = [SPI1])]
mod app {
    use stm32f4xx_hal::{prelude::*, gpio::{Output, gpioc::PC13}};

    #[shared]
    struct Shared {
        pulsaciones: u32,
    }

    #[local]
    struct Local {
        led: PC13<Output>,
    }

    #[init]
    fn init(cx: init::Context) -> (Shared, Local) {
        // configurar relojes, GPIO y habilitar la interrupcion EXTI0 del boton
        // ... (omitido)
        (Shared { pulsaciones: 0 }, Local { led })
    }
}

#[init] corre una sola vez, con las interrupciones desactivadas, y devuelve el estado inicial repartido en dos structs. Esa partición es el primer acto de seguridad: #[local] son recursos que pertenecen a una única tarea —nadie más los ve, así que no necesitan protección— y #[shared] son los que varias tareas se disputan y que, por tanto, exigen un candado.

Recursos, lock y el techo de prioridad

Añade dos tareas. Una tarea hardware, atada con binds a la interrupción del botón, se dispara sola cuando el pin cambia; una #[idle] de fondo, la de menor prioridad, lee el contador cuando no hay nada más que hacer:

    // Tarea hardware: la dispara la interrupcion EXTI0. Prioridad 2.
    #[task(binds = EXTI0, local = [led], shared = [pulsaciones], priority = 2)]
    fn boton(mut cx: boton::Context) {
        cx.local.led.toggle();                    // recurso local: sin candado
        cx.shared.pulsaciones.lock(|n| *n += 1);  // recurso compartido: bajo candado
    }

    // Fondo de baja prioridad: lee el contador compartido.
    #[idle(shared = [pulsaciones])]
    fn idle(mut cx: idle::Context) -> ! {
        loop {
            let actual = cx.shared.pulsaciones.lock(|n| *n);
            let _ = actual;
        }
    }

Fíjate en la asimetría. led es #[local] de boton: se accede directo, cx.local.led, sin ceremonia, porque el sistema de tipos ya garantiza que ninguna otra tarea lo posee. pulsaciones es #[shared]: solo se toca dentro de lock(|n| ...), y fuera de ese cierre es inaccesible. El compilador te obliga a bloquear antes de tocar lo compartido; olvidarlo no es un bug latente, es un error de tipos.

Y aquí está la joya. Ese lock no es un mutex que pueda bloquear ni dormir. Implementa el protocolo del techo de prioridad (SRP, Stack Resource Policy): al bloquear un recurso, RTIC eleva momentáneamente la prioridad del núcleo hasta el techo de ese recurso —la mayor prioridad de todas las tareas que lo usan—. Por enmascaramiento del hardware, eso impide que cualquier tarea capaz de tocar ese dato preempte durante el acceso, mientras deja correr libremente a las que no lo comparten. La exclusión es selectiva, no global. Y el coste es ridículo: escribir un registro de prioridad (BASEPRI), no adquirir un candado con espera.

flowchart TD
IRQ[Llega una interrupcion] --> NVIC[El NVIC ordena por prioridad]
NVIC --> PRE[La de mayor prioridad preempta a la menor]
PRE --> TASK[Corre la tarea vinculada al vector]
TASK --> LOCK[lock sobre un recurso compartido]
LOCK --> CEIL[Sube la prioridad al techo del recurso]
CEIL --> EXCL[Nadie que comparta el recurso puede preemptar]
EXCL --> DONE[Al salir del lock baja la prioridad]
style CEIL fill:#89b4fa,color:#11111b
style EXCL fill:#a6e3a1,color:#11111b