ECE 460/560: Class 02

A High-Level Look at Processes, HW and SW,

Synchronization and Example Systems
A.G. Dean
agdean@[Link]
[Link]

v2 9/2/2025

1
Class 02 Overview – Process Basics, HW and SW, Processes and
Synchronization in Example Systems
▪ Review of how ES computers are different from ▪ Example applications
GP, and why ▪ Scope
▪ Often demanding, complex I/O timing requirements drive ▪ Key timing requirements:
different design choices ▪ Responsiveness to changing input signal. Detect
▪ Process relationships trigger condition quickly.
▪ Stable periodic timing for sampling input value.
▪ Concurrent vs. sequential execution
▪ Improving timing by moving key processing steps from
▪ HW vs. SW on single-core CPU vs. SW on multi-core software to hardware using peripherals, interrupts,
▪ Free-running vs. synchronized direct memory access controller
▪ Application example: Oscilloscope ▪ ECE 306 line-following car
▪ Scope triggering: one kind of synchronization ▪ Inputs, processes, outputs
▪ How to implement with as little hardware as ▪ Motor position sensing and control
possible: busy-wait loop ▪ Input timing requirements for shaft position encoder.
▪ Hardware or software? Missing deadline may give wrong direction or even miss
pulses.
▪ Software timing: hard to predict required time to
▪ Output timing requirements for variable speed (pulse-
execute (and its variability) width modulated) motor drive. Missing deadline affects
▪ System response time for chain of processing steps motor speed proportionally
▪ Application timing requirements vs. HW and SW ▪ Waveform Generator
capabilities ▪ Stabilize output updates to regular periodic times with
2 low jitter for accurate signal generation.
Computers for Embedded Systems vs. General-Purpose Systems
“How slow can your CPU go and still be on time?” Embedded Systems have concurrent compute processes with diverse I/O operations. Often the I/O for a process has challenging timing
requirements, so we decouple it from compute software (bad timing characteristics) by splitting it into two or more processes to make input or output operations asynchronous to the compute
operations. These processes need to synchronize and communicate (data buffering).We may even move some processing to [Link] use interrupts, HW peripherals and DMA to make a low-
cost and feasible solution with a low-frequency CPU.
Embedded (Computer) System enhances larger system: e.g. improves Wide range of input and output signals. Digital,
performance, adds safety protections, simplifies maintenance & diagnostics. analog, differential, bit-dominance (wired-or), etc.
Must monitor inputs and control outputs.
Some I/O operations step through a sequence of I/O sub-operations triggered by
Range of processing activities needed to handle inputs, events or time delays, creating new linked timing requirements. UART RX operation,
determine control actions, update outputs. PWM, synchronous control of motor/SMPS, network with bit dominance, etc.

Inherently concurrent system. Often is most practical to implement Inherent behavior of algorithms
with multiple concurrent processes (some SW, some HW). Wide range of timing requirements (absolute time, update rate & phase, synchronization (control flow variations)
(among signals, with clock, with system substate), response time, timing stability vs. jitter
…) for input signals, output signals, and between them (I->I, I->O, O->O). Disconnect between source code and object code
System with concurrent processes requires sync & comm
timing: compilation, ISA features, optimizations
Sources of software timing obscurity: CPU performance variations: data-dependent
Synchronous software I/O is bad fit for time-critical I/O requirements. SW timing inherent behavior of algorithm, arbitrary input event
obscurity/ambiguity/non-determinism clash with I/O needs (req’ts for timing precision instruction timing, superscalar/dynamic
sequences, program compilation, performance execution, pipelines, predictors, prefetching
& stability) and SW<->I/O rate mismatches (especially for burst activities) variation/non-determinism (CPU, memory system),
Mainstream computing just uses a subset of the task scheduling Memory system
Async I/O design space. Targets gen-purpose Use Async I/O to bridge/tolerate timing mismatches (caches, VM, interference in multicore, …)
computers with a few I/O devices (user (between I/O and SW) at low cost
interface, storage, network) and their use cases. Sync for initial triggering (event generators/detectors)
Arbitrary input event sequences possible,
Interrupts/exceptions for timer tick, OS complicating system timing behavior
Implementing Async I/O requires deciding where to split Supporting splits: Communication (esp. data buffering
interface, faults, I/O events (Rx or Tx complete,
process, how those parts will sync and communicate. w/timing requirements), more sync to support comm
error). DMA discussed if you dig deep enough Interrupts and Scheduling to share CPU core(s).
(notifications, handshaking, overruns …)
into system design.
Can implement process functionality, sync and comm in SW, HW or both.
Should select based on strengths and weaknesses of SW, HW for given need. Efficiently crossing between HW and SW to implement Sharing CPU: Interrupts, Scheduling, Real-Time
When you have only a hammer, procs, sync and comm. Interrupts, DMA vs. prog I/O. System Concepts
everything looks like a nail.
CS education doesn’t do digital Throw in Use HW for some or all of func, sync, comm: less SW
Programmable
design (other than CPU, maybe another core needed (if any), easier SW deadlines (fewer, looser).
Coprocessors:
memory system, AI accelerators, TI PRU (prog.
DMA
S S
…). Must understand some digital design to effectively H H

SW
real-time unit), … Port
recognize and assess HW implementation options H
S H
Buffer
Int. Sys. Int. Sys.
VIn In Timer DMA Out LCD
General Design Pattern: functionality, Implementations & Mechanisms

HW
sync, comm (esp. buffering) (outside of CPU ISA) Erase In

General HW Event/Sync DMA HW Peripherals for Programmable logic with

Peripherals Interconnect for Sync/Comm Support custom FSM. CLB, FPGA. Pico
Peripherals Prog. I/O blocks (FSMs)
3 agdean@[Link] August 18, 2025
 Extending the Topic Map
Processes and Concurrency
for Embedded Systems

Embedded Systems Processes and

Design Space(s) Concurrency

Application Requirements Cost of Process Dependences

Characteristics & Constraints Precise Timing Implementation between Processes

Why Hardware Software Both Hardware and

Synchronization Communication
use…? Processes Processes Software Processes

CPU Sched: Notification/ Split Direct or

SW? HW? Sync. to What? Ordering/ Mutual Data Loss &
per Share CPU How? Flow Ctl./ Buffering Receiver Indirect
Do or Don’t? Triggering Exclusion Duplication
Process Time Handshaking Process? Comm.?

Peri- Dedic. HW DMA Mem- Polling Intrpt DMA Cost of Precise Buffering
pherals Interconn. Ctlr Mapped (Prog’d Concepts How? Concepts How? How? Why? How?
System Ctlr Timing Concepts
Periph. I/O)
Access
In Split urgent/
Order? How?
deferrable work

“DIY” Code Implementations

Infinite +Interrupts
+ Coop. + Task + Task Shared Shared Req/Ack DMA-
loop in : Fore/Back Serializing Double Circular
Sched. Tasks Priorities Preemption Variables Variables Flags managed
main ground Server Buffer Buffer
buffer

FSMs for RTCS Run-to- OS Mechanisms

Completion RTXv5 Message
Responsiveness Event Flag Semaphore Mutex Lock Mailbox
Scheduler RTOS Queue
4
 Take Multiple Passes, Getting More Details As Needed
Level 1: Overviews Blinky WaveGen Scope DevSys
How ES are Different
(Shield &
FRDM)
Basic Complex I/O. Dig, Process Concurrency, Sync and Introduction to Example Applications: I/O, Processing, Timing, Sync and Comm
Basics HW Processes: SW Processes. Flex Development Problem-
Behavior Ana, Basic Timing Comm for SW and HW
Lim funct, precise funct, sloppy timing, Processes Solving
(Control) Reqts Procs
timing, dedicated share/sched

Sync. vs. Async.

Level 2: Foundations. Basic Concepts and Architectures I/O

Timing Behavior CPU Sharing: intrpts, Design Debugging

Peripherals Timing Reqts. Process Sync & Comm
& Analysis sched. Roadmap: before
in Detail Preemption++ (4)
(See LN L2) Dimensions Coding
Digital Analog
HW-HW HW-SW SW-SW

Peripheral DMA Prog’d Interrupt Shared Sched. IPC Cyclic Digital & Analog Stabilizing Output TBD
Interconnect System I/O System Variables Support Exec. Interfacing, Task Synchronizing
Timing
Timing Reqts, Processes (events
Async. I/O and mutex),
Interf. and Sched.
Stabilizing Input
Need & AIO Imps Timing, Data
Concepts Buffering
AIO with Cyclic Exec.
Level 3: Detailed Design with HW Peripherals, Interrupts & Intrpts
Cyclic Exec & Interrupts AIO with
DMA and
Interrupts Coop. Sched.
& Intrpts

AIO Coop.
Apply Coop Sched
Level X: Re-Implement with Coop Sched (RTCS) Sched. & Intrpts
Services: TBD
Apply Coop Sched Apply Coop Sched Apply Coop Sched
Services: TBD Services: TBD Services: TBD
Preemptive Sched.
& Intrpts (RTOS)
Level Y: Re-Implement with Preemp. Sched (RTOS RTX5) Apply RTOS
Apply RTOS
Services: TBD Apply RTOS
Services: TBD Services: TBD Apply RTOS
Services: TBD

5
 Process Relationships: Concurrency and Synchronization

6
Process Relationships
▪ Sequential: Finish current process before starting another
▪ Finish red before starting any other process Start End Start End Start End

▪ Concurrent: Process execution may overlap in time

▪ Can start green, yellow before finishing red Start End
S E
S E
▪ Execution of concurrent processes
▪ Hardware: Dedicated circuit per process, Start End
so able to run at the same time

▪ Software: depends on # of CPU cores

▪ Each core works on one process at a specific point in time
1 Core Start S S E End E

2 Cores Start End

S S E E

3 Cores Start End

7
Synchronized or Free-Running Process Execution?
▪ Example: Five processes (A-E), each flashing an LED
▪ How to make LEDs flash in a scanning sequence? Process A LED
▪ Simple independent starter process doesn’t do this
▪ LEDs flash independently of each other. Changing one
process doesn’t affect the others Process B LED
▪ No synchronization between processes, are free-running
▪ Hardware process runs non-stop
▪ Software process runs whenever it can (CPU available) Process C LED
▪ Processes need to synchronize with each other
▪ After turning off its LED, process sends a synchronization
signal to the next process. Process D LED
▪ A process doesn’t turn on its LED until after it gets a
signal from the previous process
▪ Special case for start-up: Process A doesn’t wait for signal Process E LED
on its first execution

8
Synchronized Process Execution
▪ Don’t let Process B start to execute section B2 until
Process A A1 A2
Process A has completed section A1
▪ Includes case where each thread has only one section
Process B B1 B2
▪ Multiple cases possible based on initial process
execution order and priority (if sharing a CPU)
PA > PB PA < PB

A1 A2 Ready A1 Ready A2
A ran first

B2 must wait B2 can run B2 must wait B2 can run

Blocked Ready B1 B2 B1 Blocked B2
B ran first

Ready A1 A2 Ready A1 Ready A2

B2 must wait B2 can run B2 must wait B2 can run
B1 Blocked Ready B2 B1 Blocked B2
9
Synchronization: Simple Oscilloscope Example

▪ Input signal
▪ Start with simple one-bit digital signal (do analog later)
▪ Pulses have irregular start times, changing pulse widths

(e.g. voltage)
Signal Value
▪ Displaying the signal
▪ Oscilloscope (“scope”) plots signal value (e.g. voltage) vertically vs.
time horizontally
▪ Horizontal time base determines amount of time (THoriz)
represented on scope display Time
▪ Display stability depends timing relationship between when THorizontal
scope starts displaying the signal, and when the signal changes
▪ “Infinite persistence” accumulates all acquired traces on display until
erase button is pressed

10
Simple Method: Display Signal Continuously
▪ Sequence
▪ Display signal from 0 to THoriz
▪ Display signal from THoriz to 2*THoriz
▪ Display signal from 2*THoriz to 3*THoriz
▪ Display signal from 3*THoriz to 4*THoriz
▪ Display signal from 4*THoriz to 5*THoriz
▪ Display signal from 5*THoriz to 6*THoriz
▪ Display signal from 6*THoriz to 7*THoriz
▪ etc.

▪ What is range of pulse widths? Can’t see.

▪ Resulting display is unstable, jumps around
over time.
11
Stabilize Display with Triggering
▪ Scope does nothing until triggered
▪ Event from input signal (e.g. 0 to 1 edge)
triggers scope to start displaying signal
▪ Triggering synchronizes the scope’s start of
data display to input signal event

▪ Resulting display is much more stable

▪ Range of pulse widths is easy to see.
▪ Rising edge of signal is stable
▪ Except for last acquisition, where time
between rising edges < Thoriz
▪ Falling edge unstable since pulse width varies
12
Simple Busy-Wait Loop
Process A
Software …
// Detector/Synchronizer
while (ADC->Result < V_Threshold)
;
Hardware

VIn GPIO GPIO LCD // No Scheduler

// No Dispatcher
// Handler process
x = 0;

▪ Synchronization built into SW process A for (n=0; n<NS; n++) {

r = ADC->Result;
y = scale(r);
▪ Simple, but doesn’t scale up well with multiple software LCD_Plot(x++,y);
}
processes

13
 System Timing Performance:
Software and Hardware

14
Use Software or Hardware? Flexibility vs. Timing Stability

▪ Software
▪ Program gives very flexible functionality
▪ Interrupt system (e.g. NVIC) and scheduler
(if any) determines what software runs on
CPU and when
▪ Software very vulnerable to timing
interference. Need synchronization. Use
interrupts, scheduler to improve timing
stability
▪ Hardware
▪ Very stable timing (when independent of
software)
▪ Functionality limited to what is built into
hardware (and your creativity)
15
“Sloppy” Software Timing Behavior
▪ Time to execute code is…
▪ Hard to predict accurately: Timing ▪ Unstable (“fragile”): Depends on paths
behavior depends on machine taken through conditionals, loop
language instructions generated from repeat counts, etc. Paths may depend
source code by compiler, CPU used, on input data, execution history, etc.
data-dependent instruction timing,
system speed….

if (x>0)
j += r;
else
x++;
x = x/8; Compile, assemble ????
if (j>3) and link (machine code
instructions)
x -= 17;
else
r *= 7;

16
 System Responsiveness Depends on Processes
CPU Sharing Overhead:
Synchronization, Scheduling, Context Switching/Dispatching
▪ Uses hardware circuits which are
Process 0 dedicated (not shared)
Software

Process 1 ▪ Exceptions later: shared buses, etc.

Process 2
▪ Software process timing: much slower, unstable,
Int. Handler
hard to predict precisely
▪ Time to execute a software process is hard to
In Out
Hardware

predict, varies based on input data, history …

▪ Sharing CPU among multiple software processes
VIn Event
VOut Response delays a process
▪ Inherent delays and processing overhead (may be in
Time (microseconds)
▪ Responsiveness depends on sequence of activities program, interrupt system, OS/executive) for:
▪ Synchronization: deciding if process may run (is ready) or must
between input event and system’s response wait for event/condition
▪ Diagram ▪ Scheduling: deciding which ready software process to run next
▪ Process 1 samples Vin, looks CPU CPU CPU ▪ Context Switching and/or Dispatching: saving and restoring
for event (0 to 1 transition) Instruction Instruction Instruction process contexts, starting next process running
▪ Timing interference (preemption, blocking) from other
▪ Hardware process timing: software processes (threads, interrupt handlers)
fast, very stable, predictable
▪ Typically faster than time for VIn
CPU to execute an instruction Timing Close-Up
17
(nanoseconds)
Timing Requirements vs. Response Time Capabilities for
Different Design Approaches

Lots of time

18
Very little time
Design Examples

▪ Oscilloscope
▪ Synchronize to input signal rising across trigger voltage level, then capture data samples at precise, frequent times
▪ ECE 306 line-following car
▪ Multiple processes
▪ Motor position sensing and control
▪ Monitor motor position using quadrature shaft encoder
▪ Waveform generator
▪ Generate analog waveform with consistent, precise timing for output updates

19
Scope: Stabilize Display with Triggering
▪ Version 1: Simple Busy-Wait Loop
▪ Software detects trigger event using small loop
which blocks progress through process/thread

Process A
// Detector/Synchronizer
while (ADC->Result < V_Threshold)
Software

;
// No Scheduler
// No Dispatcher
// Handler process
Loop for all columns in screen
VIn GPIO GPIO LCD
Hardware

Get input data sample,

Scale it,
Plot it on LCD
20
 Improve Timing by Moving Activities from Software to Hardware
Trigger Detection by Software
Sync: Loop until rising Thread: Sample Sync: Loop until rising edge event
S
SW

H edge event detected input, plot on LCD detected

HW

VIn In Out LCD

Port Interrupt
CPU available for CPU available for other SW
Trigger Detection by Hardware other SW processes
Handler: Sample
processes
Port input, plot on LCD
SW

Int. Sys.
HW

VIn In Out LCD

Sync: Data
Ready to Plot?

Hardware Trigger Detection and Thread: Plot CPU available for

CPU available for CPU available for
buffered other SW
DMA (Direct Memory Access) + other SW processes other SW processes
samples on LCD processes
Timer for Data Acquisition Port Interrupt DMA
Handler: Enable S S
Port H
Timer and DMA H
SW

H
Buffer
Int. Sys. Timer Int. Sys. DMA Interrupt
HW

VIn In DMA Out LCD

Handler: Tell thread
to plot buffer data
21
 Direct Memory Access Controller
Allows Hardware->Hardware communication without using CPU

Control Signals
CPU
(Read,Write)
▪ DMA features
Address
Data ▪ DMAC can transfer (copy) N data items within
memory space from SrcAdx to DstAdx
▪ SrcAdx, DstAdx: fixed or increment per item copied

Controller
Controller
Interrupt

▪ Allows direct copy, but also accessing sequential items

DMA
Memory Peripheral Peripheral in memory array (“Save the next N ADC data values in
memory starting at this address”)
▪ Transfer can be triggered by:
▪ Hardware (DMA Request from peripheral device)
Interrupt Requests (IRQs) DMA Requests (DRQs)
▪ Software (CPU writing to DMA request control register)
▪ Configurable bus sharing with CPU: can be greedy
▪ How to access memory and peripherals? (burst of all transfers), round-robin, etc.
▪ CPU uses memory bus (address, data, control) to ▪ DMAC can generate interrupt when done
access memory and peripheral devices ▪ DMAC has multiple channels, each with individual
▪ Memory bus can also be controlled by DMA trigger source, Adx pointers and behaviors, item
Controller (DMAC) peripheral count, interrupt behavior
22
ECE 306 Car: Inputs, Processes and Outputs

23
ECE 306 Car: Add Hardware Peripherals for Interfacing

24
Motor Position Sensing and Control

25
 Waveform Generator Subsystem: One Process
W1. WaveGen, base design
Compute/Update
SW

Dig. to Ana.
HW

Amplifier Speaker
Conv.

▪ Part of a larger system with other processes (e.g. user interface)

▪ Want to update DAC output every 50 us for a 20 kHz update rate
▪ DAC signal amplified to drive speaker

Process Input Input Processing Output Output Timing Requirements

Device Peripheral Peripherals Devices
W: Waveform n/a n/a Calculate new output value, Digital-to-analog Amplifier & Every 50 us, +/- 5 us (?)
Generator wait fixed time, converter Speaker
write output value to DAC

26