Programación de firmware desde el navegador, sin instalador

Un cliente compra una placa, la conecta a una laptop y se le dice que descargue una herramienta de programación antes de que pase nada. La configuración puede atascarse justo ahí: la herramienta necesita un controlador, instalarlo requiere derechos de administrador, y TI lo tiene bloqueado. La misma fricción aparece en una línea de producción, donde un operador de pruebas necesita un entorno de Python y una versión compatible de esptool instalados en cada estación. Una página de configuración en el navegador puede eliminar algunos de esos pasos, siempre que el hardware y el sistema operativo soporten la conexión.

Qué te dan realmente Web Serial y WebUSB

Ambas son APIs del navegador que permiten a una página web comunicarse con hardware compatible sin una aplicación de programación aparte. No eliminan los controladores del sistema operativo ni las reglas de acceso a dispositivos. Web Serial lee y escribe un puerto serial del sistema operativo, a menudo expuesto por un puente USB-UART. WebUSB accede a una interfaz USB disponible, lo que permite a una página implementar el protocolo DFU o de sonda de depuración del dispositivo. Las páginas en producción necesitan HTTPS. Una primera conexión requiere el permiso del usuario mediante un selector de dispositivos; los puertos seriales autorizados previamente se pueden recuperar con getPorts(). Construye una acción clara de Conectar y un flujo de reconexión, en lugar de suponer un acceso irrestricto o un nuevo aviso de permiso para cada operación. La guía de Web Serial de Chrome explica esa distinción.

Para un destino ESP32 o ESP8266, esto está maduro. El bootloader en ROM de Espressif habla un protocolo bien documentado sobre la misma UART que se usa para la salida de consola, y esptool tiene un port en JavaScript que corre sobre Web Serial. El esp-web-tools de ESPHome lo empaqueta en un botón «Connect» listo para usar: lo apuntas a un manifiesto — un archivo JSON pequeño que enumera las imágenes de firmware, los offsets de flash y a qué variantes de chip se aplican — y detecta el chip conectado, elige la imagen correcta y la programa. Si agregas Improv Wi-Fi encima, la misma página también puede recoger las credenciales de red del cliente después de programar y pasárselas al dispositivo por el mismo enlace serial, lo que convierte una lista de pasos en una página de soporte en un solo botón.

Las partes con un bootloader USB DFU accesible pueden usar una implementación de DFU basada en WebUSB. Revisa la parte y la placa exactas: el bootloader debe estar disponible, sus pines USB conectados y su procedimiento de entrada al alcance. Revisa también la configuración del equipo host. Windows puede requerir que la interfaz use WinUSB, mientras que Linux puede requerir reglas de permisos de dispositivo; Chrome lo documenta en su guía de dispositivos WebUSB. Programar a través de una sonda de depuración necesita su propio transporte compatible y una biblioteca de programación. Un flujo nativo con sonda no se vuelve accesible desde el navegador automáticamente solo porque la sonda se conecte por USB. Evalúa la cadena completa antes de prometer una experiencia sin instalador.

Diferencias de soporte y permisos entre navegadores

El soporte de los navegadores cambió este año, y esa es la razón real para mirar esto ahora y no archivarlo bajo «algo bueno para algún día».

Navegador	Web Serial	WebUSB
Chrome / Edge / Opera (escritorio)	Soportado en las versiones actuales	Soportado en las versiones actuales
Chrome (Android)	Soportado desde la versión 148; el soporte anterior estaba limitado por el transporte	Soportado
Firefox (escritorio)	Soportado desde la versión 151	No soportado
Safari / WebKit	No soportado	No soportado

Esta tabla refleja los datos de compatibilidad de Web Serial y los datos de compatibilidad de WebUSB de MDN, consultados el 22 de septiembre de 2026. Mozilla lanzó Web Serial de escritorio en Firefox 151 en mayo. Firefox agrega un paso de complemento de permiso de sitio, y Mozilla dice que Web Serial está deshabilitado de forma predeterminada para las organizaciones que usan políticas empresariales de Firefox, a menos que los administradores lo habiliten. Ese lanzamiento no agrega WebUSB. Prueba la biblioteca de programación real además de la disponibilidad de la API: un sitio todavía puede rechazar un navegador soportado mediante sus propias verificaciones de compatibilidad. Conserva una ruta de recuperación nativa para navegadores no soportados, equipos administrados y dispositivos cuya configuración de controladores impide el acceso.

Dónde rinde y dónde no

El caso más sólido es cualquier cosa de cara al cliente: una página de configuración para un producto que habla serial o expone un bootloader DFU o compatible con Improv, donde la alternativa de hoy es «instala primero nuestra app». También rinde en una línea de producción para reprogramar o reaprovisionar una unidad que ya tiene firmware de bootloader — sin instalar herramientas en cada estación, sin deriva de versiones entre estaciones, y con la lógica de programación en un solo lugar que se actualiza en el momento en que la despliegas, en lugar de estar en instaladores dispersos en varias máquinas. Esa es la misma estación junto a la que suele estar un fixture de pruebas con pogo pins, así que vale la pena diseñarlos juntos.

Para ver el patrón en hardware real, nuestro flasher de ESP32 en el navegador gratuito lee el chip que está en el cable y el chip para el que se compiló el archivo, y se niega a escribir cuando no coinciden.

Conserva las herramientas nativas donde la sonda o el flujo de aprovisionamiento requerido no tengan una implementación compatible en el navegador. El secure boot sigue requiriendo las imágenes firmadas correctas y la autorización, sin importar qué aplicación las transporte. Para estaciones de producción desatendidas, evalúa si los permisos del navegador, el comportamiento de reconexión y el manejo de sesiones cumplen los requisitos de operación; un dispositivo nuevo no puede recibir acceso simplemente desde una página en segundo plano. Un flasher existente del fabricante o un script de producción puede seguir siendo la opción más simple y controlable.

Las revisiones que vale la pena hacer antes de comprometerse

Confirma con qué bootloader viene realmente la parte — bootloader UART en ROM, USB DFU o ninguno — porque eso determina qué ruta de programación está disponible. Prueba cada navegador y sistema operativo que pienses soportar, incluido el paso adicional de permisos de Firefox donde corresponda. Prueba en una máquina que nunca le haya dado acceso a la página, y luego prueba la reconexión después de una sesión exitosa. Incluye una laptop corporativa administrada y haz que las fallas de permisos o de políticas sean comprensibles para el usuario. Por último, interrumpe la conexión y prueba la recuperación: una programación fallida necesita una forma documentada de volver a un bootloader que funcione, la misma pregunta de recuperación y reversión que debe responder cualquier ruta de actualización. No prometas que cerrar la pestaña, desconectar el cable o suspender la laptop es inofensivo sin probarlo en el hardware de destino.

Nada de esto reemplaza una herramienta de programación nativa donde se requiera una. Elimina los casos en que una herramienta nativa estaba ahí solo porque nadie lo había reconsiderado recientemente.

Trata la selección de firmware como parte del diseño del producto. Una conexión USB exitosa no establece que la placa conectada sea la revisión de hardware correcta para la imagen seleccionada. Decide qué identifica el destino, qué versiones se permiten y qué debe hacer la página cuando no se puede establecer esa identidad. Muestra la versión de firmware seleccionada antes de escribir. Después, distingue una transferencia completada de un dispositivo que se reinició y reportó la versión esperada. Si el dispositivo no puede dar esa confirmación, dilo en lugar de mostrar un mensaje de éxito incondicional. Mantén disponibles una imagen de recuperación conocida e instrucciones fuera de la página de programación, para que un despliegue defectuoso de la página no elimine la única ruta de recuperación.

Decide también qué información necesita soporte cuando una sesión falla: versiones del navegador y del sistema operativo, identidad del dispositivo detectado, imagen seleccionada y el último paso completado. Muestra un resumen de diagnóstico que se pueda copiar, sin incluir credenciales Wi-Fi ni otros secretos. Eso hace que un flujo en el navegador sea más fácil de soportar sin pedirle al cliente que instale una segunda herramienta solo para explicar qué salió mal.

Dónde encajamos

Abordamos las páginas de configuración y de programación en producción como parte del flujo de firmware y pruebas del producto, incluida la selección de imágenes, el manejo de la conexión y la recuperación. Envíanos el bootloader que ya tiene tu parte, o la libertad de elegir uno, y los navegadores que usan tus clientes para que podamos evaluar qué pasos de configuración puede eliminar una página en el navegador.