Arquitectura

El orden que nada puede subir

Veintidós módulos en un único orden, el consumidor primero. Un módulo incluye sus propias cabeceras y las de los módulos que tiene debajo; un include que apunte hacia arriba no pasa la comprobación, en el gancho del commit y otra vez en integración continua.

El remedio para un include hacia arriba nunca es una excepción. Es bajar la cabecera, o invertir la llamada con una interfaz que el módulo de abajo declare, que es como el panel de administración llega a la aplicación en marcha sin que la aplicación sepa que existe un panel. Hay un mecanismo para fijar excepciones, una por una. Está vacío, y lo importante es precisamente que esté vacío: en el firmware no hay dos módulos que dependan el uno del otro.

Los includes se escriben desde la raíz del árbol de fuentes, así que una ruta relativa que se salga de su propio directorio no pasa la misma comprobación. Dentro de un módulo la comprobación va más allá y pone vallas entre unos grupos de ficheros y otros, y rechaza un ciclo entre cabeceras. El dibujo de la sección siguiente se genera con esas mismas líneas de include, y la comprobación falla mientras la copia que se guarda en el repositorio esté desfasada.

El grafo

El grafo de módulos se genera a partir de los propios includes en vez de dibujarse a mano, y eso es lo que evita que el diagrama y el código que describe se contradigan: la herramienta que lo dibuja es la que impone el orden.

Dos núcleos, y qué no se permite en cada uno

El chip tiene dos núcleos, y el reparto entre ellos es una regla y no una tendencia.

• Núcleo 1: lo que miras

  El bucle principal, la máquina de estados, la pantalla y los botones. No se bloquea nunca esperando a una radio ni al almacenamiento, porque cada milisegundo que pasa esperando es un milisegundo en que notas lento el dispositivo en la mano.

• Núcleo 0: lo que esperas

  El host de Bluetooth, el Wi-Fi y el servidor web, el sistema de ficheros y la criptografía. Derivar la clave tarda alrededor de segundo y medio: ocurre aquí, con un indicador de progreso dibujado en el otro núcleo, y al reloj más rápido del chip, mientras que todas las pantallas funcionan al más lento.

Una cola o un cerrojo al que cualquiera de dos tareas pueda llegar primero se construye antes de que exista la tarea que lo consume, o dentro de una llamada que ocurre una sola vez. Mirar si es nulo y crearlo en ese caso es el fallo que parece correcto: los dos núcleos pasan esa comprobación, los dos construyen uno, y a uno de ellos no lo espera nadie.

Un árbol, nueve placas

Una placa es una configuración, no una copia del firmware.

Cada placa tiene un directorio con su mapa de pines, su pantalla, su controlador de alimentación, su tabla de particiones y sus propias cifras, entre ellas la estimación de sueño que imprime la página de mediciones. El firmware se compila sobre ESP-IDF 6.0.3 sin ningún core de Arduino dentro, en C++26, y con cada aviso del compilador tratado como un error. Un guardián lee las nueve placas y falla ante una incoherencia entre ellas: treinta y tantos invariantes, entre ellos que cada compilación lleve exactamente un factor de trabajo para la derivación de clave, y que la consola serie no pueda compilarse dentro de una imagen de producción.

Cada placa tiene hasta cuatro compilaciones: una abierta de desarrollo, una de depuración que no se publica nunca, una abierta de producción y una endurecida que en su primer arranque quema fusibles de un solo uso, algo que no se puede deshacer. Tres placas no tienen compilación endurecida, porque 4 MB de flash no dan para dos ranuras de actualización y un gestor de arranque firmado.