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
[email protected]
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
[email protected]
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
[email protected]
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?
[email protected]
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
[email protected]
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
[email protected]
CO3053 – Lecture Notes 8
Round Robin with Interrupts
Shared-data problems
[email protected]
CO3053 – Lecture Notes 9
Round Robin with Interrupts
▪ Example
▫ Propeller clock
[email protected]
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)?
[email protected]
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
[email protected]
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.
[email protected] 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%)
[email protected]
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.
[email protected]
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)
[email protected]
CO3053 – Lecture Notes 16
Discussion
▪ Vending Machine
What has to be considered?
▫ Display information
▫ Handle buttons & coin acceptor
▫ Check sensors
▫ Motors control
[email protected]
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
[email protected]
CO3053 – Lecture Notes 18
Reference and Further Readings
▪ https://lectures.tik.ee.ethz.ch/es/slides/4_ProgrammingParadigms.pdf
[email protected]
Miscellaneous Topics for Efficient C
Programming
CO3053 – Lecture Notes 20
Problems with #define
[email protected]
CO3053 – Lecture Notes 21
Problem with Macros (1)
[email protected]
CO3053 – Lecture Notes 22
Problem with Macros (2)
[email protected]
CO3053 – Lecture Notes 23
Playing around with Increment
[email protected]
CO3053 – Lecture Notes 24
Bit Manipulation (1)
[email protected]
CO3053 – Lecture Notes 25
Bit Manipulation (2)
[email protected]
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
[email protected] CO3053 – Lecture Notes 27
Pointers Example
firstvalue = ?
secondvalue = ?
[email protected]
CO3053 – Lecture Notes 28
Pointers Example
[email protected]
CO3053 – Lecture Notes 29
More Pointers Fun
[email protected]
CO3053 – Lecture Notes 30
Pointers are Typed
[email protected]
CO3053 – Lecture Notes 31
Pointers and Array
[email protected]
CO3053 – Lecture Notes 32
Pointers Precedence Issues
[email protected]
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?
[email protected] CO3053 – Lecture Notes 34
References
▪ A.N. Sloss, D. Symes, and C.Wright,“ARM System Developers Guide”
[email protected]
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
[email protected]
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.
[email protected]
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.
[email protected]
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
[email protected]
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.
[email protected] 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.
[email protected]
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.
[email protected]
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?
[email protected] CO3053 – Lecture Notes 44
Rule #8 – Get a Fresh View
▪ Experts can be useful
▪ Explain what happens, NOT what you think is going on
[email protected]
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
[email protected]
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
[email protected]
