Embedded Programming

What is Embedded Programming?

Embedded programming is the process of writing firmware that runs on a microcontroller or microprocessor to control hardware components and perform specific tasks. It enables the system to read inputs from sensors, process data, and control outputs such as motors, LEDs, and displays, operating continuously with limited memory and power resources.

During Week 4 of Fab Academy, we dived deep into microcontrollers, explored different programming languages, and wrapped up with a series of assignments.

Comparing Toolchains and Workflows

As a lab we compared the toolchains and development workflows for the embedded architectures we had on hand. The full write up lives on our group assignment page. Here is what I took from it and how it shaped the path I chose for my own work.

We looked at three ways to write and flash firmware for an ESP32: the Arduino IDE, ESP-IDF, and PlatformIO. They all end up talking to the same chip, but they feel very different to use and they trade ease of use against control.

The pattern is clear. The Arduino IDE trades control for speed, ESP-IDF trades speed for control, and PlatformIO sits in the middle with proper project files and dependency tracking. Because my goal this week was to interact and communicate fast, I started in the Arduino IDE and the Wokwi simulator, which both use the Arduino core. As ORDER, my final project, grows I plan to move into PlatformIO so the build stays the same on every machine in the lab.

What I pulled from the datasheet for programming

I read through the ESP32 datasheet and pulled out the parts that actually change how I write code and wire pins. This is my quick reference for the rest of the embedded weeks.

The numbers that matter

GPIO rules I have to respect

• Do not touch GPIO6 to GPIO11. They are wired to the internal SPI flash. Using them stops the chip from booting.
• Input only pins: GPIO34, 35, 36, 37, 38, 39. They can read but cannot drive an output, and they have no internal pull up or pull down. They are great for a sensor or an analog input, never for an LED.
• Strapping pins: GPIO0, GPIO2, GPIO5, GPIO12, GPIO15. Their level at reset sets the boot behaviour, so I use them carefully. GPIO12 is the worst one to get wrong because a pull up at boot can set the flash to the wrong voltage and stop it booting.

Analog and touch pins

• ADC1: GPIO32 to GPIO39. These keep working while WiFi is on, so I read sensors here.
• ADC2 pins clash with WiFi. If WiFi is running, analogRead on an ADC2 pin fails, so I avoid them for analog when the radio is on.
• Real analog out (DAC): GPIO25 and GPIO26.
• Touch pins: GPIO0, 2, 4, 12, 13, 14, 15, 27, 32, 33.

Default pins for talking to things

The pins above are the common defaults. The ESP32 has a GPIO matrix, so most buses can be moved to other pins in code, as long as I avoid the flash pins and the input only pins.

How flashing actually works

GPIO0 decides the boot mode at reset. Held low it enters download mode so a new program can be written over UART, released high it just runs the program already in flash. That is exactly what the BOOT button does, and the EN pin (CHIP_PU) is the reset. So the flashing dance is: hold BOOT, tap EN, upload, release BOOT.

ESP32 Blink LED

Using Wokwi, a browser-based circuit simulator, to prototype the classic blink LED without any physical hardware. Follow along step by step:

01

Sign up on Wokwi, then click Create New Project

Wokwi, Create New Project screen

02

Select ESP32 as the target microcontroller board

Selecting the ESP32 board

03

Started testing with the built-in LED, but LED_BUILTIN is a reserved keyword and caused a conflict

Attempting to use the LED_BUILTIN keyword

04

Defined a custom pin variable to replace the reserved keyword and resolved the conflict

Updated code with a custom pin definition

05

Drew the full circuit schematic inside the Wokwi workspace

Circuit schematic, drawing phase

06

Added a protection resistor, even though ESP32 pin current is limited, this is best practice for circuit safety

Complete circuit with protection resistor

07

Full Working Demonstration, the LED blinks as programmed

The ESP32 wired to the red LED on GPIO12 in Wokwi

ESP32 Blink, live simulation demo

08

The full code I used. You can copy it and paste it straight into the Arduino IDE or Wokwi. I gave my LED pin its own name so it does not clash with the reserved keyword.

blink.inocopy

// ESP32 blink, my own pin name so LED_BUILTIN does not clash
int ledPin = 2;

void setup() {
  pinMode(ledPin, OUTPUT);
}

void loop() {
  digitalWrite(ledPin, HIGH);
  delay(1000);
  digitalWrite(ledPin, LOW);
  delay(1000);
}

Arduino with Tinkercad

Arduino is a beginner-friendly microcontroller with great input/output support, though it lacks built-in wireless connectivity. Inputs, push buttons, temperature sensors, light sensors, soil moisture sensors, let it sense the environment. Outputs, LEDs, motors, relays, buzzers, displays, let it respond and act.

By processing input data through programmed logic and generating appropriate outputs, Arduino can automate systems for robotics, home automation, and smart agriculture. For this section we used Tinkercad, a browser-based simulator by Autodesk.

01

Opened Tinkercad and started with a fresh circuit workspace

Getting started with Tinkercad

02

Searched for and added the Arduino board to the workspace

Searching and adding the Arduino board

03

Added remaining components, resistor, battery, LED, and push button

Adding resistor, battery, LED, and button

04

Wired all components together following the circuit diagram

Components being connected

05

Circuit fully connected and verified

Fully connected circuit

06

Labelled the circuit for clarity before writing code

Labelled and annotated circuit

The complete Tinkercad circuit, Arduino UNO with an LED, a button and a 9V battery

07

Writing the Code, programmed the button input and LED output logic in C++

Writing the Arduino code in Tinkercad

08

Simulation, ran the simulation and adjusted the resistor value because the LED brightness was too low

Final simulation with corrected resistor value

Conclusion

Talking Back Over Serial

Blinking an LED is the board interacting with the world through a local output. The next step the assignment asks for is to communicate, so the board sends data off the chip and not only flips a pin. The simplest path is the serial port over the USB cable. I started the serial line at 115200 baud and printed a counter once a second, so I could watch the board talk in the Serial Monitor while the same loop kept the LED blinking. This is wired communication.

This is the same sketch as the blink, with the serial calls added. Copy it into the Arduino IDE or Wokwi, then open the Serial Monitor at 115200 baud to see the messages.

// ESP32 interact and communicate
// the LED is the local output, Serial is the wired link back to my computer
int ledPin = 2;
int blinkCount = 0;

void setup() {
  pinMode(ledPin, OUTPUT);
  Serial.begin(115200);
  Serial.println("ESP32 is awake and listening");
}

void loop() {
  digitalWrite(ledPin, HIGH);
  delay(1000);
  digitalWrite(ledPin, LOW);
  delay(1000);

  blinkCount = blinkCount + 1;
  Serial.print("Blink number ");
  Serial.println(blinkCount);
}

Serial over USB is the wired link. The reason I picked the ESP32 in the first place is that it also carries the wireless path I need for ORDER. The same chip does WiFi (802.11 b/g/n) and Bluetooth Low Energy, so later weeks the board will send orders over WiFi instead of a cable. The serial print I run here is the first rung of that ladder. I prove the board can talk on the wire now, then move the same idea onto WiFi and BLE when the project needs it.