Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Comment thread
espzav marked this conversation as resolved.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
153 changes: 153 additions & 0 deletions content/blog/2026/06/bsp-generator-promo/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,153 @@
---
title: From Espressif Dev Kit to Your Custom Board - in an Afternoon
date: 2026-06-11
summary: Start from an esp-bsp dev kit, customize pins and features in a web form, and download a production-style BSP component for your custom PCB - same APIs, less manual work.
featureAsset: "img/featured.webp"
tags:
- ESP-BSP
authors:
- "vilem-zavodny"
---

The [ESP-BSP Generator](https://bsp-generator.espressif.tools) bridges that gap: start from a proven [esp-bsp](https://github.com/espressif/esp-bsp) board, select pins and features in a visual form, and download a production-style BSP component for *your* hardware while keeping the same APIs your code already uses.

## The problem every custom board hits

You or your software team creates a prototype on **ESP32-S3-BOX-3**, **ESP32-C3-LCDKit**, **M5Stack Tab5**, or another board from [esp-bsp](https://github.com/espressif/esp-bsp). Display, touch, audio, SD card work perfectly because Espressif maintains the BSP.

Then the hardware team designs a custom board with a different touch controller, pin mapping, and without a speaker. Now you have to partially start from scratch.

**There is a better workflow.**

## Start with what already works

{{< figure
src="img/02-load-configuration-modal.webp"
alt="Load configuration — pick a starter board (ESP-BOX-3, ESP32-C3-LCDKit, …)"
caption="Load configuration — pick a starter board (ESP-BOX-3, ESP32-C3-LCDKit, …)"
>}}

1. Open the **[ESP-BSP Generator](https://bsp-generator.espressif.tools)**.
2. Click **Load configuration** and pick a starter board that matches your prototype (e.g. ESP-BOX-3, ESP32-S3-EYE, ESP32-C3-LCDKit).
3. The form fills in MCU, features, drivers, and pin assignments - the same structure as the official BSP in [esp-bsp/bsp/](https://github.com/espressif/esp-bsp/tree/master/bsp).

## Configure features for *your* PCB

{{< figure
src="img/03-starter-board-loaded.webp"
alt="Starter board loaded — ESP-BOX-3 configuration ready to customize"
caption="Starter board loaded — ESP-BOX-3 configuration ready to customize"
>}}

Each capability is a **feature tab**: Display, Touch, Buttons, Audio, SD card, Camera, sensors, USB, battery, and more. Enable what your schematic actually has; disable what you removed.

Typical custom-board edits:

| On the dev kit | On your custom board |
|----------------|----------------------|
| 3 navigation buttons | 2 buttons, different GPIOs |
| FT5x06 touch on I2C | Same controller, different I2C pins |
| RGB LCD + backlight PWM | SPI display, fixed backlight |
| On-board microphone | No audio - tab stays off |

The generator checks dependencies (touch over I2C needs I2C enabled, and so on) before it builds anything.

{{< figure
src="img/04-display-feature-tab.webp"
alt="Display feature tab — resolution, driver, pins, and LVGL options"
caption="Display feature tab — resolution, driver, pins, and LVGL options"
>}}

Hover the **?** icons for hints. Upload a board photo for the generated README. Save the JSON - that file is your **single source of truth** for the board definition.

## Generate once, integrate like any esp-bsp component

Click **Generate BSP**. You get a ZIP with:

- A full **ESP-IDF component** (`CMakeLists.txt`, `Kconfig`, headers, sources)
- **`sdkconfig.defaults`** generated to your choices
- **`README.md`** with capabilities and dependency table
- **`API.md`** API reference (Doxygen-style, same idea as official BSPs)
- Optional **noglib** variant (BSP without LVGL)
- Optional **SquareLine Studio** OBP pack for UI designers

Your application keeps calling the same BSP entry points:

```c
#include "bsp/esp-bsp.h"

void app_main(void)
{
bsp_display_start();
bsp_display_backlight_on();
// ... your UI / logic unchanged in spirit
}
```

Wire the new component in `main/idf_component.yml`:

```yaml
dependencies:
my_custom_board:
path: ../components/my_custom_board
```

Copy `sdkconfig.defaults` to the project root, set the target, build. **The application structure stays familiar** - only the board layer changed.

---

## Swap the component, keep the software

This is the payoff for product teams:

```
Prototype firmware → uses esp-box-3 BSP from esp-bsp
Production firmware → uses my_custom_board BSP from the generator
Application code → largely the same #include and BSP APIs
```

You are not maintaining a fork of esp-bsp forever. You maintain a **small, generated board package** that follows the same conventions as [espressif/esp-bsp](https://github.com/espressif/esp-bsp): component layout, `bsp_*` helpers, LVGL integration via [esp_lvgl_port](https://github.com/espressif/esp-bsp/tree/master/components/esp_lvgl_port), examples you can compare under [esp-bsp/examples/](https://github.com/espressif/esp-bsp/tree/master/examples).

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me this whole paragraph does not make sense because this customer that uses BSP selector will not maintain the small, generated board package. He only has to save the json somewhere and the BSP team is maintaining the generated board package.
I think that this whole paragraph can be shortened and merged with Your application keeps calling the same BSP entry points:

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, we can keep this paragraph.


## ESP-IDF upgraded? Regenerate, don’t rewrite

Saved configuration JSON is more than a backup. When:

- **ESP-IDF** moves to a new major version,
- **esp-bsp** templates or drivers change,
- you add a feature you skipped in v1 (e.g. SD card on the next PCB spin),

…load the JSON in the generator, adjust what changed, and **Generate BSP** again.

You refresh pins, Kconfig, and generated sources from the template — instead of merging hundreds of manual edits across C files.

{{< figure
src="img/05-generation-success.webp"
alt="Generation success — next steps, file list, and Download ZIP"
caption="Generation success — next steps, file list, and Download ZIP"
>}}

The success page walks through integration steps; the in-app **Help** modal covers load/save, features, and SquareLine OBP install paths.

## Why esp-bsp + the generator together

| | [esp-bsp](https://github.com/espressif/esp-bsp) | [BSP Generator](https://bsp-generator.espressif.tools) |
|---|------------------------------------------------|------------------------------------------------------|
| **Best for** | Official Espressif & partner boards | Your custom PCB |
| **Maintained by** | Espressif BSP team | Generated from shared templates |

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here I would say it is also a bit misleading. I would say that even the generated component has to be maintained by the BSP team because once you start editing the generated package you can't really do what you advertise in ESP-IDF upgraded? Regenerate, don’t rewrite

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure, if I understand right, but generated custom board cannot be maintained by BSP team.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No I mean that the customer also should not maintain it. Ideally they should not touch the generated package because of they do then it can't be re-generated in the future because it would be missing those changes that they did.

| **API style** | `bsp_*`, LVGL port, examples | Same patterns |
| **Registry** | Components on [components.espressif.com](https://components.espressif.com) | Your `idf_component.yml` + path or publish later |

Use **esp-bsp** as reference and dependency where it fits. Use the **generator** when the schematic is yours.

## SquareLine Studio? Covered.

If your flow includes UI design, enable **Generate SquareLine Studio pack** (Display required). The ZIP includes an [Open Board Platform](https://docs.squareline.io/docs/obp/) bundle (`.slb`, `.zip`, `.png`) ready to copy into `~/SquareLine/boards/` - designers stay in SquareLine; firmware stays on the same BSP pins and resolution you defined in the form.

## Try it in five minutes

1. Go to **[bsp-generator.espressif.tools](https://bsp-generator.espressif.tools)**
2. **Load** `ESP-BOX-3` or any starter board close to your hardware
3. Change one GPIO, rename the BSP, click **Generate**
4. Drop the component into a blank ESP-IDF project and `idf.py build`

Explore official boards and docs in **[github.com/espressif/esp-bsp](https://github.com/espressif/esp-bsp)** - then make the generator your shortcut from dev kit to custom product.
Loading