By the end of this chapter, you will be able to:
setup() and loop() in the microcontroller execution modelmillis() instead of delay()A microcontroller is a tiny computer on a chip. Unlike your laptop or phone, it’s designed to do one thing well: interact with the physical world through sensors and actuators.
Why is this different from regular programming?
What you’ll learn:
This chapter prepares you for hands-on work with Arduino and ESP32 boards in the prototyping chapters.
Programming a microcontroller is like teaching a tiny robot brain to follow your instructions - you get to be the boss!
It was Max the Microcontroller’s very first day on the job, and he was SO excited! But there was one problem - Max didn’t know how to do ANYTHING yet. He was just a blank chip, waiting to learn.
“Don’t worry, Max!” said Lila the LED cheerfully. “The humans will teach you using something called PROGRAMMING. They’ll write special instructions that tell you exactly what to do!” Sammy the Sensor nodded wisely. “First, they’ll write a setup() part - that’s like your morning routine where you get ready for the day. You learn which pins do what and say hello to all your sensor friends!”
“Then comes the fun part,” added Bella the Battery. “The loop() is like your daily job that you do over and over forever! Maybe you read Sammy’s temperature, then tell Lila to blink, then wait a second, and do it all again!” Max’s circuits tingled with excitement. “So setup() runs once when I wake up, and loop() runs forever until someone unplugs me? That sounds simple!” The team cheered as the humans uploaded Max’s first program. BLINK! BLINK! BLINK! went Lila, following Max’s brand new instructions. “I did it!” cheered Max. “I made Lila blink! This is amazing - I can learn to do ANYTHING!”
| Word | What It Means |
|---|---|
| Program | A list of instructions that tells the microcontroller exactly what to do, step by step - like a recipe for a robot! |
| setup() | The part of the program that runs ONE time when the microcontroller wakes up - like brushing your teeth in the morning |
| loop() | The part of the program that runs FOREVER, over and over - like breathing (you do it automatically all day!) |
| Upload | Sending your program from the computer into the microcontroller’s brain so it can learn what to do |
Be a Human Microcontroller: Write a simple “program” on paper with setup() and loop() sections. For setup(), write things you do once in the morning (brush teeth, get dressed). For loop(), write things you repeat all day (breathe, blink eyes, check if you’re hungry). Now have a friend or family member “run” your program - they do the setup steps once, then repeat the loop steps over and over until you say “stop!” This is exactly how a microcontroller works - it follows your instructions perfectly, exactly as you wrote them. If you wrote “jump 100 times” it would do ALL 100 jumps. That’s why programmers have to be very careful with their instructions!
| Platform | Pros | Cons | Best For |
|---|---|---|---|
| Arduino Uno | Simple, huge community, 5V logic | Slow (16 MHz), no Wi-Fi | Learning, simple projects |
| Arduino Nano | Small, breadboard-friendly | Same limitations as Uno | Compact projects |
| ESP32 | Wi-Fi+Bluetooth, fast (240 MHz), cheap | 3.3V logic, more complex | IoT projects |
| ESP8266 | Very cheap, Wi-Fi | Fewer pins, older | Simple Wi-Fi projects |
| Raspberry Pi Pico | Dual-core, flexible | Less community support | Advanced projects |
1. Install Arduino IDE
Download from arduino.cc (version 2.x recommended)
2. Add ESP32 Board Support (for ESP32 boards)
Go to: File → Preferences
Add to “Additional Boards Manager URLs”:
https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.jsonGo to: Tools → Board → Boards Manager
Search “esp32” and install “ESP32 by Espressif Systems”
3. Select Your Board
Every Arduino/ESP32 program has two essential functions:
void setup() {
// Runs ONCE when the board powers on or resets
// Use for: Pin configuration, serial begin, sensor initialization
}
void loop() {
// Runs FOREVER in a continuous loop
// Use for: Reading sensors, controlling outputs, main logic
}Behind the scenes, the Arduino core (board support package) provides a small runtime that:
setup() onceloop() (or runs it as a background task on RTOS-based boards)The exact CPU architecture depends on the board (AVR, ARM Cortex-M, Xtensa, RISC-V), but the mental model stays the same: your application code runs, and hardware events (GPIO, timers, UART) can interrupt it.
Most microcontrollers share the same building blocks:
Two execution contexts matter for IoT code:
setup(), loop(), background work)Microcontrollers implement interrupts via an interrupt vector table (or an equivalent dispatch table) that maps interrupt sources to handler function addresses. When you call attachInterrupt() in Arduino code, you’re asking the board support package to wire a pin event to your ISR.
On ARM Cortex-M MCUs, the main program runs in Thread mode and ISRs run in Handler mode. On interrupt entry, the CPU pushes a small stack frame (registers + return address) and restores it on exit. Other architectures use different names, but the same idea applies: interrupt code runs in a separate, time-critical context.
Understanding these architectural details helps you:
IRAM_ATTR, volatile)// The "Hello World" of hardware programming
// Blinks the built-in LED on and off
void setup() {
// Configure the built-in LED pin as an output
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
digitalWrite(LED_BUILTIN, HIGH); // Turn LED on
delay(1000); // Wait 1 second (1000 ms)
digitalWrite(LED_BUILTIN, LOW); // Turn LED off
delay(1000); // Wait 1 second
}pinMode(pin, mode) - Configures a pin as INPUT, OUTPUT, or INPUT_PULLUPdigitalWrite(pin, value) - Sets a pin HIGH (3.3V/5V) or LOW (0V)delay(ms) - Pauses execution for millisecondsLED_BUILTIN is a predefined constant for the onboard LED (pin varies by board; often pin 13 on Arduino Uno, and commonly GPIO2 on many ESP32 dev boards).
GPIO (General Purpose Input/Output) pins can be configured as either inputs (reading sensors/buttons) or outputs (controlling LEDs/relays).
const int LED_PIN = 2; // GPIO2 on ESP32
void setup() {
pinMode(LED_PIN, OUTPUT);
}
void loop() {
digitalWrite(LED_PIN, HIGH); // LED on
delay(500);
digitalWrite(LED_PIN, LOW); // LED off
delay(500);
}const int BUTTON_PIN = 4; // GPIO4
const int LED_PIN = 2; // GPIO2
void setup() {
pinMode(BUTTON_PIN, INPUT_PULLUP); // Internal pull-up resistor
pinMode(LED_PIN, OUTPUT);
}
void loop() {
int buttonState = digitalRead(BUTTON_PIN);
if (buttonState == LOW) { // Button pressed (active LOW with pull-up)
digitalWrite(LED_PIN, HIGH);
} else {
digitalWrite(LED_PIN, LOW);
}
}
Without a pull-up (or pull-down) resistor, an unconnected input pin “floats” and reads random values. INPUT_PULLUP enables the internal pull-up resistor, keeping the pin HIGH when the button is not pressed.
With a pull-up: - Button not pressed → Pin reads HIGH (1) - Button pressed → Pin reads LOW (0) - “Active Low” logic
Many sensors output analog voltages. The ADC (Analog-to-Digital Converter) converts these to digital values.
| Board | ADC Resolution | Voltage Range | Value Range |
|---|---|---|---|
| Arduino Uno | 10-bit | 0-5V | 0-1023 |
| ESP32 | 12-bit | 0-3.3V | 0-4095 |
const int POT_PIN = 34; // GPIO34 (ADC1 on ESP32)
void setup() {
Serial.begin(115200);
// No pinMode needed for analog input
}
void loop() {
int rawValue = analogRead(POT_PIN); // 0-4095 on ESP32
// Convert to voltage (ESP32: 12-bit ADC, 0-4095 maps to 0-3.3V)
float voltage = rawValue * (3.3 / 4095.0);
// Convert to percentage
int percentage = map(rawValue, 0, 4095, 0, 100);
Serial.print("Raw: ");
Serial.print(rawValue);
Serial.print(" | Voltage: ");
Serial.print(voltage);
Serial.print("V | Percent: ");
Serial.print(percentage);
Serial.println("%");
delay(100);
}const int TEMP_PIN = 35;
void setup() {
Serial.begin(115200);
}
void loop() {
int rawValue = analogRead(TEMP_PIN);
// LM35 outputs 10mV per degree Celsius
// With 3.3V reference and 12-bit ADC:
float voltage = rawValue * (3.3 / 4095.0);
float temperatureC = voltage * 100.0; // 10mV/°C
Serial.print("Temperature: ");
Serial.print(temperatureC);
Serial.println(" °C");
delay(1000);
}Let’s work through the LM35 temperature sensor ADC calculation in detail:
LM35 sensor characteristics:
ESP32 ADC specifications:
Converting ADC value to voltage: \[V_{\text{measured}} = \text{rawValue} \times \frac{V_{\text{ref}}}{4095}\]
For 25°C (sensor outputs 250 mV): \[\text{rawValue} = \frac{0.25 \text{ V}}{0.000806 \text{ V/bit}} = 310 \text{ (ADC count)}\]
Converting voltage to temperature: \[T = \frac{V_{\text{measured}}}{10 \text{ mV/°C}} \times 1000 = V_{\text{measured}} \times 100\]
Example with rawValue = 310:
Temperature resolution: With 12-bit ADC and 3.3V reference: \[\Delta T = 0.806 \text{ mV/bit} \times \frac{1°C}{10 \text{ mV}} = 0.0806°C \text{ per bit} \approx 0.08°C\]
This means the ESP32 can resolve temperature changes as small as 0.08°C when using the LM35 sensor — excellent precision for most IoT applications!
Practical consideration: ESP32 ADC has ~2-3% non-linearity, so actual precision is closer to ±0.3°C without calibration.
Serial communication sends data one bit at a time over a wire. It’s essential for: - Debugging - Print values to see what your code is doing - Data logging - Send sensor data to a computer - Configuration - Receive commands from a computer
void setup() {
Serial.begin(115200); // Start serial at 115200 baud
Serial.println("Hello, World!"); // Print with newline
}
void loop() {
// Print different data types
Serial.print("Integer: ");
Serial.println(42);
Serial.print("Float: ");
Serial.println(3.14159, 2); // 2 decimal places
// Read incoming data
if (Serial.available() > 0) {
char received = Serial.read();
Serial.print("Received: ");
Serial.println(received);
}
delay(1000);
}| Function | Description | Example |
|---|---|---|
Serial.begin(baud) |
Initialize serial | Serial.begin(115200) |
Serial.print(data) |
Print without newline | Serial.print("Hi") |
Serial.println(data) |
Print with newline | Serial.println(42) |
Serial.available() |
Check if data waiting | if(Serial.available()) |
Serial.read() |
Read one byte | char c = Serial.read() |
Serial.readString() |
Read until timeout | String s = Serial.readString() |
Serial.parseInt() |
Parse integer | int n = Serial.parseInt() |
delay() blocks the entire program. Nothing else can happen during the delay.
// BAD: Blocking code - can't do anything else during delays
void loop() {
digitalWrite(LED1, HIGH);
delay(1000); // Stuck here for 1 second!
digitalWrite(LED1, LOW);
delay(1000); // Stuck here again!
// Can't read sensors, respond to buttons, etc.
}// GOOD: Non-blocking code using millis()
unsigned long previousMillis = 0;
const long interval = 1000; // 1 second
bool ledState = false;
void loop() {
unsigned long currentMillis = millis();
// Check if it's time to toggle the LED
if (currentMillis - previousMillis >= interval) {
previousMillis = currentMillis;
// Toggle LED
ledState = !ledState;
digitalWrite(LED_PIN, ledState);
}
// Other code can run here without being blocked!
int sensorValue = analogRead(SENSOR_PIN);
// Process sensor data...
}
// Blink LED every 500ms AND read sensor every 100ms
unsigned long ledPreviousMillis = 0;
unsigned long sensorPreviousMillis = 0;
const long ledInterval = 500;
const long sensorInterval = 100;
void loop() {
unsigned long currentMillis = millis();
// LED task
if (currentMillis - ledPreviousMillis >= ledInterval) {
ledPreviousMillis = currentMillis;
digitalWrite(LED_PIN, !digitalRead(LED_PIN));
}
// Sensor task
if (currentMillis - sensorPreviousMillis >= sensorInterval) {
sensorPreviousMillis = currentMillis;
int value = analogRead(SENSOR_PIN);
Serial.println(value);
}
}An interrupt immediately pauses the main program when an event occurs (like a button press), runs a special function (ISR - Interrupt Service Routine), then resumes the main program.
| Mode | Triggers When |
|---|---|
LOW |
Pin is LOW |
CHANGE |
Pin changes state (HIGH→LOW or LOW→HIGH) |
RISING |
Pin goes LOW→HIGH |
FALLING |
Pin goes HIGH→LOW |
Keep your ISR fast and simple:
volatileUnderstanding interrupt timing is critical for building responsive IoT systems. When an interrupt occurs, the processor must save context, execute the ISR, and restore context—all of which takes time.
The bottom half pattern splits interrupt handling into two parts:
// Example: Bottom half pattern for sensor reading
volatile bool sensorReady = false;
volatile uint16_t rawValue = 0;
// TOP HALF: Fast ISR
void IRAM_ATTR sensorISR() {
rawValue = readSensorRegister(); // Quick hardware read
sensorReady = true; // Set flag
}
// BOTTOM HALF: Main loop processing
void loop() {
if (sensorReady) {
sensorReady = false;
// Heavy processing here (safe in main loop)
float voltage = rawValue * 3.3 / 4095.0;
float temperature = calculateTemp(voltage);
sendToCloud(temperature);
Serial.println(temperature);
}
}// Read sensor in main loop
void loop() {
int value = analogRead(SENSOR_PIN);
if (value > THRESHOLD) {
// Take action
}
delay(100); // Read every 100ms
}// Read sensor without blocking
unsigned long lastRead = 0;
void loop() {
if (millis() - lastRead >= 100) {
lastRead = millis();
int value = analogRead(SENSOR_PIN);
processValue(value);
}
// Other tasks can run here
}// React immediately to digital events
volatile bool motionDetected = false;
void IRAM_ATTR motionISR() {
motionDetected = true;
}
void loop() {
if (motionDetected) {
motionDetected = false;
// Handle motion detection
sendAlert();
}
// Other tasks
}enum State { IDLE, READING, PROCESSING, SENDING };
State currentState = IDLE;
unsigned long stateTimer = 0;
void loop() {
switch (currentState) {
case IDLE:
if (millis() - stateTimer >= 5000) {
currentState = READING;
}
break;
case READING:
sensorValue = readSensor();
currentState = PROCESSING;
break;
case PROCESSING:
processedValue = processSensor(sensorValue);
currentState = SENDING;
break;
case SENDING:
sendData(processedValue);
stateTimer = millis();
currentState = IDLE;
break;
}
}Test your understanding of core microcontroller programming concepts.
The Mistake: Declaring large local arrays or buffers inside ISRs, such as char buffer[256] for formatting debug messages or storing sensor data within the interrupt handler.
Why It Happens: Developers treat ISRs like regular functions, forgetting that ISRs use a separate, much smaller stack. On ESP32, the ISR stack is typically 2-4 KB (configurable via CONFIG_ESP_SYSTEM_EVENT_TASK_STACK_SIZE), while Arduino AVR boards have only 256-512 bytes for the entire stack. A single char[256] array consumes half the available ISR stack on AVR.
The Fix: Keep ISR local variables under 32 bytes total. Use global or static buffers declared with volatile outside the ISR, and have the ISR only set flags or copy small values (4-8 bytes). For ESP32, use IRAM_ATTR and limit stack usage to under 512 bytes:
// WRONG: Large buffer in ISR
void IRAM_ATTR badISR() {
char msg[256]; // Stack overflow risk!
sprintf(msg, "Value: %d", sensorValue);
}
// CORRECT: Minimal ISR, process in main loop
volatile uint16_t isrValue = 0;
volatile bool dataReady = false;
void IRAM_ATTR goodISR() {
isrValue = readRegister(); // 2 bytes only
dataReady = true; // Flag for main loop
}The Mistake: Using dynamic memory allocation (malloc, new, String concatenation) in the main loop of embedded systems, leading to gradual memory fragmentation until the system crashes after hours or days of operation.
Why It Happens: On desktop systems, modern allocators and virtual memory hide fragmentation issues. On microcontrollers with 4-256 KB RAM and no virtual memory, fragmentation is permanent until reset. Each String concatenation like String s = "Temp: " + String(temp) + "C" allocates 3+ heap blocks that fragment differently on each iteration.
The Fix: Use static buffers with fixed sizes allocated at compile time. For string formatting, use snprintf() with stack-allocated char[] arrays. Reserve String objects once at startup if absolutely needed:
// WRONG: Heap fragmentation in loop
void loop() {
String msg = "Sensor: " + String(analogRead(A0)); // Fragments heap!
Serial.println(msg);
}
// CORRECT: Static buffer, no heap allocation
void loop() {
static char msg[32]; // Allocated once, reused
snprintf(msg, sizeof(msg), "Sensor: %d", analogRead(A0));
Serial.println(msg);
}For ESP32, monitor heap with ESP.getFreeHeap() and ESP.getMaxAllocHeap() - if max allocatable block shrinks over time while free heap stays constant, you have fragmentation.
1. Blocking the Loop with delay()
delay(1000) to wait between sensor readings, which freezes the entire program and ignores all inputs during that timedelay() is the first timing function beginners learn, and it works for simple blink sketches. The consequences only become apparent when adding buttons, displays, or multiple sensorsmillis(). Store the last action time and check if enough time has passed: if (millis() - lastRead >= interval) { lastRead = millis(); readSensor(); }. This allows the loop to remain responsive to other inputs2. Not Using volatile for ISR-Shared Variables
int buttonPressed = 0; that’s modified in an interrupt but read in loop(), then wondering why changes aren’t detectedvolatile, it may never re-read the actual memory location where the ISR updated the valuevolatile: volatile int buttonPressed = 0;. For multi-byte variables on 8-bit MCUs, also disable interrupts briefly when reading to prevent torn reads3. Ignoring Pull-Up Resistors on Inputs
pinMode(pin, INPUT_PULLUP) for active-low buttons (pressed = LOW), or add external 10k resistors. Always ensure inputs have a defined voltage when not actively drivenScenario: Build a battery-powered doorbell that: (1) sends alert when button pressed, (2) logs motion events, (3) sleeps between events to save power.
Hardware:
Code:
#include <WiFi.h>
#define BUTTON_PIN 5
#define PIR_PIN 4
#define LED_PIN 2
volatile bool buttonPressed = false;
volatile bool motionDetected = false;
unsigned long lastMotion = 0;
// ISRs -- keep SHORT, just set flags
void IRAM_ATTR buttonISR() { buttonPressed = true; }
void IRAM_ATTR motionISR() { motionDetected = true; lastMotion = millis(); }
void setup() {
Serial.begin(115200);
pinMode(BUTTON_PIN, INPUT_PULLUP);
pinMode(PIR_PIN, INPUT);
pinMode(LED_PIN, OUTPUT);
attachInterrupt(digitalPinToInterrupt(BUTTON_PIN), buttonISR, FALLING);
attachInterrupt(digitalPinToInterrupt(PIR_PIN), motionISR, RISING);
WiFi.begin("YourSSID", "YourPassword");
}
void loop() {
if (buttonPressed) {
buttonPressed = false;
digitalWrite(LED_PIN, HIGH);
Serial.println("ALERT: Doorbell pressed!");
digitalWrite(LED_PIN, LOW);
}
if (motionDetected) {
motionDetected = false;
Serial.printf("Motion at: %lu\n", millis());
delay(5000); // Debounce
}
// Deep sleep after 30s idle (200mA -> 10mA)
if (millis() - lastMotion > 30000) {
esp_sleep_enable_ext0_wakeup(GPIO_NUM_5, 0);
esp_deep_sleep_start();
}
delay(100);
}Key Techniques Demonstrated:
loop() checks flags, doesn’t wait for eventsTesting Results:
| Event | Response Time | Current Draw |
|---|---|---|
| Button press | <10 ms (instant) | 200 mA (active) |
| Motion detect | <50 ms | 200 mA (active) |
| Idle (awake) | - | 80 mA (WiFi on) |
| Deep sleep | - | 10 μA |
Battery Life Calculation:
Assuming 2000 mAh battery, 10 events per day (20 seconds active each):
Active time: 10 events × 20 s = 200 s/day = 0.056 hours
Active energy: 200 mA × 0.056 h = 11.2 mAh/day
Sleep time: 24 h - 0.056 h = 23.944 hours
Sleep energy: 0.01 mA × 23.944 h = 0.24 mAh/day
Total: 11.2 + 0.24 = 11.44 mAh/day
Battery life: 2000 mAh / 11.44 mAh = 175 days (~6 months)Lessons:
| Scenario | Use Interrupts | Use Polling | Rationale |
|---|---|---|---|
| Button press detection | ✓ Yes | Maybe | Interrupts guarantee instant response; polling might miss fast presses |
| Sensor read every 10 seconds | No | ✓ Yes | Polling with millis() is simpler; no need for interrupt overhead |
| Emergency stop signal | ✓ Yes | No | Safety-critical: must respond within microseconds |
| UART data arrival | ✓ Yes | Maybe | Interrupt prevents data loss; polling works if checking frequently |
| I2C sensor read | No | ✓ Yes | I2C libraries handle communication; no interrupt needed |
| Multiple fast events (>100 Hz) | ✓ Yes (with queue) | No | Polling can’t keep up; interrupts with FIFO queue required |
| Low-power sleep/wake | ✓ Yes | No | Only interrupts can wake from deep sleep |
| Simple blink LED | No | ✓ Yes | Polling with millis() is cleaner for non-critical timing |
Decision Tree:
Q1: Is the event unpredictable and rare (<1% of time)?
├─ YES: Is response time critical (<10 ms)?
│ ├─ YES: Use interrupts
│ └─ NO: Consider polling (simpler)
└─ NO: Event is frequent or periodic
└─ Use polling with millis()
Q2: Does the device need to sleep for power savings?
└─ YES: Use interrupt for wake-up eventInterrupt Use Cases:
| Use Case | Why Interrupt is Better |
|---|---|
| Doorbell button | Instant response, no polling waste |
| Emergency stop button | Safety-critical, <1 ms response |
| Rotary encoder | Fast pulses (100-1000 Hz) would be missed by polling |
| UART RX | Data arrives asynchronously, must capture immediately |
| External RTC alarm | Wakes MCU from deep sleep |
| Zero-crossing detector (AC) | Precise timing for TRIAC control |
Polling Use Cases:
| Use Case | Why Polling is Better |
|---|---|
| Temperature read every 60s | Scheduled task, no urgency |
| Display update | Main loop handles refresh timing |
| State machine transitions | Logic-driven, not event-driven |
| Analog sensor averaging | Need multiple samples over time |
| Network communication | Libraries handle protocol, polling checks status |
Hybrid Approach:
Best practice: Use interrupts for urgent events, polling for periodic tasks:
volatile bool urgentFlag = false;
void IRAM_ATTR urgentISR() {
urgentFlag = true; // Set flag only
}
void loop() {
// Handle urgent interrupt
if (urgentFlag) {
urgentFlag = false;
handleUrgentEvent(); // Heavy processing in main loop
}
// Poll periodic tasks
static unsigned long lastRead = 0;
if (millis() - lastRead >= 1000) {
lastRead = millis();
readSensor();
}
}Key Insight: Interrupts are for reacting, polling is for scheduling.
The Mistake: A developer writes an ISR that reads a sensor, processes data, formats a string, and prints to serial. The device becomes unresponsive and crashes randomly.
Bad Code:
void IRAM_ATTR buttonISR() {
// WAY TOO MUCH WORK IN ISR!
float temp = dht.readTemperature(); // 2 seconds blocking!
char message[100];
sprintf(message, "Button pressed! Temp: %.1f C", temp);
Serial.println(message); // Slow serial I/O
// Even worse: network call
sendMQTTMessage("button/pressed", message); // 100+ ms!
}Why It’s Broken:
Consequences:
The Fix: Top-Half/Bottom-Half Pattern
Good Code:
// TOP HALF: ISR only sets flag (microseconds)
volatile bool buttonPressed = false;
void IRAM_ATTR buttonISR() {
buttonPressed = true; // 1 microsecond
}
// BOTTOM HALF: Main loop does heavy work
void loop() {
if (buttonPressed) {
buttonPressed = false;
// Safe to do slow operations in main loop
float temp = dht.readTemperature();
char message[100];
sprintf(message, "Button pressed! Temp: %.1f C", temp);
Serial.println(message);
sendMQTTMessage("button/pressed", message);
}
delay(10);
}ISR Golden Rules:
✅ ALLOWED in ISR: - Set/clear flags (volatile bool) - Increment counters (volatile uint32_t count++) - Read hardware registers (GPIO.in) - Store timestamp (volatile unsigned long time = millis())
❌ FORBIDDEN in ISR: - delay() or any blocking call - Serial.print() (too slow) - Sensor reads (DHT, I2C, SPI—all slow) - Network operations (WiFi, MQTT, HTTP) - malloc() / new (heap allocation) - Floating-point math (slow on some MCUs) - Long loops (for(int i=0; i<1000; i++))
Quantified Impact:
| Operation | Time in ISR | Consequence |
|---|---|---|
| Set flag | 1 μs | ✓ Safe |
| Read GPIO | 1 μs | ✓ Safe |
| Serial.print() 10 chars | 870 μs | ⚠ Risky (short messages OK) |
| DHT22 read | 2,000,000 μs (2 s!) | ✗ Crash |
| MQTT publish | 100,000 μs (100 ms) | ✗ Crash |
ESP32 Specific:
ESP32 has dual-core architecture. On core 0, WiFi stack runs constantly. Long ISRs on core 1 can starve WiFi, causing disconnections:
// Mark ISR for fast RAM execution
void IRAM_ATTR fastISR() {
// Only code in IRAM, no flash access
GPIO.out_w1ts = (1 << LED_PIN); // Set LED
}Real-World Example:
Smart doorbell with 2-second ISR (reading temperature) caused: - 15% of button presses ignored (watchdog reset during ISR) - WiFi disconnection every 30 minutes (stack timeout) - 3-star Amazon reviews: “Doorbell misses button presses”
After fix (flag-only ISR): 100% button press detection, zero WiFi issues, 5-star reviews.
Key Takeaway: ISRs should take <100 μs. Anything longer moves to main loop!
| Concept | Key Points |
|---|---|
| Program Structure | setup() runs once, loop() runs forever |
| GPIO | Configure with pinMode(), read/write with digitalRead()/digitalWrite() |
| Analog Input | Use analogRead(), values depend on ADC resolution |
| Serial | Essential for debugging; use Serial.begin(), print(), println() |
| Timing | Avoid delay(); use millis() for non-blocking code |
| Interrupts | Use for time-critical events; keep ISR short |
The following AI-generated visualizations provide alternative perspectives on microcontroller programming concepts.
Understanding Arduino pin capabilities ensures correct hardware connections and prevents conflicts between peripherals.
The interrupt vector table maps interrupt sources to their handlers, enabling rapid response to hardware events without polling.
Direct register access provides maximum control over microcontroller peripherals, enabling optimization beyond what library functions allow.
Microcontroller Programming
├── Builds on: [Electronics Basics](../electronics/electricity-introduction.html) - Voltage, current, GPIO fundamentals
├── Uses: [Analog-Digital Electronics](../electronics/analog-digital-electronics.html) - ADC for analog sensor reading
├── Applies: [Sensor Fundamentals](../sensors/sensor-fundamentals-and-types.html) - Physical sensors being programmed
├── Enables: [Prototyping Hardware](prototyping-hardware.html) - Physical implementation of concepts
└── Optimizes with: [Energy-Aware Considerations](../energy-power/energy-aware-considerations.html) - Power management patternsKey Programming Patterns:
| If you want to… | Read this |
|---|---|
| Learn wireless communication protocol integration | Programming Paradigms and Tools |
| Understand power management for battery prototypes | Power Management |
| Explore debugging and testing techniques | Programming Best Practices |