PinPilot: Verified ESP32 Firmware with IBM Bob

The problem. Starting an ESP32 project with a few sensors and a display is slow and error-prone, even for experienced embedded developers. The classic ESP32 hides many traps: input-only pins, strapping pins that break boot, flash pins, and ADC2 channels that silently stop working as soon as WiFi is enabled. Developers also have to work out shared I2C buses, address conflicts, SPI chip selects and library setup from several datasheets, and getting an LVGL touchscreen to compile can take a day on its own. These mistakes usually appear only on the bench, after hours of debugging — and embedded developers already spend 20–40% of their time debugging. Documentation of the final wiring is rarely written at all. The solution. PinPilot combines a visual configurator with IBM Bob acting as a firmware engineer. In the web app, developers pick components from a catalog of common market parts (BME280, BH1750, DS18B20, capacitive soil moisture sensor, relay, SSD1306 OLED, ILI9341 TFT). PinPilot assigns pins automatically following ESP32 best practices and validates the design in real time against a single source of truth for pin capabilities. It catches flash pins, input-only pins, strapping pins, I2C address conflicts, duplicated GPIOs and ADC2 + WiFi conflicts, and an "Auto-fix pins" button resolves them in one click. The result is exported as a project.json. The developer then opens that file in IBM Bob IDE, where PinPilot's custom modes and skills take over. Firmware Dev generates a complete PlatformIO project using two parallel subagents, with a non-blocking main loop, a generated pin map and one module per component, and immediately compiles it. If the build fails, Bob switches automatically to Build Fixer, which reads the compiler error and applies a minimal fix, with a hard limit of three attempts. Tech Writer then produces a LaTeX document with a block diagram, wiring table, pin map and bus configuration, compiled to PDF. Target users. Embedded and IoT developers, makers and students, and small hardware teams — for example, agtech teams building sensor nodes for the field. Why it is different. PinPilot deliberately splits the work: hardware rules are checked deterministically, so the AI never has to guess which pin is safe, while Bob handles what really needs an agent — generating, compiling, fixing and documenting code. Nothing is presented as working unless it actually compiled. Both demos compile: a weather station on the first attempt (7.1% RAM), and a smart farm node with an LVGL 9 dashboard on the second attempt, after Build Fixer corrected an LVGL callback type error (29.0% RAM). The catalog also grows from documents: Bob read a sensor datasheet and created a new, schema-valid entry, citing the page of every value. What normally takes hours of datasheet reading, pin checking and library setup becomes a few minutes, with the most common hardware bugs caught before any code is written.