Cuando un equipo firmware arranca un proyecto sin un Board Support Package (BSP), buena parte del primer hito se va en inicializar la placa: seleccionar target, configurar periféricos, asignar GPIOs, levantar display, controlador táctil, botones, audio, sensores, almacenamiento y power management. Es un trabajo detallado que exige leer esquemáticos, se rompe fácil ante un pin mal asignado, y hay que rehacerlo cada vez que un prototipo se convierte en PCB de producción.

Espressif lanzó el ESP-BSP Generator, una herramienta web que resuelve exactamente ese cuello de botella. El equipo firmware carga un BSP ya existente, adapta los pines y features al PCB nuevo, y descarga un componente ESP-IDF listo para integrar, con la misma estructura y convenciones que los BSPs oficiales.

¿Qué es un BSP y por qué importa?

Un BSP empaqueta el conocimiento de hardware específico en un componente reutilizable. Contiene los drivers, la inicialización de periféricos, la configuración de la placa, los ajustes del target y las APIs necesarias para usar las capacidades del board. En lugar de repetir el mismo setup en cada aplicación, los proyectos llaman a una capa común.

Espressif introdujo la idea inicialmente con los BSPs mantenidos para sus dev kits (Using ESP-BSP with DevKits). El mismo enfoque es igual de útil para hardware custom: crear un BSP propio le da al equipo un único lugar donde describir el esquemático, reutilizar código de inicialización, mantener la aplicación limpia y moverse entre prototipo y producción sin fricción.

¿Qué hace exactamente el ESP-BSP Generator?

La lógica es simple: en vez de copiar manualmente un board existente, editar sources, actualizar Kconfig y revisar cada dependencia, el desarrollador describe su hardware en un formulario guiado. Puede partir desde un board probado del repositorio esp-bsp — por ejemplo ESP32-S3-BOX-3, ESP32-C3-LCDKit o M5Stack Tab5 — ajustar pines y features enabled para que coincidan con el esquemático, y generar un componente BSP con la misma calidad que los oficiales.

Diálogo para cargar configuración desde un board de arranque como ESP-BOX-3 o ESP32-C3-LCDKit
Diálogo para cargar configuración desde un board de arranque como ESP-BOX-3 o ESP32-C3-LCDKit

El flujo básico:

  • Abrir el generador y hacer clic en Load configuration para elegir el board de partida más cercano al prototipo.
  • El formulario se rellena con MCU, features, drivers y asignación de pines — la misma estructura que los BSPs oficiales.
  • Los íconos ? entregan hints sobre cada campo.
  • Guardar el archivo JSON: es la única fuente de verdad de la definición del board.

¿Cómo se configura un board custom?

Cada capacidad de la placa vive en su propia feature tab: Display, Touch, Buttons, Audio, SD card, Camera, sensores, USB, batería y más. Se habilita lo que el esquemático tiene y se deshabilita lo que se quitó del PCB. El generador chequea dependencias — por ejemplo, un táctil sobre I2C requiere I2C habilitado — antes de generar cualquier archivo.

Pestaña de configuración de Display con resolución, driver, pines y opciones LVGL
Pestaña de configuración de Display con resolución, driver, pines y opciones LVGL

Antes de tocar drivers, conviene personalizar la identidad del BSP: actualizar BSP Name (queda como nombre del folder del componente), Long Description (se copia al README.md generado y opcionalmente al .slb de SquareLine Studio), subir una foto del board, agregar el link al HW con esquemáticos, y actualizar la BSP URL que se escribe en idf_component.yml.

¿Qué entrega el ZIP final?

Al hacer clic en Generate BSP el equipo recibe un archivo comprimido con:

  • Un componente ESP-IDF completo (CMakeLists.txt, Kconfig, headers, sources).
  • sdkconfig.defaults generado según las opciones elegidas.
  • README.md con capacidades y tabla de dependencias.
  • API.md con referencia estilo Doxygen, igual que los BSPs oficiales.
  • Variante noglib opcional (BSP sin LVGL).
  • Pack opcional para SquareLine Studio — el editor visual de UI de LVGL.

La aplicación puede seguir llamando a los mismos entry points del BSP:

C
#include "bsp/esp-bsp.h"

void app_main(void) {
    bsp_display_start();
    bsp_display_backlight_on();
    // ...
}

Y el componente nuevo se enlaza en main/idf_component.yml:

YAML
dependencies:
  my_custom_board:
    path: ../components/my_custom_board

¿Cómo cambia el flujo entre prototipo y producción?

Este es el payoff editorial para equipos de producto: el firmware del prototipo usa el BSP esp-box-3 desde el repositorio esp-bsp, y el firmware de producción usa my_custom_board generado con la herramienta. La aplicación mantiene los mismos #include y las mismas APIs. El equipo no tiene que mantener un fork eterno de esp-bsp: solo un paquete de board pequeño y generado que sigue las mismas convenciones — layout del componente, helpers bsp_*, integración LVGL vía esp_lvgl_port.

Pantalla de éxito con siguientes pasos, lista de archivos y botón para descargar el ZIP
Pantalla de éxito con siguientes pasos, lista de archivos y botón para descargar el ZIP

La definición del board vive en un JSON

Cada corrida exitosa produce un archivo JSON de configuración dentro del folder del BSP (por ejemplo my_board/my_board.json). Espressif recomienda tratarlo como la única fuente de verdad del hardware, no los archivos .c generados. El JSON contiene la metadata del board (nombre, MCU, URL del repositorio, foto, opciones del generador) y BSP_FEATURES: qué capacidades están habilitadas y cómo están cableadas — pines GPIO, buses I2C/SPI/RGB, drivers de display y touch, códecs de audio, ancho de bus para SD card y sensores.

En la práctica, esto significa:

  • Commit del JSON en Git junto al firmware — es la definición del board que vale la pena versionar; el BSP se regenera desde ahí en vez de editar los .c.
  • Reload cuando sea necesario desde la home del generador o desde la pantalla de éxito.
  • Compartir el JSON entre colegas o proyectos para que todos partan de la misma descripción.
  • Diff entre spins del PCB para ver qué cambió: un sensor nuevo, distintos pines I2C, swap del driver del display.

¿Qué pasa cuando se actualiza ESP-IDF?

El JSON guarda el board del usuario; los templates del generador guardan cómo debe construirse un BSP para la versión actual de ESP-IDF y del ecosistema de componentes. Cuando salga un mayor de ESP-IDF, se actualicen patrones en esp-bsp, aparezcan drivers nuevos en el registry o se necesite agregar una feature, no hay que hacer merge manual de cientos de líneas en los bsp_*.c.

Basta cargar el JSON guardado, ajustar solo lo que cambió, y hacer clic en Generate BSP nuevamente. La herramienta re-renderiza todo el componente desde los templates actuales: sources, Kconfig, sdkconfig.defaults, API.md, README.md y el pack opcional de SquareLine. El pinout y las features elegidas se mantienen; el código generado incorpora los fixes de template y las actualizaciones de API automáticamente.

Aplicabilidad para equipos LatAm

Para PYMES y makers en Chile que hacen consultoría de firmware sobre ESP32, ESP32-S3 o ESP32-C6 — una franja creciente desde 2024 con el auge del hardware conectado local — la herramienta acorta el ciclo prototipo-producción de días a horas. En proyectos donde el equipo cliente ya prototipó sobre un ESP32-S3-BOX o un ESP32-C3-LCDKit y encarga la PCB final, el generador elimina la fase de portabilidad que antes se cobraba como servicio adicional.