Skip to content

4. Embedded Programming

Weekly Assignment:

Group assignment:

  • Demonstrate and compare the toolchains and development workflows for available embedded architectures

Individual assignment:

  • Browse through the datasheet for your microcontroller
  • Write a program for a microcontroller, and simulagte its operation, to interact (with local input &/or output devices) and communicate (with remote wired or wireless connection)
  • Extra credit: test it on a development board
  • Extra credit: try different languages &/or development environments

XIAO ESP32C3

Wokwi Simulation

Wednesday night, Mr. Dubick had the lab a presentation about the week. He covered troubleshotting, giving us two guides: the ESP 32 Microcontroller Troubleshooting Guide and RP2040 Microcontroller Troubleshooting Guide.

He also explained to us a pull down resistor simulation assignment to be done using Wokwi. A pull down resistor is so that if the sensor reads 1, it turns the light on. It should only register 1 or 0, not somewhere in between. Pull downs are always connected to ground, so always at 0. When power switches because of the button, the current can go either way, but because of the 10k resistor, it goes to 1. Conversely, a pull up resistor would be one that is always set to 1 and switches to 0.

For the simulation, I used a XIAO-ESP32-C3 chip. [This](pull down resistor simulation](https://www.tinkercad.com/things/4XVcShB6Uss-button-pull-down-resistor?authuser=0) was the basic Arduino template for pull down resistors found on TinkerCAD that I referenced. On the right hand panel, at the top where its default set to Basic Components, I went under Starters Arduino and then Button.

On Wokwi, I found a basic template with the ESP32-C3 chip that I edited for the pull down simulation.

This was the pinout sheet I used to do my wiring.

As per usual, something was going wrong and I did not know how to proceed. I was pretty confident with my first iteration of the wiring, having figured out the GPIO2 pin that I needed.

However, when I tried to simulate it, it failed with many errors. Here is a pdf of the ChatGPT conversation in which I figured out the wiring and code. It had me add another 330 kΩ resistor for the LED.

This was the final code Chat gave me:

int buttonPin = D1;  // Button connected to GPIO 2
int ledPin = D10;    // LED connected to GPIO 10

void setup() {
  pinMode(buttonPin, INPUT);  // Button as input (pull-down handled externally)
  pinMode(ledPin, OUTPUT);    // LED as output
}

void loop() {
  int buttonState = digitalRead(buttonPin); // Read button state

  if (buttonState == HIGH) {  // Button pressed
    digitalWrite(ledPin, HIGH); // Turn LED on
  } else {
    digitalWrite(ledPin, LOW);  // Turn LED off
  }

  delay(10); // Small debounce delay
}

Cooper Cumbus helped me realize that when I define my pins, I should make it D1 instead of just 1 because I am using the digital pins. With his advice, mines worked!

Here is a public link to my project.

I made a breakthrough about video code. I didn't need to keep it in docs (it also looks really bad that way) I just needed to have it in images and keep the ../../ part in front. Thanks to Angel Fang for helping me finally realize this.

Arduino

At first, I was having trouble with my wiring. And then, Angel came in as an absolute angel true to her name and helped me rearrange the board. In my original wire assembly, I had rotated the button 90 degrees because I had limited room. She pointed out how it should remain horizontal and we moved the button lower so that there would be enough room. And behold, she got it to work.

My documentation for the rest of this section is the same as what I did in my section for my group project, found here.

MicroPython

Just like for Arduino, this section's documentation is found below where I recorded my group project here.

XIAO RP2040

I read through the datasheet and the Seeed Studio introduction and made my own simplified chart about the chip.

Feature RP2040
Dimensions 21×17.8×3.5mm
Architechture Dual-core ARM Cortex M0+
CPU Speed up to 133MHz
Flash Size 2MB
SRAM 264KB
Digital pins 11
Analog pins 4
PWM pins 11
Power 3.3V/5V DC
Debugging SWD (Serial Wire Debug)

Wokwi Simulation

There is no RP2040 model, so I used the Raspberry Pi, which functions the same way. Angel let me know this and helpedmkd me find the model.

This is the Raspberry Pi Pico pinout I used and the wiring of my simulation on Wokwi.

After all the rearranging I had to do for the ESP32, I decided to make my wiring on Wokwi with consideration of how it might actually be on my breadboard, thinking about spacing and orientation. This was my code:

from machine import Pin
import time

# Define pins
buttonPin = Pin(3, Pin.IN, Pin.PULL_DOWN)  # GP3 as input with internal pull-down
ledPin = Pin(5, Pin.OUT)  # GP5 as output for LED

while True:
   if buttonPin.value() == 1:  # Button is pressed (GP3 goes HIGH)
       ledPin.value(1)  # Turn LED on
   else:
       ledPin.value(0)  # Turn LED off

   time.sleep(0.05)  # Small delay for stability

But I encountered an issue when I tried to simulate it and it would not compile, eventually giving me a build server failure error message.

I asked chat and it told me that it might have been a conflict because I was running the code on arduino and not Micropython when I was using MicroPython code. This was the ChatGPT Conversation.

That checked out because the end of the title of the template was .ino. Thinking back, the arduino model I was using was the traffic light from the templates and I had not taken it from a specific MicroPython example sub section.

So I went into Blink and recreated everything using the exact same wiring and code. I knew it was right because the name of this template was “Blink with MicroPython” and it ended with .py.

Arduino

Once I moved into the breadboard, I needed to switch to the XIAO-RP2040 pins, and also Arduino C++ as my code. This was the pinout I used.

I changed the corresponding pins I wanted to use in my code. However, I ran into more code discrepancies when I uploaded it.

This time, it had to do with the way I defined my pins in the code chat gave me. It had an overarching # Define pins when it should have been 

# define buttonPin = Pin(29, Pin.IN, Pin.PULL_DOWN)  # GP3 as input with internal pull-down
# define ledPin = Pin(1, Pin.OUT)  # GP5 as output for LED

This was the final code I used to program using Arduino. 

int buttonPin = D3;  // button connected to pin 1
int ledPin = D5;    // LED connected to pin 2

void setup() {
  pinMode(buttonPin, INPUT);  // Set button pin as input (no internal pull-up resistor used)
  pinMode(ledPin, OUTPUT);    // Set LED pin as output
}

void loop() {
  int buttonState = digitalRead(buttonPin);  // Read the button state

  if (buttonState == HIGH) {  // Button is pressed (LOW with pull-down resistor)
    digitalWrite(ledPin, HIGH);  // Turn LED on
  } else {
    digitalWrite(ledPin, LOW);   // Turn LED off
  }
}

Like before, I needed to use the corresponding D_ pins because Arduino uses digital pins.

Then I uploaded the code to the RP2040, and it worked on the breadboard!

Micropython

The extent of the difference between Micropython and C++ that I knew of before this was that Micropython registers the button as 1 and 0 while C sees if its high or low. Mr. Dubick clarified that it was mostly a question of preference, but also that MicroPython allows the more powerful RP2040 chip to do more powerful things.

I followed this guide from Seeed Studio.

I downloaded Thonny version 4.1.7 for Mac OS. I went into Tools → Options → Interpreter and chose MicroPython(Raspberry Pi Pico) as the device and "try to detect port automatically" as the port.

To connect the RP2040 to my MAC, I needed to hold down the B (for BOOT) button while plugging it into my Mac.

Back in the Interpreter tab, select "Install or update MicroPython" and another window pops up. I selected family and version like so.

I then clicked install and pasted this code 

from machine import Pin, Timer

led = Pin(25, Pin.OUT)
Counter = 0
Fun_Num = 0

def fun(tim):
   global Counter
   Counter = Counter + 1
   print(Counter)
   led.value(Counter%2)

tim = Timer(-1)
tim.init(period=1000, mode=Timer.PERIODIC, callback=fun)

and hit the green play button to run it. The built-in LED of my ESP32-C3 started blinking once per second, either blue or green. I can't tell because it's alternating. In shell, there should be a list of numbers constantly increasing by 1.

Now, to light up my red LED using MicroPython. It requires a third-party library so I needed to add that first. I downloaded the ws2812.py library and opened it in Thonny (Command+O). Click "File → Save as" to save the library, but this time choose Raspberry Pi Pico as the location

Note: the file name must be exactly ws2812.py for it to work

I then used this code in Thonny

from ws2812 import WS2812
import utime
import machine
power = machine.Pin(11,machine.Pin.OUT)
power.value(1)
BLACK = (0, 0, 0)
RED = (255, 0, 0)
YELLOW = (255, 150, 0)
GREEN = (0, 255, 0)
CYAN = (0, 255, 255)
BLUE = (0, 0, 255)
PURPLE = (180, 0, 255)
WHITE = (255, 255, 255)
COLORS = (BLACK, RED, YELLOW, GREEN, CYAN, BLUE, PURPLE, WHITE)

led = WS2812(12,1)#WS2812(pin_num,led_count)

while True:
    print("Beautiful color")
    for color in COLORS: 
        led.pixels_fill(color)
        led.pixels_show()
        utime.sleep(0.2)

I ran it and it did what it was supposed to! The bigger led on the other side lit up in many colors, as expected. And in shell, it said “Beautiful color.”

With that working, I next tried using the MicroPython code to do what I originally wanted to do: light up the LED with the button. I used the following code.

from machine import Pin
import time

# Define pins
buttonPin = Pin(3, Pin.IN, Pin.PULL_DOWN)  # GP3 as input with internal pull-down
ledPin = Pin(5, Pin.OUT)  # GP5 as output for LED

while True:
   if buttonPin.value() == 1:  # Button is pressed (GP3 goes HIGH)
       ledPin.value(1)  # Turn LED on
   else:
       ledPin.value(0)  # Turn LED off

   time.sleep(0.05)  # Small delay for stability

And again, it didn't work at first. I realized it was because of the pin numbers I was using. Just as the digital pin had to be D_, I had to use the Micropython pin numbers. Instead of 3 and 5, it should be 29 and 7, respectively.

# Define pins
buttonPin = Pin(29, Pin.IN, Pin.PULL_DOWN)  # GP3 as input with internal pull-down
ledPin = Pin(7, Pin.OUT)  # GP5 as output for LED

AND THEN IT WORKED!!!

Group Assignment:

The group assignment this week was to demonstrate and compare the toolchains and development workflows for available embedded architectures. I worked with Tyler Russel and Amalia Bordoloi to cover the ESP32-C3, ATTiny412, and RP2040 microcontrollers. You can access our documentation here.

Individual Contribution -- ESP32C3

Note: Everything performed in this section was done using Mac OS

I worked on the ESP32C3 and read through the datasheet.

Feature ESP32-C3
Chip ESP32-C3
Architechture RISC-V, 32-bit
CPU Speed Up to 160 MHz
Flash Size 4 MB (embedded flash)
RAM 4 MB (embedded flash)
Wireless Connectivity Wi-Fi 4 (802.11 b/g/n) / Bluetooth 5.0 (BLE)
GPIO Pins 22 (max)
GPIO Voltage 3.3V
Operating Voltage 3.0V-3.6V
Power Supply 3.3V (required)
PWM Up to 16 channels
Debugging JTAG, UART

At first, I was very confused about what a toolchain was, and this basic introduction was helpful. To understand the ESP-IDF toolchain, I looked through the ESP32-C3 Datasheet, the Technical Reference Manual, and Espressif Documentation for ESP-IDF. For Arduino, I referenced its GitHub and a toolchain overview. Overall though, I was already familiar with Arduino, having used it often in the past.

Toolchain Comparison

Feature ESP-IDF Arduino-ESP32
Language Support C, C++ C++ (Arduino API)
Build System CMake, Ninja Arduino IDE/PlatformIO
Operating System FreeRTOS Bare-metal
Debugging OpenOCD, GDB Serial print debugging
Environment Setup Complexity High (ESP-IDF, toolchain, Python dependencies) Low (Arduino IDE, PlatformIO)
Ease of Use Advanced (Requires CLI & CMake knowledge) Beginner-friendly (Simple IDE)
Memory Management Full control over memory, RTOS heap Automatic
Board Support Full ESP32 support (all features) Limited to common ESP32 functionalities
Code Portability High (Works with other ESP-IDF-supported chips) Medium (Limited to Arduino ecosystem)
Extensibility Highly customizable Limited to Arduino framework constraints
Built-in Libraries Espressif official libraries Large Arduino and third-party libraries
Hardware Abstraction Low (configuring drivers required) High (simpler GPIO, PWM handling)
Power Efficiency Advanced power management Basic sleep functions
Peripheral Support Full access to ESP32-C3 peripherals Limited (some advanced peripherals not supported)
WiFi/Bluetooth API Advanced Simplified API
Debugging Support OpenOCD, JTAG, ESP32 debugging tools Basic Serial Monitor
Flashing Method idf.py flash (CLI) One-click "Upload" in Arduino IDE
Serial Monitor idf.py monitor Built-in Arduino Serial Monitor
Security Features Secure Boot, Flash, Encryption, etc. support Minimal security features
Community Support Espressif official forums, GitHub Large Arduino user community
Recommended For Advanced IoT, RTOS Quick prototyping
Project Types Industrial, commercial, complex Hobbyist, maker

Personally, after looking through the comparative, I started to lean towards ESP-IDF. For the same reasons I erred towards MKDocs, it being hard to set up but better to use than HTML most of the time, I did see the light in ESP-IDF. But as all things are, it really just depends on what you want to do.

These are my main takeaways:

Use ESP-IDF if you need fine-grained control, advanced control over features, and optimized performative for professional/complex applications. Also if you want advanced debugging tools with OpenOCD and JTAG. The tradeoff includes a more complex setup and more manual configuration.

Use Arduino if you need a quick, easy way to develop simple applications without worrying about low-level configurations. It offers easily used API for GPIO, WiFi, and Bluetooth. There is a large libarary ecosystem and cross-compatibility with existing Arduino projects.

Development Workflows

To compare their development workflows, I just pulled from my prevously documented experience programming through both.

Workflow Section Arduino (C/C++) MicroPython (Python)
Project Setup Arduino IDE or PlatformIO Install MicroPython firmware on the microcontrolelr
Writing Code C/C++ with Arduino libraries; .ino files Python; .py files
Compiling Compiled into machine code using compilers None
Uploading Binary is uploaded through USB or programmer flashed first, then scripts are uploaded directly
Execution runs setup() function once then repeatedly runs the loop() function Python starts running immediately after reset or power-on

Arduino

Development Environment Setup:

  1. Download and install the Arduino IDE from the Arduino Website
  2. Open Arduino IDE → Preferences and add the ESP32 board URL
  3. Go to Tools → Board → Boards Manager, search for ESP32 by Espressif, and install it
  4. Select the ESP32-C3 Board in Tools → Board → esp32 → XIAO_ESP32C3
  5. Select the correct COM port under Tools → Port

Write and Compile Code:

  1. Write some code in the Arduino C++ language. For example, a basic blink example (you could also go to File → Examples → 01.Basics → Blink)
void setup() {
    pinMode(2, OUTPUT);  // Configure GPIO2 as an output
}
void loop() {
    digitalWrite(2, HIGH);  // Turn LED on
    delay(500);             // Wait 500ms
    digitalWrite(2, LOW);   // Turn LED off
    delay(500);
}
  1. Compile by clicking the Verify check mark
  2. Upload

This was the pinout sheet I used and my wiring (same for the MicroPython version)

This was the final Arduino C++ code Chat gave me:

int buttonPin = D1;  // Button connected to GPIO 2
int ledPin = D10;    // LED connected to GPIO 10

void setup() {
  pinMode(buttonPin, INPUT);  // Button as input (pull-down handled externally)
  pinMode(ledPin, OUTPUT);    // LED as output
}

void loop() {
  int buttonState = digitalRead(buttonPin); // Read button state

  if (buttonState == HIGH) {  // Button pressed
    digitalWrite(ledPin, HIGH); // Turn LED on
  } else {
    digitalWrite(ledPin, LOW);  // Turn LED off
  }

  delay(10); // Small debounce delay
}

MicroPython

I followed this Seeed Studio Tutorial on getting MicroPython working for XIAO ESP32-C3.

I installed esptool.py using the command prompt pip3 install. I followed these instructions to download the firmware binary file. I was putting micropython on my board for the first time, so i needed to clear everything with esptool.py erase_flash. After downloading the latest .bin file available, version 24.1 for me, I used this prompt:

esptool.py --baud 460800 write_flash 0 <insert full file name.bin>

For me, the file name was not enough for it to work and I repeatedly got an error about the file not existing in my directory. I needed to use the entire file path, so /User/.....bin instead.

Then I flashed my firmware on the specific port I was using. To find all of my available ports, I did ls /dev/tty.*. It should be something like /dev/cu.usbmodem### To flash I used this prompt:

esptool.py --chip esp32c3 --port <port name> --baud 460800 write_flash -z 0x0 <file name/location>

For my editor, I chose to use Thonny because I already had it downloaded from when I did MicroPython for the RP2040. Once I opened it, I went into Run → Configure Interpreter and changed the interpreter and port.

I then used these script lines in Shell:

import gc
gc.mem_free()

import esp
esp.flash_size()

To get the flash and SRAM size

I tried this code first:

from machine import Pin
import time

# Define pins
buttonPin = Pin(2, Pin.IN)  # D2 (GPIO3) as input (external pull-down)
ledPin = Pin(10, Pin.OUT)   # D10 (GPIO10) as output

while True:
    buttonState = buttonPin.value()  # Read button state

    if buttonState == 1:  # Button pressed
        ledPin.value(1)  # Turn LED on
    else:
        ledPin.value(0)  # Turn LED off

    time.sleep(0.01)  # Small debounce delay (10ms)

Then remembered that MicroPython used GPIO pins, so the corresponding pins to D1 and D10 should be GPIO3 and 10, respectively (it was also noted in the comments).

Even though I changed the software, I still faced some issues. The button state in Shell would not register as 1 even when I pressed it. I realized that it was a hardware issue and that my button was not properly connected to power. Once I fixed that, it worked!

The button registered correctly, being at a 0 state when unpressed and 1 when I pressed it.

This was the final code I used:

from machine import Pin
import time

# Define pins
buttonPin = Pin(3, Pin.IN, Pin.PULL_DOWN)  # GPIO3 (D2) with internal pull-down resistor
ledPin = Pin(10, Pin.OUT)  # GPIO10 for LED

while True:
    buttonState = buttonPin.value()  # Read button state
    print("Button state:", buttonState)  # Print button state for debugging

    if buttonState == 1:  # Button pressed (active HIGH due to pull-down)
        ledPin.value(1)  # Turn LED on
    else:
        ledPin.value(0)  # Turn LED off

    time.sleep(0.01)  # Small debounce delay (10ms)

Overview

This week helped me understand toolchains and electronic programming in more depth. At first, I found both toolchains confusing and didn't fully understand what it was, but after researching the ESP-IDF and Arduino, it helped me learn new aspects about the ESP32C3 and jogged my memory on some things I knew, but now saw differently. To generalize, Arduino seemed more begineer-friendly and easy to set up, while ESP-IDF is the opposite in both regards, but has greater functionality. As for the workflows, I was already familiar with the Arduino IDE workflow, having used it a lot in previous engineering classes and for projects. So, where I really learned new things was with MicroPython again. I figured out how to manually flash firmware and use Thonny.

But for both, I realized I had to be careful about the pin numbers I use, D_ for digital pins and the corresponding GPIO pins for MicroPython. I faced hardware and software issues this week. This reminded me to not just sift through the code, but double-check my wiring--if everything is grounded, has power, connected properly on the breadboard, etc. I also faced a port issue, which reinforced a recurring issue where I have to put in my full file-path as opposed to just the name when it typically asks for just a file name.

Overall, I was more worried than I should have been going into this week. I knew electronic programming was one of my weaker skills, but this week actuall went pretty smoothly and most of my struggles can be written off as just oversight. Troubleshooting never took more than an hour and I consider that a win in consideration of the past. I just hope my future encounters with embedded coding go as or more smoothly.

Files

Code Files:

Video Files:

Last update: February 21, 2025