CO3053 – Embedded Systems

5. Embedded Programming Paradigm

▪ Round Robin
▪ Round Robin with Interrupt
▫ Event-Driven and Time-Driven
▪ Real Time Operating System
CO3053 – Lecture Notes 2

Contents
▪ Round Robin & Round Robin with Interrupts
▪ Real-Time Operating System

▪ Misc.Topics for Efficient C Programming

▪ 9 Debugging Rules

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 3

Round Robin
▪ Simplest architecture, a single loop checks devices in predefined sequence and
performs I/O right away

▪ Works well for system with few devices, trivial timing constraints,
proportionally small processing costs
▪ Response time of device i equal to WCET (Worst Case of Execution Time) of
the body of the loop
anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 4

Round Robin
▪ Periodic Round Robin
▫ In case the system must perform operations at different frequencies
▫ Add code to wait a variable amount of time

▪ Exercise
▫ Think how to implement a loop that runs every 10ms and measures the drift

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 5

Round Robin
▪ Limitations
▫ If some devices require small response times, while other have large WCET it
will not be possible to guarantee that all timing constraints will be met.
▫ The architecture is fragile, adding a new task can easily cause missed
deadlines.

▪ Question
▫ Is the order in which devices appear significant?
▫ Same above question, but with code for devices having different processing
times and timing constraints?

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 6

Round Robin with Interrupts

▪ Hardware events requiring small response times handled by ISRs
▪ Typically ISRs do little more than set flags and copy data

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 7

Round Robin with Interrupts

▪ Interrupt routines deal with the very urgent needs of devices.
▫ Non-urgent tasks are executed in a robin-round fashion
▫ Interrupt can be Time-driven or Event-driven

▪ Interrupt routines set flags to indicate the interrupt happened.

▫ Urgent tasks can be prioritized

▪ Drawbacks
▫ Shared-data problems arise
▫ Time response for a non-urgent task
 duration of the main loop + interrupts
anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 8

Round Robin with Interrupts

Shared-data problems

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 9

Round Robin with Interrupts

▪ Example
▫ Propeller clock

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 10

Round Robin with Interrupts

▪ Questions
▫ What if all task code executes at same priority?
▫ What if one of the device requires large amount of processing time (larger
than the time constraint of others)?

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 11

Real-Time Operating System (RTOS)

▪ An RTOS is an OS for response time-controlled and event-controlled
processes.

▪ It is very essential for large-scale embedded systems.

▪ The main task of a RTOS is to manage the resources of the system

such that a particular operation executes in precisely the same
amount of time every time it occurs

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 12

Real-Time Operating System (RTOS)

▪ Interrupt routines execute urgent tasks
and signal that non-urgent tasks are ready
to be executed.

▪ The operating system invokes dynamically

the non-urgent tasks.

▪ The OS is able to suspend the execution of

a task to allow another one to be
executed. (Preemptive Scheduling Support)

▪ The OS handles communication between

tasks.
anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 13

Real-Time Operating System (RTOS)

▪ Data communication between
tasks/interrupts must be coordinated

▪ Complex implementation (but you

don’t have to do it yourself)

▪ Robustness against modifications

▪ The OS uses a certain portion of the

processor resources (2% to 4%)

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 14

Selection Strategy
▪ We want to obtain the greatest amount of control over the
system response time ➠ Select the simplest architecture that
will meet your response requirements.

▪ RTOSs should be used where response requirements demand

them.

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 15

Discussion
▪ Simple video game (such as PONG)
What has to be considered?
▫ Display the image (PAL signal: 625 lines @ 50Hz)
▫ Game management (i.e. compute the position of the ball)
▫ Game control (buttons, controller)

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 16

Discussion
▪ Vending Machine
What has to be considered?
▫ Display information
▫ Handle buttons & coin acceptor
▫ Check sensors
▫ Motors control

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 17

Discussion
▪ Vehicle embedded electronics
What has to be considered?
▫ Sensor measurement (pedal, speed, switches, …)
▫ Engine control (ignition, turbo, injection, cooling system, …)
▫ Cruise-control
▫ Display
▫ GPS

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 18

Reference and Further Readings

▪ https://lectures.tik.ee.ethz.ch/es/slides/4_ProgrammingParadigms.pdf

anhpham@hcmut.edu.vn
Miscellaneous Topics for Efficient C
Programming
CO3053 – Lecture Notes 20

Problems with #define

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 21

Problem with Macros (1)

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 22

Problem with Macros (2)

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 23

Playing around with Increment

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 24

Bit Manipulation (1)

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 25

Bit Manipulation (2)

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 26

Pointers
▪ Reference to a data object or a
function

▪ Helpful for “call-by-reference”

functions and dynamic data
structures implementations

▪ Very often the only efficient way

to manage large volumes of data
is to manipulate not the data
itself, but pointers to the data
anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 27

Pointers Example

firstvalue = ?
secondvalue = ?
anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 28

Pointers Example

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 29

More Pointers Fun

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 30

Pointers are Typed

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 31

Pointers and Array

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 32

Pointers Precedence Issues

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 33

Efficient C Programming
▪ How to write C code in a style that will compile efficiently (increased
speed and reduced code size) on ARM architecture?

▫ How to use data types efficiently?

▫ How to write loops efficiently?

▫ How to allocate important variables to registers?

▫ How to reduce the overhead of a function call?

▫ How to pack data and access memory efficiently?

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 34

References
▪ A.N. Sloss, D. Symes, and C.Wright,“ARM System Developers Guide”

anhpham@hcmut.edu.vn
Debugging

9 Indispensable Rules for Finding the Most

Elusive Software and Hardware Problems

David J. Agans
CO3053 – Lecture Notes 36

Debugging

9 Indispensable Rules for Finding the Most Elusive Software and

Hardware Problems

David J. Agans

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 37

Rule #1 – Understand the System

▪ Read the manual (datasheet).

▪ Debugging something you don’t understand is

pointlessly hard.

▪ Just as with testing, subject knowledge matters –

here you need knowledge of the source code as
well.

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 38

Rule #2 – Make It Fail

▪ You cant debug what you cant produce.

▪ Find a way to reliably make a system fail.

▪ Record everything, and look for correlation.

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 39

Rule #3 – Quit Thinking and Look

▪ Don’t hypothesize before examining the failure in detail
▫ Examine the evidence, then think.

▪ Engineers like to think, don’t like to look nearly as much.

▪ If it is doing X, must be Y – maybe

▫ Check

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 40

Rule #4 – Divide and Conquer

▪ This rule is the heart of debugging
▫ Delta-debugging

▫ Narrow down the source of the problem

▫ Does it still fail if this factor is removed?

▫ Use a debugger to check system state at checkpoints; if everything is ok, you

are before the problem.
anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 41

Rule #5 – Change One Thing at a Time

▪ A common very bad debugging strategy
▫ It could be one of X,Y, X.
▫ I shall change all three and run it again.

▪ Isolate factors, because that is how you get experiments that tell you
something.

▪ If code worked before last check-in, maybe you should look at

just those changes.

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 42

Rule #6 – Keep an Audit Trail

▪ Don’t rely on your perfect memory to remember everything you
tried.

▪ Don’t assume only you will ever work on this problem.

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 43

Rule #7 – Check the Plug

▪ Question assumptions
▫ Are you running the right code?
▫ Are you out of gas?
▫ Is it plugged in?

▪ Start at the beginning

▫ Did you initialize memory properly?
▫ Did you turn it on?

▪ Test the tool

▫ Are you running the right compiler?
▫ Does the meter have a dead battery?
anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 44

Rule #8 – Get a Fresh View

▪ Experts can be useful

▪ Explain what happens, NOT what you think is going on

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 45

Rule #9 – If you didn’t Fix it, It ain’t Fixed

▪ Once you “find the cause of a bug” confirm that changing the cause
actually removes the effect.

▪ A bug is not done until the fix is in place and confirmed to actually fix
the problem.
▫ You might have just understood a symptom, not the underlying problem

anhpham@hcmut.edu.vn
CO3053 – Lecture Notes 46

Summary
1. Understand the system
2. Make It Fail
3. Quit Thinking and Look
4. Divide and Conquer
5. Change One Thing at a Time
6. Keep An Audit Trail
7. Check The Plug
8. Get A Fresh View
9. If You Didn’t Fix It, It ain’t Fixed

anhpham@hcmut.edu.vn