Firmware Whispers: 14 Prompts That Turn Arduino, ESP32 and Raspberry Pi Ideas Into Working Prototypes Faster

Firmware Whispers: 14 Prompts That Turn Arduino, ESP32 and Raspberry Pi Ideas Into Working Prototypes Faster

In 2026, the bottleneck in embedded and IoT projects is rarely the idea. It is the gap between a sketch on a napkin and firmware that actually boots, connects to Wi-Fi, publishes to a broker, and survives a week on a battery. Datasheets are long, errata sheets are longer, and the difference between delay() and vTaskDelay() can cost you an afternoon.

This is where well-crafted prompts change the economics of prototyping. Not "write me code" prompts — those produce plausible-looking garbage. We mean prompts that force the model to reason about pin maps, timing budgets, RTOS semantics, and power states before it writes a single line. The result: fewer compile cycles, fewer board resets, and more time spent on the part that is actually interesting.

Below are 14 prompts organized by difficulty. Each includes what it does, a real example, and the kind of output you should expect. Treat them as templates — the more hardware context you inject, the better the answer.

Basic: Getting the Board to Do Something Sensible

1. Pin map planner

Task: Avoid the classic mistake of assigning a PWM pin to an input-only GPIO.

Prompt:

I am using an ESP32-WROOM-32 DevKitC. I need: 1x I2C sensor (BME280),
1x SPI display (ST7735), 1x ADC light sensor, 1x PWM LED, 1x button with
internal pull-up. List a pin assignment that avoids strapping pins, avoids
input-only pins (34-39), and keeps ADC2 free for Wi-Fi coexistence.
Explain each choice in one line.

Example result: The model returns a table mapping SDA→GPIO21, SCL→GPIO22, SPI MOSI→GPIO23, and explicitly warns that GPIO34–39 are input-only and that ADC2 is unusable while Wi-Fi is active — a real constraint documented in Espressif's ESP32 datasheet.

2. Datasheet-to-driver translator

Task: Turn a register table into a minimal C driver.

Prompt:

Here is the register map of a fictional-but-plausible sensor:
0x00 WHO_AM_I (read, expected 0x5A)
0x10 CTRL_REG1 (RW, bit0=enable, bits4-6=ODR)
0x20 DATA_X_L, 0x21 DATA_X_H (read)
Write a portable C driver with init(), read_x(), and a self-test
that verifies WHO_AM_I. No HAL dependencies.

Example result: A ~60-line driver with a static int i2c_read(...) shim you can wire to Wire (Arduino), ESP-IDF's i2c_master, or Linux i2c-dev. The self-test catches wiring errors before you debug logic.

3. Arduino sketch skeleton with non-blocking loop

Prompt:

Write an Arduino sketch for an Uno that blinks an LED every 500 ms,
reads a button with debounce, and prints state changes over Serial at
115200 baud. Do not use delay() in loop(). Use millis() and a small
state machine. Include comments explaining the overflow-safe subtraction.

Example result: The model produces the standard (now - last) >= interval pattern and explains why now - last is overflow-safe for unsigned long — a genuine footgun for beginners.

4. Error message decoder

Task: Debug cryptic toolchain output.

Prompt:

My ESP-IDF build fails with:
"region `iram0_0_seg' overflowed by 4,312 bytes"
What does this mean, what are the likely causes, and how do I reduce
IRAM usage without disabling Wi-Fi? Give concrete sdkconfig flags.

Example result: An explanation that IRAM holds code that must run during flash-cache-disabled windows (ISRs, some Wi-Fi paths), plus suggestions like moving large functions to flash with IRAM_ATTR removed, and checking CONFIG_ESP_WIFI_IRAM_OPT.

Advanced: RTOS, Connectivity, and Real Protocols

5. FreeRTOS task decomposition

Prompt:

I have three jobs on an ESP32: (a) read BME280 every 2s, (b) publish
JSON to MQTT over Wi-Fi, (c) drive a WS2812 strip with smooth animation.
Decompose into FreeRTOS tasks with priorities, stack sizes, and queues.
Explain why the LED task should NOT be the highest priority.

Example result: A three-task design with a queue between sensor and MQTT tasks, and the reasoning that the animation task is timing-sensitive but not safety-critical — starving the Wi-Fi task causes disconnects.

6. MQTT topic schema designer

Prompt:

Design an MQTT topic hierarchy for 500 devices across 12 sites,
each with temperature, humidity, and a firmware version. Use the
Homie convention if it fits. Show example topics for subscribe and
publish, and explain QoS choice for telemetry vs. commands.

Example result: Topics like homie/5/site-03/dev-042/temperature, with QoS 0 for telemetry (loss-tolerant, cheap) and QoS 1 for commands (at-least-once). References the Homie convention at homieiot.github.io.

7. OTA update plan

Prompt:

Explain how to implement OTA firmware updates on ESP32 using the
native esp_https_ota component. Include: partition table requirements,
rollback on failed boot, and how to sign the image. Give the exact
idf.py commands.

Example result: Mentions the ota_0/ota_1 dual-app partition scheme, esp_ota_mark_app_valid_cancel_rollback(), and idf.py build followed by hosting the .bin over HTTPS. Signature uses espsecure.py sign_data.

8. Power budget calculator

Prompt:

My device runs on 2xAA (3V, ~2000 mAh usable). It wakes every 60s,
reads a sensor (20 mA for 50 ms), transmits over BLE (8 mA for 300 ms),
then sleeps at 5 µA. Compute average current and battery life. Show
the formula and units.

Example result: Average current ≈ 5 µA + (20 mA·0.05 s + 8 mA·0.3 s)/60 s ≈ 5 µA + 56.7 µA ≈ 61.7 µA. Life ≈ 2000/0.0617 ≈ 32,400 hours ≈ 3.7 years. The model shows every step so you can change assumptions.

9. Raspberry Pi GPIO with libgpiod

Prompt:

Show how to toggle GPIO17 on a Raspberry Pi 5 using libgpiod v2 from
Python (gpiod module), not RPi.GPIO. Include reading a button with
edge detection and clean shutdown.

Example result: Uses gpiod.request_lines() with Edge.RISING and a with block so the line is released. Notes that RPi.GPIO is deprecated on newer kernels in favor of the character device interface.

Expert: Hardening, Compliance, and Scale

10. Watchdog and brownout strategy

Prompt:

Design a robustness strategy for an ESP32 device in an industrial
cabinet with noisy power. Cover: task watchdog (TWDT), interrupt
watchdog, brownout detector threshold, and how to log the reset
reason on boot using esp_reset_reason().

Example result: Concrete calls — esp_task_wdt_init(), esp_task_wdt_add(), checking ESP_RST_BROWNOUT vs ESP_RST_TASK_WDT — plus the advice to persist the reset reason to NVS before rebooting.

11. Security review of an IoT design

Prompt:

Review this design for OWASP IoT Top 10 issues: ESP32 with hardcoded
Wi-Fi credentials, MQTT over plain TCP, no secure boot, OTA over HTTP.
List each risk, its OWASP category, and a concrete fix with the
appropriate ESP-IDF API.

Example result: Maps hardcoded creds to "Weak, Guessable, or Hardcoded Passwords," recommends nvs_flash with encryption, TLS via esp-tls, and secure boot v2 signed with an RSA-3072 key.

12. Unit-testing embedded logic off-target

Prompt:

I have a state machine in C for a door controller. Show how to compile
and test it on a Linux host with Unity (ThrowTheSwitch), mocking the
GPIO layer via function pointers, so I can run tests in CI without
hardware.

Example result: A CMake target that compiles the logic file plus a fake gpio_read() implementation, and a Unity test asserting transitions. This is the pattern used by many firmware teams to keep CI fast.

13. Linux device tree overlay for Pi HAT

Prompt:

Write a device tree overlay for a Raspberry Pi that enables SPI0 with
CE0 at 1 MHz and declares a custom chip compatible with "vendor,mydev"
at address 0. Show the .dts source and the dtc compile command.

Example result: A .dts with fragment@0 targeting spi0, and the command dtc -@ -I dts -O dtb -o mydev.dtbo mydev-overlay.dts. Explains that overlays are loaded via config.txt with dtoverlay=.

14. Fleet telemetry schema and retention

Prompt:

I have 5,000 ESP32 devices publishing 1 message/minute. Design a
schema for time-series storage (InfluxDB line protocol), estimate
daily write volume, and propose a downsampling and retention policy.

Example result: Line protocol sample telemetry,site=s03,dev=d042 temp=21.4,hum=47i 1696000000000000000, ~7.2M points/day, retention 90 days raw and 2 years downsampled to 5-minute averages.

The through-line across all 14 prompts is context. A model that knows your exact board, your pin constraints, and your power budget produces firmware you can flash; a model fed one vague sentence produces a tutorial you have to rewrite. Start with the basic prompts on a breadboard, graduate to the RTOS and OTA ones when your prototype leaves the desk, and keep the security review prompt in your checklist before anything ships to a customer.

If you want a structured way to build these skills — from GPIO fundamentals to fleet-scale telemetry — explore the embedded and IoT tracks at asibiont.com/blog. Pick one prompt, wire one board, and see how much of the datasheet you can skip before lunch.