Por qué Rust en el embebido: seguridad sin red debajo

En un servidor, un puntero salvaje tiene dos redes debajo: la unidad de gestión de memoria (MMU), que lo convierte en un fallo de página y mata el proceso limpiamente, y el recolector de basura, que impide que llegues a tenerlo. En un microcontrolador las dos desaparecen. No hay sistema operativo que aísle procesos, a menudo no hay MMU —un Cortex-M carece de ella—, y casi nunca sobra la RAM ni la tolerancia a pausas que un GC exige. El espacio de direcciones es plano: la flash, la RAM y cada periférico conviven en un único mapa, de modo que una escritura descarriada no revienta con una traza de pila, sino que reconfigura en silencio el registro que gobierna un motor. Aquí la seguridad de memoria no es una comodidad: es la línea que separa un bug que atrapas de un bug que mueve un actuador físico. Por eso la tercera puerta de Rust —garantía en compilación, coste cero en ejecución— no es una opción más en el embebido: es la única que cabe.

Lo que desaparece bajo tus pies

Recuerda el dilema fundacional: control frente a seguridad, con C y C++ en un bando y los lenguajes con GC en el otro. En un PC, ese dilema tiene dos analgésicos. La MMU traduce direcciones virtuales y dispara un fallo de página cuando tocas memoria que no es tuya; el sistema operativo lo convierte en un SIGSEGV que mata solo tu proceso y deja el resto del sistema intacto. Y si prefieres no jugar con fuego, un recolector de basura te quita el volante entero.

En un Cortex-M, ninguna de las dos existe. No hay MMU —como mucho una MPU opcional, mucho más burda—, así que las direcciones que manejas son físicas y desnudas. La flash arranca en 0x0800_0000, la RAM en 0x2000_0000, y los periféricos en 0x4000_0000: todos en el mismo mapa plano. Una escritura fuera de rango no provoca un fallo de página, porque no hay quien lo levante; simplemente aterriza donde apunte. Si el puntero descarriado cae sobre 0x4002_0000, no has corrompido un dato: has reconfigurado un puerto GPIO, un temporizador o un canal de DMA. El programa no se cae —sigue corriendo—, pero el motor gira cuando no debía.

flowchart TD
BUG[Escritura por un puntero salvaje] --> Q[Hay MMU y SO]
Q -->|Si, en un PC| PC[Fallo de pagina y SIGSEGV]
PC --> LIMPIO[El proceso muere limpio y aislado]
Q -->|No, en un MCU| MCU[Aterriza en el mapa plano]
MCU --> REG[Reconfigura un registro de periferico]
REG --> FISICO[El actuador fisico obedece al error]
style LIMPIO fill:#a6e3a1,color:#11111b
style FISICO fill:#f38ba8,color:#11111b

El recolector de basura es, además, doblemente imposible aquí. Muchos MCU tienen entre 8 y 256 KB de RAM: no hay espacio para un heap gestionado que suele pedir de dos a cinco veces la memoria del dato vivo. Y un bucle de control de motor a 20 kHz no tolera una pausa de recolección de un milisegundo. A menudo ni siquiera hay heap: el binario reserva toda su memoria de forma estática. Las dos escapatorias tradicionales del dilema —“que la MMU lo mate” y “que el GC lo evite”— quedan amputadas. La garantía tiene que estar demostrada antes de arrancar.

El hardware como recurso con dueño

Un periférico es, físicamente, un puñado de registros en direcciones fijas. En C se exponen como macros globales: cualquier función, desde cualquier módulo, puede escribir en GPIOA->ODR. No hay noción de propiedad, así que dos rutinas que configuren el mismo puerto compiten sin que nada lo impida: una carrera de datos, pero sobre silicio.

Rust aplica su modelo de propiedad al hardware. El PAC —la capa de acceso a registros que verás en la lección siguiente— expone el conjunto de periféricos como un singleton: una función take() que devuelve Some la primera vez y None en cada llamada posterior. Poseer ese valor es poseer el hardware; para repartirlo, mueves subperiféricos fuera de él. El borrow checker garantiza entonces algo que en C no tiene ni nombre: que no existan dos partes del programa con un handle mutable al mismo periférico a la vez.

use stm32f4xx_hal::pac;

let dp = pac::Peripherals::take().unwrap(); // Some la 1a vez
// let otro = pac::Peripherals::take();     // devolveria None: ya no eres el unico
let gpioa = dp.GPIOA; // mueves el puerto fuera: ahora su dueno es esta variable

Es el mismo Send, el mismo Sync, el mismo ownership que ya dominas, aplicados a un recurso que no es memoria del heap sino un bloque de registros. La exclusividad deja de ser una convención que el equipo promete respetar y pasa a ser un invariante que el compilador impone.

El tipo que recuerda cómo está configurado el pin

El segundo regalo del sistema de tipos es el typestate, la misma técnica con que blindaste tu núcleo unsafe haciendo irrepresentables los estados ilegales, ahora aplicada al estado de un pin. Un GPIO puede estar como entrada, como salida o en función alternativa. En C es un entero, y nada te impide leer un pin configurado como salida o poner alto uno que es entrada: registros incoherentes que el hardware obedece sin rechistar.

En un HAL de Rust, la configuración vive en el tipo. Configurar el pin lo consume y devuelve otro tipo distinto:

let gpioc = dp.GPIOC.split();
let mut led = gpioc.pc13.into_push_pull_output(); // tipo: Output push-pull
led.set_high(); // existe para una salida

// let x = led.is_high();  // NO COMPILA: is_high no existe para un pin de salida

Un pin de entrada tiene tipo Input y un pin de salida Output (con parámetros como PushPull u OpenDrain); set_high solo existe para el segundo. Llamar a la operación equivocada no es un error en ejecución que descubres con el osciloscopio: es un método que sencillamente no está. Y todo ello a coste cero: el parámetro de tipo es un marcador fantasma, borrado en compilación, de modo que el código máquina generado es idéntico a la escritura cruda del registro que habrías tecleado en C. Pagas la seguridad en el compilador y no un ciclo en el chip.