Write Arduino/ESP32 Code with AI in 15 Minutes

Generate working IoT firmware with AI—handle pins, sensors, and deep sleep without manual debugging of hardware configurations.
·
6 min read
·
Mark
·
Software Development Embedded Systems

Stop debugging pin configurations manually—let AI generate working IoT firmware with proper hardware setup

Problem: IoT Projects Fail at the Hardware-Software Interface

You have sensors and microcontrollers but spend hours debugging why the DHT22 won't read, the servo jitters, or WiFi keeps disconnecting. The code examples online don't match your board revision.

You'll learn:

  • How AI handles hardware-specific constraints (pins, voltage, timing)
  • Prompt patterns for reliable sensor integration
  • Catching common ESP32/Arduino pitfalls before flashing

Time: 15 min | Level: Intermediate

Why This Happens

Generic Arduino tutorials assume you know which pins support PWM, which need pull-up resistors, and how to handle 3.3V vs 5V logic. AI models trained on Arduino forums can generate syntactically correct code that physically damages components or never works.

Common symptoms:

  • Sensor reads return -999 or NaN
  • "Brownout detector was triggered" on ESP32
  • Servo moves to random positions
  • WiFi connects but immediately disconnects

Solution

Step 1: Describe Hardware Explicitly

AI needs your exact components, not generic names. Bad prompts get bad code.

Prompt Template:

Board: ESP32-DevKitC v4 (30-pin, CP2102 USB chip)
Sensors: DHT22 on GPIO 4, HC-SR04 ultrasonic on GPIO 5 (trig) & 18 (echo)
Power: USB 5V, sensors powered from 3.3V pin
Goal: Read temperature every 10 seconds, trigger LED on GPIO 2 if temp > 30°C

Constraints:
- Must deep sleep between readings (battery powered)
- Handle DHT22 startup time (2 seconds)
- Avoid GPIO 6-11 (used by flash memory)

Why this works: AI knows ESP32 has boot mode pins, limited deep sleep wake sources, and 3.3V logic. Vague prompts miss these.

Step 2: Request Hardware Validation

Ask AI to check your wiring before generating code.

Follow-up Prompt:

Before writing code:
1. Check if my pin choices conflict with boot modes
2. Verify DHT22 can run on 3.3V (datasheet says 3-5V)
3. Confirm GPIO 4 supports input with internal pull-up
4. Calculate if 500mA USB can power all components

Expected Response:

  • ✅ GPIO 4 is safe, has pull-up
  • ⚠️ DHT22 at 3.3V may be unreliable below 0°C
  • ❌ GPIO 2 blinks during boot—use GPIO 15 for LED instead

If AI skips this: Rephrase: "Act as hardware engineer reviewing this schematic. What breaks?"

Step 3: Generate Code with Error Handling

Standard Arduino examples ignore hardware failures. Demand robustness.

Prompt Addition:

Include:
- Timeout for DHT22 reads (sensor can freeze)
- Brownout detection (check if Vin drops below 3.1V)
- Retry logic for WiFi (ESP32 has flaky RF at boot)
- Watchdog timer to recover from hangs

AI Output Pattern:

#include <DHT.h>
#include <esp_task_wdt.h>

#define DHT_PIN 4
#define LED_PIN 15
#define WDT_TIMEOUT 30  // seconds

DHT dht(DHT_PIN, DHT22);

void setup() {
  Serial.begin(115200);
  
  // Enable watchdog - ESP32 will reset if loop() hangs
  esp_task_wdt_init(WDT_TIMEOUT, true);
  esp_task_wdt_add(NULL);
  
  pinMode(LED_PIN, OUTPUT);
  dht.begin();
  
  delay(2000);  // DHT22 needs 2s after power-on
}

void loop() {
  esp_task_wdt_reset();  // Feed watchdog
  
  // Read with timeout protection
  float temp = dht.readTemperature();
  
  if (isnan(temp)) {
    Serial.println("DHT read failed - check wiring");
    delay(2000);
    return;  // Skip this cycle
  }
  
  // Check brownout condition
  if (temp < -50) {  // Sensor returns -127 on power issues
    Serial.println("Possible brownout detected");
  }
  
  digitalWrite(LED_PIN, temp > 30 ? HIGH : LOW);
  
  Serial.printf("Temp: %.1f°C\n", temp);
  delay(10000);
}

Why this works: Adds hardware-aware safety that generic examples omit.

Step 4: Request Deep Sleep Implementation

For battery projects, naive delay() drains power. ESP32 deep sleep needs careful setup.

Prompt:

Convert loop() to deep sleep mode:
- Wake every 10 minutes
- Keep RTC memory for WiFi credentials
- GPIO 4 must stay powered (DHT22 needs stable power)
- Calculate expected battery life (2000mAh LiPo, 20µA sleep current)

AI generates:

#include <esp_sleep.h>

#define SLEEP_DURATION 600e6  // 10 min in microseconds

void loop() {
  // ... sensor reads ...
  
  Serial.println("Entering deep sleep");
  Serial.flush();  // Wait for serial to finish
  
  // Configure wake source
  esp_sleep_enable_timer_wakeup(SLEEP_DURATION);
  
  // GPIO 4 stays powered via RTC domain
  esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_ON);
  
  esp_deep_sleep_start();
}

Battery life calculation AI provides:

  • Active (5s): ~80mA → 0.11 mAh per cycle
  • Sleep (595s): ~20µA → 0.003 mAh per cycle
  • Total: ~17 mAh/day = 117 days on 2000mAh battery

Step 5: Validate Before Flashing

Prompt:

Review this code for:
1. GPIO conflicts with boot mode (GPIO 0, 2, 12, 15)
2. Missing pull-up/pull-down resistors
3. Timing violations (I2C clock speed for 3.3V)
4. Memory leaks (String concatenation in loop)

AI checks:

  • ❌ GPIO 15 must be pulled low at boot (add 10kΩ resistor to GND)
  • ✅ No String objects in loop
  • ⚠️ DHT22 library uses blocking delays—consider async version

Verification

Flash and Monitor:

# Using Arduino CLI
arduino-cli compile --fqbn esp32:esp32:esp32 iot_sensor.ino
arduino-cli upload -p /dev/ttyUSB0 --fqbn esp32:esp32:esp32 iot_sensor.ino
arduino-cli monitor -p /dev/ttyUSB0 -c baudrate=115200

You should see:

Temp: 24.3°C
Entering deep sleep
...
[10 minutes later]
ets Jun  8 2016 00:22:57
rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
Temp: 24.5°C

If it fails:

  • Brownout on wake: Power supply too weak—use 2A adapter or bigger capacitor (100µF near ESP32)
  • DHT reads NaN: Wrong pin or missing 4.7kΩ pull-up resistor on data line
  • Won't wake from sleep: GPIO used for wake must be RTC-capable (0, 2, 4, 12-15, 25-27, 32-39)

Advanced: Multi-Sensor Systems

Prompt for Complex Projects:

Board: ESP32-WROOM-32
Sensors:
- BME280 (I2C, 0x76) on GPIO 21 (SDA) / 22 (SCL)
- VEML7700 (I2C, 0x10) on same bus
- MQ-135 (analog, GPIO 34)

Requirements:
- I2C clock 100kHz (both sensors support)
- Check for I2C address conflicts
- MQ-135 needs 24h warmup—store calibration in EEPROM
- All sensors must complete reads in <5 seconds (for battery life)

AI will:

  • Detect I2C address conflict if both are 0x76 (need to change one)
  • Generate EEPROM code to skip MQ-135 calibration after first 24h
  • Use Wire.setTimeOut(5000) to abort stuck I2C transactions
  • Calculate total current draw and suggest battery size

What You Learned

  • AI needs exact hardware specs (board revision, sensor model, power source)
  • Requesting validation catches GPIO conflicts and power issues before flashing
  • Production IoT code requires watchdogs, timeouts, and brownout handling
  • Deep sleep needs RTC domain configuration, not just esp_deep_sleep_start()

Limitations:

  • AI can't debug physical wiring issues (use multimeter to verify 3.3V at sensor)
  • Some sensors (BME680, PN532) have quirky initialization—read datasheet even with AI code
  • RF interference issues (WiFi + BLE simultaneously) need manual tuning

AI Tools for IoT Development

Recommended Workflow:

  1. Claude/ChatGPT with Code Interpreter: Paste datasheets, ask for pin mapping validation
  2. GitHub Copilot in Arduino IDE: Autocompletes sensor library boilerplate
  3. PlatformIO + AI: Better library management than Arduino IDE

Prompt Library:

# Pin conflict checker
"ESP32 GPIO <your pins> - check boot mode conflicts and list safe alternatives"

# Power calculation
"<sensor names> at <voltage> - calculate total current draw and suggest battery"

# Library comparison
"Compare Adafruit_DHT vs DHTesp for ESP32 deep sleep - which handles RTC better?"

Tested on ESP32-DevKitC v4, Arduino IDE 2.3.2, ESP32 board package 3.0.0, DHT sensor library 1.4.6