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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
CO3053 – Lecture Notes 8

Round Robin with Interrupts

Shared-data problems

anhpham@[Link]
CO3053 – Lecture Notes 9

Round Robin with Interrupts

§ Example
Propeller clock

anhpham@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
CO3053 – Lecture Notes 16

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

anhpham@[Link]
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@[Link]
CO3053 – Lecture Notes 18

Reference and Further Readings

§ [Link]

anhpham@[Link]
Miscellaneous Topics for
Efficient C Programming
CO3053 – Lecture Notes 20

Problems with #define

anhpham@[Link]
CO3053 – Lecture Notes 21

Problem with Macros (1)

anhpham@[Link]
CO3053 – Lecture Notes 22

Problem with Macros (2)

anhpham@[Link]
CO3053 – Lecture Notes 23

Playing around with Increment

anhpham@[Link]
CO3053 – Lecture Notes 24

Bit Manipulation (1)

anhpham@[Link]
CO3053 – Lecture Notes 25

Bit Manipulation (2)

anhpham@[Link]
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@[Link]
CO3053 – Lecture Notes 27

Pointers Example

firstvalue = ?
secondvalue = ?
anhpham@[Link]
CO3053 – Lecture Notes 28

Pointers Example

anhpham@[Link]
CO3053 – Lecture Notes 29

More Pointers Fun

anhpham@[Link]
CO3053 – Lecture Notes 30

Pointers are Typed

anhpham@[Link]
CO3053 – Lecture Notes 31

Pointers and Array

anhpham@[Link]
CO3053 – Lecture Notes 32

Pointers Precedence Issues

anhpham@[Link]
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@[Link]
CO3053 – Lecture Notes 34

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

anhpham@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]
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@[Link]