Un programa bare-metal: no_std, no_main y el LED que parpadea

Todo programa Rust que has escrito hasta ahora se apoyaba, sin que lo vieras, en un runtime: un trozo de código que se ejecuta antes de tu main, monta la pila, procesa los argumentos, prepara el asignador y, al terminar, recoge la mesa. Ese runtime lo prestaba el sistema operativo a través de la biblioteca estándar. En un microcontrolador no hay sistema operativo que lo preste, así que hay que renunciar a él y reconstruir el esqueleto a mano. Tres piezas lo consiguen: #![no_std] amputa todo lo que depende de un SO y deja solo el núcleo del lenguaje; #![no_main] descarta el punto de entrada convencional, que presupone un arranque de C; y el crate cortex-m-rt aporta el verdadero comienzo —el vector de reset, la inicialización de la RAM, la tabla de vectores— y cede el control a tu función #[entry], que no retorna nunca porque en el metal desnudo no existe un “después”. Esta lección construye ese hola mundo: un LED que parpadea, la prueba de vida del embebido.

no_std: quedarse con el lenguaje, soltar el sistema operativo

La biblioteca estándar de Rust se divide, sin que suela notarse, en dos mitades. core es el corazón independiente del sistema: tipos primitivos, Option, Result, iteradores, traits, slice, aritmética. No presupone nada del entorno. std envuelve a core y le añade todo lo que exige un sistema operativo debajo: Vec y String (que necesitan un asignador de heap), hilos, ficheros, red, tiempo del sistema. En un MCU no hay nada de eso, así que arrastrar std sería pedir servicios que no existen.

#![no_std]

Ese atributo en la raíz del crate desconecta std y te deja programando contra core. Sigues teniendo el lenguaje entero —el borrow checker, los traits, los genéricos, los enums, Result— porque todo eso vive en core. Lo que pierdes es la colección con heap y el acceso al SO. Si necesitas asignación dinámica sin SO, existe una vía intermedia: el crate alloc (con Vec y Box) sobre un asignador global que tú proveas. Pero el embebido idiomático prefiere, casi siempre, no tener heap en absoluto y reservarlo todo de forma estática.

no_main y cortex-m-rt: reconstruir el arranque

Un fn main normal no es el primer código que corre: antes se ejecuta un runtime de C (el crt0) que el sistema operativo enlaza, encargado de montar el entorno y luego llamar a tu main. Sin SO, ese runtime no está. Por eso #![no_main] le dice al compilador que no espere la firma de main habitual: el punto de entrada lo definiremos nosotros.

Ahí entra cortex-m-rt, el runtime mínimo para los núcleos Cortex-M. Cuando el chip arranca, la CPU lee el vector de reset —una dirección grabada al principio de la flash— y salta a él. cortex-m-rt pone ahí su rutina de arranque, que hace el trabajo imprescindible antes de que tu código tenga sentido: copia los datos inicializados de la flash a la RAM (la sección .data), pone a cero las variables sin inicializar (la sección .bss), instala la tabla de vectores de interrupción y, solo entonces, invoca la función que hayas marcado con #[entry].

flowchart TD
RESET[La CPU lee el vector de reset] --> RT[cortex-m-rt arranca]
RT --> DATA[Copia .data de la flash a la RAM]
RT --> BSS[Pone a cero la seccion .bss]
DATA --> VT[Instala la tabla de vectores]
BSS --> VT
VT --> ENTRY[Salta a tu funcion con entry]
ENTRY --> LOOP[Bucle infinito, no retorna nunca]
PANIC[panic-halt provee el panic handler obligatorio] -.-> ENTRY
style RESET fill:#fab387,color:#11111b
style ENTRY fill:#89b4fa,color:#11111b
style LOOP fill:#a6e3a1,color:#11111b

De aquí sale una firma que sorprende al recién llegado: la función de entrada devuelve -> !, el tipo never. No es un capricho: en un PC, cuando main retorna, el runtime recoge y devuelve el control al SO. En el metal desnudo no hay SO ni runtime que recoja; no existe un “después de main”. Si tu función terminara, la CPU seguiría ejecutando lo que hubiera en la siguiente dirección de memoria: basura. Por eso el tipo obliga a que nunca acabe, y de ahí el bucle infinito que corona todo programa embebido.

Falta una pieza que std regalaba: el manejador de pánico. Cuando algo entra en pánico, Rust invoca la función marcada con #[panic_handler]; std traía una que imprime y aborta, pero en no_std debes proveerla tú. La forma habitual es importar un crate que la define:

use panic_halt as _;   // aporta un panic_handler que detiene la CPU en un bucle

El as _ es revelador: importas el crate solo por su efecto de borde —registrar el símbolo del manejador—, sin usar ningún nombre suyo. En depuración se prefiere panic-probe, que imprime el mensaje por defmt antes de detenerse.

El LED que parpadea, entero

Con esas piezas, el hola mundo se escribe así. Toma los periféricos, configura el reloj, saca el pin del LED, obtén un temporizador para el retardo y entra en el bucle eterno:

#![no_std]
#![no_main]

use cortex_m_rt::entry;
use panic_halt as _;
use stm32f4xx_hal::{pac, prelude::*};

#[entry]
fn main() -> ! {
    let dp = pac::Peripherals::take().unwrap();

    let rcc = dp.RCC.constrain();
    let clocks = rcc.cfgr.sysclk(84.MHz()).freeze(); // configura y congela relojes

    let gpioc = dp.GPIOC.split();
    let mut led = gpioc.pc13.into_push_pull_output();
    let mut delay = dp.TIM2.delay_ms(&clocks);

    loop {
        led.set_high();
        delay.delay_ms(500_u32);
        led.set_low();
        delay.delay_ms(500_u32);
    }
}

El proyecto necesita tres ficheros más. Las dependencias en Cargo.toml:

[dependencies]
cortex-m = "0.7"
cortex-m-rt = "0.7"
panic-halt = "1"
stm32f4xx-hal = { version = "0.22", features = ["stm32f411"] }

La orden de compilación cruzada y el flasheador en .cargo/config.toml, que fija el target del núcleo (aquí un Cortex-M4F con FPU) y delega la ejecución a probe-rs:

[build]
target = "thumbv7em-none-eabihf"

[target.thumbv7em-none-eabihf]
runner = "probe-rs run --chip STM32F411CEUx"

Y el mapa de memoria en memory.x, que cortex-m-rt usa para colocar las secciones donde el silicio las espera:

MEMORY
{
  FLASH : ORIGIN = 0x08000000, LENGTH = 512K
  RAM   : ORIGIN = 0x20000000, LENGTH = 128K
}

Con todo en su sitio, cargo run --release compila para el target ARM, y probe-rs graba el binario en la flash por el depurador de la placa y lo ejecuta. Si añades defmt, sus mensajes de log llegan por el mismo cable, sin necesidad de un puerto serie aparte. El LED parpadea: tienes vida en el metal.