Skip to content

Lecture 01: What is Embedded?

Obuda University -- Embedded Systems

Week 1 | Lectures: bi-weekly | Labs: weekly

Welcome to Embedded Systems

This course is about building a robot -- piece by piece, week by week.

How it works: - Lectures happen every two weeks (Weeks 1, 3, 5, 7, 9, 11) -- concepts, exercises, reflection - Labs happen every week -- hands-on with the robot - Each lecture reflects on completed labs AND previews upcoming labs - Challenge-first approach: try → fail → measure → fix - You will make mistakes. That is the point. Every failure teaches you something a textbook cannot.

By Week 12 you will have a working autonomous robot -- and the engineering mindset to build the next one on your own.

Your Learning Arc

  • Foundation (Weeks 1–2): What is Embedded? ← you are here, GPIO, Sensors
  • Sensing & Signals (Weeks 3–4): ADC, I2C, PWM basics, Ultrasonic
  • Movement & Control (Weeks 5–6): Motor physics, P-control, IMU
  • Software (Weeks 7–8): State Machines, Abstraction
  • Engineering (Weeks 9–10): Software Engineering, Integration
  • Synthesis (Weeks 11–12): Course Synthesis, Demo

How Each Week Works

Lecture (bi-weekly, 45 min) Lab (weekly, hands-on)
Format Concepts, worked examples, exercises Build, test, and debug on the robot
Goal Understand the why and the how Apply it to a real system
Rhythm Reflects on past labs, previews next labs Puts concepts into practice

Lectures provide the theory. Labs provide the practice. Labs run every week -- lectures every other week.

Assessment: - Lab completion each week (did your robot do the thing?) - Demo Day in Week 12 (show what your robot can do and explain your design) - No written exam

Today's Map

Driving question: What makes a system "embedded" -- and why does that change how you think about software?

  1. What is Embedded?
  2. Inside an MCU
  3. SENSE-DECIDE-ACT
  4. The RP2350 Platform
  5. GPIO Basics
  6. From C to MicroPython (and Boot)
  7. Semester Journey
  8. Quick Checks

1. What IS an Embedded System?

Why Embedded Exists

Many products need computation, but with hard physical constraints:

  • Latency: react in milliseconds (or faster)
  • Power: run for long periods on battery
  • Cost/Size: tiny hardware, low unit cost
  • Reliability: predictable behavior for years

Embedded systems are computers designed around these constraints.

The Definition

An embedded system is a computer that exists to control or monitor something else.

"A computer" -- processor, memory, and software inside.

"...that exists to..." -- it has a dedicated purpose.

"...control or monitor something else" -- it serves a larger system.

Key Characteristics

  • Not general-purpose -- does one job, not whatever the user wants
  • Part of something bigger -- the computer serves the product
  • Not exposed as a computing platform -- you interact with the product, not "a computer"
  • Interacts with the physical world -- through sensors and actuators

The Key Question

Is the computer THE product, or is the computer INSIDE the product?

When you buy a laptop, you buy a computer. When you buy a washing machine, you buy a washer (with a computer inside).

The computer is a means to an end, not the end itself.

"Is the computer THE product?"

Product The Computer Is... Embedded?
Laptop THE product (you buy a computer) No
Washing machine INSIDE (you buy a washer) Yes
Car INSIDE (dozens of ECUs, invisible) Yes
Traffic light INSIDE (you see lights, not computers) Yes
Your robot INSIDE (it is a robot, not a computer) Yes

Embedded Systems Are Everywhere

How many embedded systems did you interact with today before class?

Domain Example What It Controls
Your Robot Line follower Motors based on sensors
Home Washing machine Water, drum, heating
Transport Car ECU Fuel injection, timing
Safety Airbag controller Deployment in milliseconds
Medical Pacemaker Heart rhythm

You just don't see them -- and that is the point.

The Embedded Market

bg right:40% contain

Embedded systems span an enormous range: from 8-bit MCUs in a toothbrush to 64-bit SoCs in a car.

Segment Examples Typical MCU Class
Consumer electronics Remote controls, toys 8/16-bit
Industrial PLCs, motor drives 32-bit
Automotive ECUs, ADAS, infotainment 32/64-bit
Medical Pacemakers, infusion pumps 32-bit
IoT / Smart home Sensors, thermostats 32-bit + WiFi

The Embedded Market

What matters for this course:

  • We focus on MCU-based embedded systems (not Linux-class systems)
  • We use MicroPython first for fast iteration and visibility
  • We still compare with C to understand trade-offs and real-time constraints

Why This Course Uses an MCU, Not a Laptop

When you design a product, the first question is: do I need an OS? If the answer is no -- and for most embedded products it is no -- you reach for an MCU. Less power, less cost, deterministic timing.

Our Pico costs EUR4. A Raspberry Pi 4 costs EUR35. That factor-of-nine matters when you ship a million units -- it is the difference between a viable product and a bankrupt company.

Factor MCU (Pico 2) MPU (Raspberry Pi 4)
Unit cost ~EUR4 ~EUR35
Power Milliwatts Watts
Boot time Milliseconds Seconds
Timing Deterministic OS jitter
Needs OS? No Yes

The question is not "which is better" -- it is "what does my product need?" A thermostat needs an MCU. A drone with computer vision needs an MPU. Most of the 30 billion MCUs shipped per year are solving problems that don't need an operating system.

From Definition to Architecture

We now know what an embedded system IS -- a purpose-built computer inside a product.

But what does the computer inside actually look like? A laptop has a CPU, RAM, a hard drive, a GPU -- all separate chips on a motherboard.

An MCU puts everything on one chip. That changes everything.

2. What's Inside an MCU?

The Three Parts of Every MCU

Here is the surprise if you are coming from desktop programming: peripherals are where the real action happens in embedded, not the CPU.

Diagram: MCU internals — CPU, Memory, and Peripherals on one chip. The Peripherals block is the largest.

On a PC, you think about CPU speed and RAM. On an MCU, you think about peripherals. The CPU is a simple Cortex-M33. The magic is in the hardware blocks: PWM generators, ADCs, I2C controllers, DMA engines. They work independently of your code -- while your program sleeps, hardware is still toggling pins, converting voltages, and moving data.

MCU = CPU + Memory + Peripherals

The key difference between an MCU and "just a CPU":

Peripherals are built into the chip.

No need for external memory chips, no need for separate I/O controllers. Everything is on one piece of silicon.

This is what makes microcontrollers small, cheap, and self-contained.

Why Peripherals Matter More Than MHz

bg right:40% contain

An MCU with the right peripheral can outperform a faster MCU using raw CPU speed.

Example: NeoPixel LEDs require precisely timed 800 kHz pulses.

Approach CPU Required Result
Bit-bang in Python 100% busy, cannot hit timing Fails
Bit-bang in C 100% busy, barely works Fragile
Hardware PIO 0% CPU, perfect timing Works

Before adding CPU speed, ask: "Is there a peripheral that does this in hardware?"

Example: DMA lets hardware move data without the CPU.

MCU vs MPU

bg right:40% contain

One of the first decisions in embedded design: what processor do I need?

Class What It Means Typical Use Examples
MCU CPU + RAM + Flash + peripherals on one chip Bare-metal control RP2350, STM32, ESP32
MPU CPU + memory controllers, needs external RAM Embedded Linux i.MX, Raspberry Pi

MCU vs MPU -- Choosing

The question is not "which is better?" but "which fits my constraints?"

Constraint Favors MCU Favors MPU
Power Micro-amps to milliamps Milliamps to amps
Cost 1--10 EUR 10--100 EUR
Real-time Predictable timing OS introduces jitter
Processing Limited compute ML, image processing

Memory Architecture: Von Neumann vs Harvard

bg right:45% contain

Two main memory architectures in MCU design:

Architecture Data & Code Example
Von Neumann Shared memory space Most desktop CPUs
Harvard Separate memory spaces RP2350, most MCUs

Harvard architecture enables simultaneous instruction fetch and data access -- critical for real-time performance.

From Components to Systems

An MCU sitting on a desk does nothing. It has a CPU, memory, and peripherals -- but no purpose.

What turns components into a system is connecting them to the physical world: sensors to observe it, actuators to change it, and software to decide what to do.

How does an MCU interact with the world?

3. The System View: SENSE-DECIDE-ACT

The Fundamental Loop

Every embedded system follows the same pattern:

Diagram: SENSE → DECIDE → ACT, with the physical world feeding back from actuators to sensors in a closed loop.

Your Robot's Loop

  1. SENSE: Optocouplers detect line position
  2. DECIDE: Software calculates motor correction
  3. ACT: Motors turn wheels
  4. Loop: Robot moves, line position changes, sense again

This loop runs continuously -- tens to hundreds of times per second.

If you've written Arduino sketches before, you've been doing this loop already -- setup() and loop() IS sense-decide-act. What this course adds is the engineering rigor around it: how to measure, how to validate, how to handle the cases where it fails.

Closed-Loop Control (Feedback)

Your line-following robot: - Desired state: Stay on the line - Actual state: Robot position on floor - Sensors: Measure position and feed back

Closed loop means the robot does not just command motion once. It keeps measuring what actually happened and correcting continuously.

The Key Insight

Without measurement, you are just guessing.

This is why embedded systems need sensors -- and why getting good measurements matters so much.

We will return to this idea throughout the course.

Hardware + Software = ONE System

In embedded systems, hardware and software are not separate parts. Together they form one closed system.

Diagram: Four-layer stack from Physical World down through Sensors, MCU Hardware, to Software — each layer only talks to its neighbor.

The Layer Model

Software does not interact with physics directly.

Software  --->  MCU Hardware  --->  Sensors/Actuators  --->  Physical World

Understanding this stack is central to embedded thinking.

A bug might be in your code, in your wiring, in your sensor placement, or in the physics of your environment. You must think across all layers.

The Main Loop

Most embedded systems follow this pattern:

# Conceptual structure (same in C and MicroPython)
while True:           # Runs forever
    read_sensors()    # SENSE
    process_data()    # DECIDE
    control_outputs() # ACT

This is not "Python thinking" -- this is embedded system thinking.

Looks Simple. It Is Not.

The main loop raises hard questions:

  • How long does each step take?
  • What if a step takes too long?
  • What happens between loop iterations?
  • What if a sensor reading is wrong?

We will explore all of these throughout the course.

From "Program" to "System"

The mental shift this course requires:

Programming Course This Course
"Does it compile?" "Does it meet timing?"
"Does it give correct output?" "Does it behave correctly over time?"
"It works on my machine" "It works under all conditions"
"I tested it" "Here is the data that proves it works"

How Is This Different From What You Know?

In a programming course, a program starts, runs, and exits. In embedded systems:

  • The program never ends -- while True: runs forever. There is no return 0.
  • Time is physical -- A sensor must be read within microseconds. A motor command must arrive on time. Physics does not wait for your code.
  • Bugs have physical consequences -- A bug in a web app shows an error page. A bug in a motor controller can break hardware, drain a battery, or crash a robot.
Programming course:              Embedded systems:

  main()                           while True:
    do_stuff()                       read_sensors()      # physics
    return result                    compute()           # timing matters
  # program ends                     act()               # physical output
                                   # never ends

What Changes in Bare-Metal?

What You May Assume Embedded Reality
Program starts when you run it Program starts at power-on
Program ends when done Program never ends
OS handles timing You handle timing (no OS!)
printf() just works Serial output takes ms, may block
Time is abstract Time is physical -- 1 ms matters!
Bugs → crash, restart Bugs → physical consequences
Memory is "infinite" Memory is limited (520 KB RAM)

The embedded mindset: same concepts whether you use C, MicroPython, or Rust.

Common Misconceptions

Misconception Reality
"C = real-time" Real-time is about determinism, not language. A poorly written C program can miss deadlines just as easily.
"Real-time = fast" Real-time means predictable deadlines. A system that always responds in 10 ms is real-time. A system that usually responds in 1 ms but sometimes takes 500 ms is NOT.
"sleep() is timing" sleep() blocks everything. Nothing else runs during the sleep. On an OS, other threads continue -- on bare-metal, the entire system freezes.
"If it ran once, it works" Embedded runs forever under varying conditions -- temperature changes, battery drains, sensors degrade. One successful run proves nothing.

From "does it compile?" to "does it meet timing?" -- this is the shift.

From Model to Mechanism

The SENSE-DECIDE-ACT loop is a model -- a way of thinking about embedded systems.

But models do not move motors or read sensors. Software does not touch the physical world directly.

What exact hardware platform will run our software this semester?

Before pin-level control, we need to know the MCU and board we are building on.

4. The RP2350 and Pico 2

RP2350 -- Key Specifications

Feature Value
CPU 2x ARM Cortex-M33 (or 2x RISC-V) @ 150 MHz
SRAM 520 KB
ROM 8 KB
GPIO 30 pins
ADC 4-channel, 12-bit, 500 kS/s
Communication USB 1.1, UART, SPI, I2C
Timing/Control PWM, Timers, RTC, Watchdog
Special PIO (Programmable I/O) state machines

RP2350 Block Diagram

h:420

Datasheet: rp2350-datasheet.pdf

Raspberry Pi Pico 2 Board

bg right:40% contain

The Pico 2 is a development board built around the RP2350:

Component Purpose
RP2350 MCU The brain
4 MB Flash Stores your program and filesystem
Micro-USB connector Power + serial communication
Crystal oscillator Provides precise clock source
Power supply Regulates voltage for the chip
LED Built-in indicator (active via Pin("LED"))
BOOTSEL button Enters firmware update mode

Cost: approximately 5 EUR -- affordable for every student project.

Pico 2 Pinout

h:450

Every pin has multiple functions -- GPIO, ADC, PWM, SPI, I2C, UART. The pinout defines what your code can control.

Why We Use RP2350 (Pico 2)

  • Dual-core ARM Cortex-M33 -- fast enough for control, simple enough to understand
  • PIO state machines -- hardware timing without writing C
  • MicroPython support -- rapid prototyping for learning
  • ~5 EUR cost -- affordable for student projects
  • Good peripherals -- PWM, ADC, I2C, SPI, PIO all built-in

Why Is the Chip Called RP2350?

bg right:35% contain

The naming scheme encodes key specifications directly in the part number.

More info in the datasheet.

Our Lab Device: Yahboom Pico Robot

bg right:45% contain

  • Brain: RP2350 (Pico 2)
  • Sensors: 4x line sensors, IMU (gyro+accel), ultrasonic, microphone
  • Actuators: 2x DC motors, addressable LEDs, buzzer
  • Power: battery pack + motor driver (H-bridge)
  • Display: OLED screen (I2C)

This robot is your teaching platform for all 12 weeks.

Online Simulator: Wokwi

Practice without hardware: wokwi.com

  • Supports MicroPython and C/C++ for Raspberry Pi Pico
  • Simulate GPIO, LEDs, sensors, displays
  • Prototype at home without the physical robot

Use it for experimentation. The real robot is still the primary learning tool.

5. GPIO -- The Hardware-Software Bridge

What Is GPIO?

A General-Purpose Input/Output pin is the physical connection between software and the outside world.

Digital Output -- code becomes voltage:

from machine import Pin
led = Pin("LED", Pin.OUT)  # "LED" = the onboard LED
led.value(1)  # HIGH -- 3.3V -- LED on
led.value(0)  # LOW  -- 0V   -- LED off

On the original Pico (RP2040), the onboard LED was on GPIO 25 and you could write Pin(25). On the Pico 2 (RP2350), the LED is behind a wireless chip and is not a simple GPIO -- use Pin("LED") instead. For all other pins, you still use numbers: Pin(16), Pin(2), etc.

Digital Input -- voltage becomes data:

button = Pin(16, Pin.IN, Pin.PULL_UP)
if button.value() == 0:  # pressed -- connected to ground
    print("Button pressed!")

Every sensor reading and every actuator command passes through a GPIO pin.

Current Limits -- Why You Need Drivers

A GPIO pin can source roughly 4-12 mA. That is enough for some things, but not for others:

Device Current Needed GPIO Can Handle? Solution
LED (with resistor) ~5 mA Yes Direct connection
Small sensor ~1-10 mA Yes Direct connection
DC motor ~200-500 mA No -- will damage the pin H-bridge driver
Servo motor ~500-1000 mA No External power + signal

Key insight: GPIO provides the signal; the driver provides the power. This is WHY H-bridges exist (Lecture 03).

Watch the total too: Each pin has its own limit, but the chip also has a maximum total current across all pins. Five LEDs at 10 mA each = 50 mA from the chip. Exceed it and the smoke comes out -- and it does not go back in.

Pins Are Multi-Function

Most MCU pins are multi-function -- the same physical pin can act as GPIO, PWM output, ADC input, or a communication bus, depending on configuration:

Function What the pin does
GPIO Simple digital high/low under software control
PWM Hardware-timed toggling (e.g. motor speed)
ADC Reading an analog voltage (dedicated analog-capable pins)
I2C / SPI Communication buses (specific pin pairs)
USB Dedicated pins -- not remappable

Understanding pins means understanding the boundary between software and hardware.

6. From C to MicroPython (and Boot Flow)

This is what blinking an LED looks like when you talk directly to the hardware:

int main(void) {
    PUT32(0x4000f000, (1<<5));    // enable GPIO block
    PUT32(0x400140cc, 0x05);      // set pin 25 as output
    PUT32(0xd0000020, (1<<25));   // drive pin 25 high
    while (1) {
        PUT32(0xd000001c, (1<<25)); // toggle pin 25
        delay(500000);              // busy-wait
    }
}

You control every register yourself. Powerful — but not fast to write or easy to read.

There must be a better way to learn embedded thinking...

Enter MicroPython

Same LED blink:

import machine, time
led = machine.Pin("LED", machine.Pin.OUT)
while True:
    led.value(not led.value())
    time.sleep_ms(500)

Same result. But you write what you mean, not which registers to poke.

C (bare-metal) MicroPython
Write a GPIO toggle Look up register address, bit mask pin.value(1)
Test an idea Edit, compile, flash, reboot (~30 s) Type in REPL, see result instantly
Debug a value Set up JTAG/GDB, add breakpoint print(sensor.read())
Change behavior Recompile and reflash Edit file, Ctrl+D to restart

How Does C Code Run?

your_code.c  →  compiler (on your PC)  →  machine code (.uf2)  →  flash to MCU

The compiler translates your code to CPU instructions once. The MCU runs them directly — no translation at runtime.

How Does MicroPython Code Run?

your_code.py  →  parser + compiler (on the MCU!)  →  bytecode (in RAM)  →  VM executes

When your .py file starts, MicroPython compiles it to bytecode first — a compact instruction format, not raw text. Then a small virtual machine (VM) on the chip executes those bytecode instructions one by one.

It does not re-read your text at runtime. But every bytecode instruction (like "look up led", "call value") still goes through the VM — which is slower than raw machine code.

The interpreter is a small C program (~300 KB) that lives on the MCU and runs your Python bytecode.

What Does One Line Cost? (RP2350 @ 150 MHz)

Read a GPIO pin into a variable:

Code Behind the scenes Time
C val = GET32(0xd0000004); 1-3 CPU instructions ~10-30 ns
MicroPython val = pin.value() ~300-600 instructions ~3-8 us

Roughly 300-800x slower per call. So why use MicroPython at all?

  • A sensor at 100 Hz = 10 000 us per reading. 5 us overhead is ~0.05% of the budget
  • Physics (sensor conversion, I2C latency, ADC settling) is the bottleneck, not the CPU
  • You save hours of development for microseconds of runtime

MicroPython where timing is comfortable. C (or PIO/DMA) where timing is critical.

Most embedded systems are limited by physics and I/O — not the CPU.

How Does Code Start Running?

When you plug in your Pico 2, a precise sequence begins:

Flowchart: Power On → Boot ROM → BOOTSEL check → either USB mass-storage mode or flash init → main() begins.

XIP (Execute In Place): code runs directly from flash -- it is not copied into RAM. Only variables live in SRAM.

MicroPython-Specific Boot

Once the MicroPython firmware starts, it runs its own sequence:

Flowchart: MicroPython starts → mount filesystem → boot.py → main.py check → either run code or enter REPL.

REPL = Read-Eval-Print Loop. You can type Python directly and see results instantly. This is one of MicroPython's biggest advantages for learning.

7. The Semester Journey

Your 12-Week Arc

Timeline: Foundation (Weeks 1–2) → Sensing & Signals (Weeks 3–4) → Movement & Control (Weeks 5–6) → Software (Weeks 7–8) → Engineering (Weeks 9–10) → Synthesis (Weeks 11–12), each building on the last.

Course Schedule: 6 Lectures, 12 Weeks

Lectures happen every two weeks. Labs happen every week.

Week Phase Lecture Labs
1 Foundation Lecture 1: What is Embedded? Robot Unboxing
2 Foundation — GPIO & Sensors
3 Sensing Lecture 2: Sensors, Signals & Actuators Ultrasonic & Timing
4 Movement — Motor Control
5 Control Lecture 3: Actuators & Control Line Following
6 Control — IMU Turns

Course Schedule (continued)

Week Phase Lecture Labs
7 Software Lecture 4: Software Architecture State Machines
8 Project — HW Abstraction + Architecture
9 Project Lecture 5: Engineering Practice Project Integration
10–11 Project Lecture 6: Course Synthesis Project Work
12 Project — Demo Day

What You Will Build

Progression: Week 1 (blink) → Week 5 (line follow) → Week 6 (IMU) → Week 7 (state machine) → Week 12 (competition-ready system).

Same robot, growing capabilities. Each week adds one new skill on top of the previous ones.

The Progression of a Single Feature

The line-following challenge evolves across the semester:

Week Approach What Happens
2 Read line sensors (GPIO) See raw 0/1 values
4 Add PWM motor control Basic movement, still crude
5 Add P-control Smooth tracking
6 Add IMU + data logging Precise turns, tune Kp from data
7 Add state machine Multiple driving modes + obstacles
12 Full integration Competition-ready

Same line. Same robot. Growing sophistication. Each week better than the last.

Lecture 1 Summary

Six Things to Remember

  1. Embedded = purpose-built -- a computer inside a product, doing one job

  2. MCU = CPU + Memory + Peripherals -- peripherals matter more than clock speed

  3. SENSE - DECIDE - ACT -- the fundamental loop of every embedded system

  4. GPIO is the bridge -- software meets the physical world through GPIO pins; know the current limits

  5. RP2350 is our platform -- dual Cortex-M33, 520 KB SRAM, rich peripherals, 5 EUR

  6. MicroPython for learning -- fast development, same embedded concepts as C

Quick Checks

Quick Check 1

What distinguishes an embedded system from a general-purpose computer?

Think for 30 seconds, then answer.

Quick Check 1 -- Answer

An embedded system is dedicated to a specific task and is part of a larger product. The user interacts with the product, not with the computer.

A general-purpose computer is the product itself -- the user decides what software to run.

Key difference: purpose-built vs platform.

Next: Lab 01

Lab 01: Robot Unboxing

  • Unbox your robot and identify its components
  • Explore sensors, motors, LEDs, and the buzzer
  • Play with the robot -- make it beep, blink, move
  • Discover what the hardware can do before writing serious code

Goal: Have fun. Get curious. Discover what the robot can do.

"You're blinking LEDs on a EUR4 board. The same GPIO principles control brakes on a EUR40,000 car."

Next lecture (Week 3): Lecture 2 -- Sensors, Signals & Actuators

Tutorial: Robot Unboxing