On platforms without USE_STORE_LOG_STR_IN_FLASH (ESP32, RP2040,
LibreTiny), there is only one esp_log_printf_ overload, so the
separate esp_log_vprintf_ function just adds an unnecessary call
frame. Inline the logger dispatch directly into esp_log_printf_
for these platforms.
The const char* esp_log_vprintf_ is still provided unconditionally
for direct callers (e.g. midea component).
On ESP8266 (USE_STORE_LOG_STR_IN_FLASH), the two esp_log_printf_
overloads continue to share esp_log_vprintf_ as before.
Measured: 32 bytes flash saved on ESP32, no change on ESP8266.
Move the pure logic (string building, escaping, byte length
calculation) out of the nested closure into a module-level function
that can be tested without codegen mocks. Tests cover both copilot
review concerns: empty friendly_name with MAC suffix, and UTF-8
byte length for non-ASCII characters.
When name_add_mac_suffix is true and friendly_name is empty, emit a
mutable static char[] buffer instead of a string literal to match the
char* signature. Also use UTF-8 byte lengths instead of Python str
len() to handle non-ASCII characters correctly.
When MAC suffix is not used, pre_setup takes const char* parameters
so string literals stay in flash. When MAC suffix is used, it takes
mutable char* for the static buffers that get overwritten with the
actual MAC address. This avoids const_cast entirely.
Also adds ESPHOME_NAME_ADD_MAC_SUFFIX define for static analysis.
Replace std::string members with StringRef for Application::name_
and Application::friendly_name_. These are set once during setup()
and never modified, so std::string overhead is unnecessary.
For the MAC suffix case, codegen emits static mutable char buffers
with a placeholder suffix that pre_setup() overwrites with the
actual MAC address. For the non-suffix case, StringRef points
directly at the string literal.
Saves ~2.5KB flash and ~48 bytes RAM by eliminating std::string
template instantiations (constructor, _M_assign, _M_dispose,
_M_construct, _M_replace_cold, _S_copy).
Add generate_boards.py script that reads board definitions and variant
pin headers from the arduino-pico repository to auto-generate boards.py
with support for 143+ boards including RP2350 variants.
Fix the Pico W LED pin from 32 (non-existent GPIO, never worked) to 64
(CYW43 wireless GPIO 0, hardware verified).
Make gpio.py pin validation data-driven:
- CYW43 virtual pin detection uses board pin map data
- Pin range based on MCU type from generated board metadata
- No hardcoded board names or magic numbers
Serial ports in the chooser may belong to other devices (e.g. FT232R),
not the RP2040. Show the BOOTSEL tip whenever no BOOTSEL device is
detected via picotool, regardless of whether serial ports are present.
Replace UF2 file copy to mass storage volume with direct picotool upload.
This avoids macOS "disk not ejected properly" warnings caused by the RP2040
resetting immediately after receiving the firmware.
- Use picotool (already installed by PlatformIO) for BOOTSEL detection
and firmware upload via USB
- Upload ELF directly with `picotool load -v -x` for real-time progress
- Remove platform-specific mass storage volume detection (macOS/Linux/Windows)
- Show helpful udev rules message on Linux permission errors
J. Nick Koston