How to Program a Microcontroller: ESP32 Timers, I2C, and Bare Metal

Programming a microcontroller is the process of writing compiled instructions that directly manipulate hardware registers to control physical pins, timers, and peripherals in real time. Unlike coding for a desktop OS, writing embedded firmware changes the actual voltage states and timing edges on a physical circuit board, dictating exactly when a MOSFET switches or a sensor is polled. Beginners commonly confuse programming a microcontroller with writing software for a microprocessor (like a Raspberry Pi running Linux); the critical difference is that a microcontroller has no underlying operating system to manage memory or catch crashes, meaning your code is the operating system.

The Core Loop: What Programming Actually Changes

When you learn how to program a microcontroller, you are essentially learning to map software logic to physical silicon. On a desktop, writing a variable to memory just updates a virtual address space managed by the OS. On an ATmega328P with 32KB Flash and 2KB SRAM, writing to a specific memory address might toggle the physical state of Port B, Pin 5, driving an LED high.

Modern frameworks like Arduino or ESP-IDF provide a Hardware Abstraction Layer (HAL). When you call digitalWrite(HIGH), the HAL translates that command into a bitwise operation on a memory-mapped I/O register. However, to write robust firmware, you must understand what happens beneath the HAL:

• Clock Domains: Your code executes at the mercy of the system clock (e.g., 240 MHz on an ESP32). If you change the CPU frequency to save power, your software-based delay loops will break unless you use hardware timers.
• Interrupt Latency: When a physical pin changes state, an Interrupt Service Routine (ISR) pauses your main loop. If your ISR takes too long to execute, you will drop incoming UART bytes or miss encoder pulses.
• Memory Constraints: There is no garbage collection. Every byte of SRAM you allocate for a buffer is a byte stolen from the stack. Exceeding SRAM limits causes a stack collision with the heap, resulting in an immediate, unrecoverable crash.

Where You Meet This in Practice

You will encounter the direct hardware-to-code relationship in almost every embedded project, but it becomes critical in three specific scenarios:

1. Motor Control and PID Loops: If you are driving a BLDC motor, your code must read the hall-effect sensors and commutate the phases within microseconds. A software delay caused by a blocking Wi-Fi call will cause the motor to stall or draw destructive stall current.
2. Low-Power Battery Nodes: In a remote LoRaWAN sensor node, you cannot just put a delay(60000) in your loop. You must program the microcontroller to configure the Real-Time Clock (RTC) peripheral, shut down the main CPU domain, and enter deep sleep, dropping current draw from 80mA to 10µA.
3. High-Speed Data Acquisition: Reading an ADC via software polling is too slow for audio or vibration analysis. You must program the Direct Memory Access (DMA) controller to move ADC samples directly into SRAM without CPU intervention.

Worked Numeric Example: Sizing an ESP32 PWM Timer

Let’s look at a concrete example of how to program a microcontroller's hardware timer. Suppose you need to drive a 4-pin PC cooling fan using the ESP32-WROOM-32’s LEDC (LED Control) peripheral. PC fans require a 20 kHz PWM signal, and you want a 10-bit resolution (0 to 1023) for fine-grained speed control.

The ESP32’s APB (Advanced Peripheral Bus) clock typically runs at 80 MHz (80,000,000 Hz). The LEDC frequency formula is:

Frequency = APB_Clock / (2^resolution × divider)

We need to solve for the integer divider:

• Target Frequency: 20,000 Hz
• Resolution Steps: 2^10 = 1024
• Divider = 80,000,000 / (20,000 × 1024)
• Divider = 80,000,000 / 20,480,000 = 3.90625

Because the hardware timer divider must be an integer (in standard ESP-IDF configurations), we round to 4. Let’s calculate the actual resulting frequency:

Actual Freq = 80,000,000 / (1024 × 4) = 19,531.25 Hz.

This is 19.53 kHz, which is well within the acceptable tolerance for a standard PC fan. To set the fan to 50% speed, you program the duty cycle register to half of your resolution steps: 1024 / 2 = 512. According to the Espressif LEDC API documentation, configuring these exact timer parameters ensures the hardware generates the waveform autonomously, freeing the CPU to handle network tasks without jittering the PWM signal.

Real-World Scenario Walkthrough: The I2C Bus Lockup

Theory is clean; the workbench is messy. Here is a classic failure mode that occurs when physical circuit realities collide with software assumptions.

The Setup: You are building a weather station using an ESP32 and a BME280 environmental sensor communicating over I2C. You write a simple loop to poll the sensor every 2 seconds and transmit the data over Wi-Fi.

The Numbers: The I2C bus is configured for Fast Mode (400 kHz clock). You rely on the ESP32’s internal weak pull-up resistors (approximately 30 kΩ) on the SDA and SCL lines, omitting external resistors to save BOM cost.

The Outcome: The system runs flawlessly on your desk for three hours. When you move it near a refrigerator compressor, the ESP32 freezes entirely. The serial monitor stops printing, and the board requires a hard physical power cycle to recover.

What Went Wrong: Electromagnetic interference (EMI) from the compressor induced a voltage spike on the I2C lines. Because the 30 kΩ internal pull-ups were too weak to quickly pull the bus back to 3.3V against the parasitic capacitance of the wires, the SDA line was momentarily pulled low. The BME280 interpreted this as a start condition and held the line low, waiting for a clock pulse. The ESP32’s default I2C library entered an infinite while() loop waiting for the bus to clear. Without a software timeout, the CPU hung forever.

Common Confusions: Microcontrollers vs. Microprocessors

Understanding how to program a microcontroller requires unlearning habits from desktop software development. The most common point of confusion is treating a microcontroller like a microprocessor.

If you try to run a tight, software-timed bit-banging loop to read a specialized sensor on a Raspberry Pi, the Linux kernel will preempt your thread to handle network interrupts, ruining your timing. On an ESP32, you can disable interrupts entirely for 50 microseconds, bit-bang the protocol perfectly, and re-enable them—a technique that would crash a Linux system.

FAQ: Debugging Your First Embedded Code