idfxx 1.0 release - C++23 component library
Posted: Mon Apr 27, 2026 6:15 pm
Hi all,
I've just released https://github.com/cleishm/idfxx v1.0, a modern C++23 component library for ESP-IDF. It's the API surface I want to use when building my C++ ESP-IDF projects: typed RAII for every resource, scoped enums and gpio objects in place of raw ints, std::format-based logging, ESP-IDF errors exposed via a custom std::error_category and presented as std::error_code, and a try_* form of every method returning std::expected for projects compiled without exceptions. Most components compile down to the C API - the C++ surface is a compile-time abstraction, so the generated code is the same as the equivalent ESP-IDF C calls.
30 components in this first release:
Install via the Component Registry:
Repo with full docs and examples: https://github.com/cleishm/idfxx
A short example, scanning an I2C bus for devices:
30 components is where idfxx starts. Whether it grows depends a lot on what else I need for my projects or whether the community picks it up. Contributions and suggestions on what to prioritise are welcome, as is feedback from anyone who has tried similar wrappers.
I've just released https://github.com/cleishm/idfxx v1.0, a modern C++23 component library for ESP-IDF. It's the API surface I want to use when building my C++ ESP-IDF projects: typed RAII for every resource, scoped enums and gpio objects in place of raw ints, std::format-based logging, ESP-IDF errors exposed via a custom std::error_category and presented as std::error_code, and a try_* form of every method returning std::expected for projects compiled without exceptions. Most components compile down to the C API - the C++ surface is a compile-time abstraction, so the generated code is the same as the equivalent ESP-IDF C calls.
30 components in this first release:
- Core: error handling, memory allocators, chrono, flags, std::format-based logging, esp_timer wrapper, hardware interrupt allocation
- FreeRTOS wrappers: task, queue, event group, event loop
- Storage: NVS, OTA, partitions
- Networking: netif/SNTP, Wi-Fi, HTTP(S) client/server, console
- Peripherals: GPIO, SPI master, I2C master, 1-Wire, PWM, button, rotary encoder
- Display: LCD panel I/O, ILI9341 driver, touch panel I/O, STMPE610
- Sensors: DS18x20
Install via the Component Registry:
Code: Select all
dependencies:
cleishm/idfxx_core:
version: "^1.0.0"
cleishm/idfxx_gpio:
version: "^1.0.0"
A short example, scanning an I2C bus for devices:
Code: Select all
#include <idfxx/i2c/master>
#include <idfxx/log>
using namespace frequency_literals;
static constexpr idfxx::log::logger logger{"app"};
extern "C" void app_main() {
idfxx::i2c::master_bus bus{idfxx::i2c::port::i2c0, {
.sda = idfxx::gpio_21,
.scl = idfxx::gpio_22,
.frequency = 400_kHz,
}};
auto addresses = bus.scan_devices();
logger.info("Found {} device(s):", addresses.size());
for (auto addr : addresses) {
logger.info(" {:#04x}", addr);
}
}
30 components is where idfxx starts. Whether it grows depends a lot on what else I need for my projects or whether the community picks it up. Contributions and suggestions on what to prioritise are welcome, as is feedback from anyone who has tried similar wrappers.