Un reloj de 2020, un firmware completo, tres días
Un T-Watch de 2020 dormía en un rincón: desarrollar para él exigía demasiado esfuerzo. En tres días, con un agente, recibió un firmware escrito desde cero y publicado con licencia MIT.
Compré un LilyGO T-Watch 2020 hace seis años, porque era barato e ideal para probar y trastear. Desarrollar para él, en cambio, exigía una inversión real: C/C++, un framework que aprender, nociones de sistemas embebidos. Acabó en un rincón, junto a otros side projects sin terminar.
Con la IA, todos esos frenos desaparecen: en pocos minutos, tenía un firmware completo, escrito desde cero. Sin la IA, no lo habría sacado del cajón: crear cualquier cosa en él exigía demasiado esfuerzo.
¿Qué aparatos duermen en tu casa? Imagina lo que podrías hacer con ellos, en un tiempo récord.
La entrada sobre los cuatro días ya contó el primer flasheo. Aquí me quedo con el reloj.
# Lo que quería
Una esfera de cronógrafo de aviación y displays de 7 segmentos al estilo de los «circuitos temporales». Luego el tiempo, los autobuses y las notificaciones del iPhone. La lista completa de aplicaciones está en el README del repositorio.
Mi método se resume en dos gestos. Expongo sencillamente las funciones que quiero. Luego pido enseguida una primera versión de principio a fin, para tener un ciclo de retroalimentación corto. El resultado se vuelve convincente muy rápido.
Dirigí el desarrollo en lenguaje natural, expresando intenciones. Leyendo el código generado, también aprendí mucho, tanto sobre el lenguaje como sobre los frameworks y los conceptos de sistemas embebidos. ¡El alcance pedagógico es inmenso!
# El comienzo
Primer commit a las 3:22. El prompt de misión imponía dos reglas: hacer una copia de seguridad de los 16 MB de flash originales antes de cualquier escritura, y no tocar nunca los eFuses ni la tensión del núcleo.
La copia de seguridad estuvo a punto de fallar. A 921 600 baudios, el puerto USB desapareció en plena lectura. El agente volvió a empezar a 230 400 baudios, en bloques de 1 MB verificados uno a uno, porque por encima el cable introducía errores. A las 3:46, la copia completa estaba verificada y su hash SHA-256 registrado. A las 3:48, primer flasheo verificado en el reloj.
Tuve un poco de miedo de brickear el reloj. No sabía de dónde venía el fallo; probablemente del cable. El agente se encargó de todo, hasta probar un flasheo lento y fraccionado para lidiar con ese cable defectuoso (!). Sus preguntas y sus métodos eran pertinentes y precisos, y eso era lo que me daba confianza.
A las 4:09, la esfera de aviador aparecía en pantalla, con un segundero a 8 Hz.
La esfera de aviador, capturada en el reloj real por el puerto serie. Captura ya publicada en la entrada anterior.
# El momento en que se rompió
Conectado por USB, el reloj aguantaba. Con batería, se colgaba sistemáticamente al cabo de unos segundos. Durante la mañana, temía que estuviera brickeado, y le metía prisa al agente para que fuera rápido antes del siguiente cuelgue. Tuve que apagarlo y encenderlo tres veces.
Había dos causas, encontradas una tras otra. Primero, el watchdog del procesador seguía armado durante el sueño ligero. Ahora se suspende antes de entrar en reposo y se rearma al despertar. Después, una pulsación del botón congelaba el reloj. La línea de interrupción del chip de alimentación se queda en nivel bajo mientras no se lee, y la interrupción se volvía a disparar sin fin. Las interrupciones GPIO ahora se desactivan durante el sueño, y comprobé que el reloj aguantaba muy bien.
# Una decisión: dejar de depender del cable
Los cortes del USB volvían durante los flasheos. Había dos opciones: esperar a que volviera el puerto, o hacer que el cable fuera accesorio. El agente propuso el «modo taller»: cuando el reloj está alimentado por USB y el Wi-Fi está configurado, se queda conectado, acepta actualizaciones por Wi-Fi (OTA) y expone una consola TCP. Un Wi-Fi encendido todo el tiempo es normalmente un antipatrón. Enchufado a la corriente, la batería no está en juego, y la opción se puede desactivar.
Como el cable fallaba, el agente pasó por su cuenta a las actualizaciones por Wi-Fi (OTA). ¡Magia! Más tarde, los cortes aparecieron también mientras el procesador estaba en su cargador de arranque en ROM: así que el problema es de hardware, no de software. Después llegó un modo seguro: tras tres cuelgues seguidos en el primer minuto, el Bluetooth no arranca, para poder reparar siempre el reloj a distancia.
El reloj real en la pantalla de diagnóstico, la primera pantalla flasheada. Foto ya publicada en la entrada anterior.
# Dónde estoy
El problema del cable (B2 en BLOCKERS.md) sigue abierto: la conexión micro-USB sigue siendo frágil. El doble toque que despierta la pantalla sigue siendo algo aleatorio, pero funciona. El gesto de muñeca para despertar el reloj todavía hay que ajustarlo. La autonomía durante un día entero aún no se ha medido.
Lo que más me impresionó fue la rapidez con la que el agente flasheó el reloj por su cuenta y me mostró resultados concretos. Tengo muchas ganas de probarlo en otros aparatos. De hecho, pronto voy a volver a sacar mis micro:bits: ¡tengo una idea de proyecto!