8th chapter

BASIC DESIGN OF AN EMBEDDED SOFTWARE (ES) USING RTOS

Prior to design, we must construct a specification of the ES to meet such requirements properties
as:

1) Completeness.

2) Time (timing constraints response time, reactive time, and deadlines – soft vs. Hard)

3) Properties of the target hardware (for effective design of the ES),

4) Knowledge of microprocessor speed – can the microprocessor run the IR 1200 times per sec?

5) Need all the software engineering skill you have, plus such properties as: structures,

encapsulation, info/- hiding, modularity, coupling, cohesion, maintainability, testability.

Effective use of design tools and methodologies

6) Testing and debugging ES requires specialized hardware tools and software tools and
techniques

Principles – 1

1. Write Short Interrupt Routine:

 Even lowest priority IR’s are handled before the highest priority task code (minimize task
code response time)
 IR’s are error prone and hard to debug (due to hardware dependent software parts) Parts
IR code requiring immediate / quick response should be in the core of IR code; parts
needing ‘longer’ processing and not so urgent response should be done a task (signaled
by the IR)

2. How many tasks?

 More tasks offer better control of overall response time

 Modularity – different task for different device handling or functionality
 Encapsulation – data and functionality can be encapsulated within responsible task
 More tasks means data sharing, hence more protection worries and long response time
due to associated overheads
 More task means inter task messaging, with overhead due to queuing, mail boxing, and
pipe use
 More tasks means more space for task stacks and messages
 8th chapter

 More tasks means frequent context switching (overhead) and less throughput
 More tasks mean frequent calls to the RTOS functions (major overhead adds up).

3. You need tasks for Priority.

 For quicker response time using task prioritization – high priority for time critical ones,
and low priority for others.

4. You need tasks for Encapsulating.

 A dedicated task to encapsulate the handling of each shared device (e.g., printer display
unit) or a common data structure (e.g., an error log) Parts of a target hardware storing
data in a flash memory – a single task encapsulates the handling of permission to write to
flash (set / reset of flash at given times)

5. Other Tasks you Might or Might Not Need?

 Need many small, simple tasks? But worry about data sharing, inter task comm.
 8th chapter

 Need a task per stimuli? Same problems!

6. Recommended Task Structure

 Modeled/Structured as State Machines

 Tasks run in an infinite loop
 Tasks wait on RTOS for an event (expected in each task’s independent message queue)
 Tasks declare their own private data to use (fully encapsulated)
 Tasks block on in one place (RTOS signal), and not any other semaphore, no data sharing
 Tasks use no microprocessor time when their queues are empty.

7. Avoid Creating and Destroying Tasks

 Creating tasks takes more system time

 Destroying tasks could leave destroy pointers to messages, remove semaphore others are
waiting on (blocking them forever) Rule of thumb: Create all tasks needed at start, and
keep them if memory is cheap.

8. Consider Turning Time-Slicing Off

 Useful in conventional OS’s for ‘fairness’ to user programs In ES’s fairness is not an
issue, response time is!
 Time slicing causes context switching – time consuming and diminishes throughput.
 Where the RTOS offers an option to turn time slicing off, turn it off!

9. Restrict the use of RTOS functions/features

 Customize the RTOS features to your needs (Note: the RTOS and your ES gets linked
and located together into same address space of ROM/RAM .If possible write ES
functions to interface with RTOS select features to minimize excessive calls to several
RTOS functions (increases opportunity for errors).
 Develop a shell around the RTOS functions, and let your own ES tasks call the shell (and
not the RTOS directly) – improves portability since only the shell may be rewritten fro
RTOS to RTOS.

8.3 An Example – Designing an Underground Tank Monitoring ES System

 Resolving timing problem

 Deciding to use an RTOS
 Dividing the work into tasks
 Moving the system forward
 8th chapter

 Dealing with the Shared data

System of 8 underground tanks Measures read: temperature of gas (thermometer) read at any
time float levels (float hardware) interrupted periodically by the microprocessor. Calculate the
number of gallons per tank using both measures. Set an alarm on leaking tank (when level slowly
and consistently falls over time). Set an alarm on overflow (level rising slowly close to full
level). User interface:

a) 16 button control panel, LCD, thermal printer System can override user display options
and show warning messages. Histories of levels and temperature over time can be
requested by user (3050 lines long) and user can queue up ‘several’ reports. Issuing
commands require 2 or 3 buttons, and system can prompt the display in the middle of a
user command sequence. Buttons interrupt the microprocessor. One low priority task that
handles all # gallons calculations and detects leaks as well (for all tanks – 1 at a time). A
high priority overflow detection task (higher than a leak detection task). A high priority
 8th chapter

float hard ware task, using semaphores to make the level calc and overflow detection task
wait on it for reading (semaphores will be simpler, faster than queuing requests to read
levels).

A high priority button handling tasks – need a state machine model (an IR? With internal static
data structures, a simple wait on button signal, and an action which is predicated on sequence of
button signals) since semaphores won’t work

A high priority display task – to handle contention for LCD use Turning the alarm bell on/off by
the level calculation, overflow, and user button is typically non contentious – an atomic op –
hence do not need a separate alarm bell task However, need a module with BellOn(), BellOff()
functions to encapsulate the alarm hardware

Hard RealTime Scheduling Considerations

 Guaranteeing that the system will meet hard deadlines – comes from writing fast code
 Issues: fast algorithms, efficient data structures, code in assembly (if possible)
 Characterizing real time systems:
 Made of n tasks that execute periodically every Tank units of time Each task worst case
execution time, Cn units of time and deadline of Dn Assume task switching time is 0 and
non-blocking on semaphore.
 Each task has priority Pn Predicting Cn is very important, and depends on avoiding
‘variability’ in Execution times for tasks, functions, access time of data structures/buffers,
Semaphore blocking – any operation that can’t be done in the same time units on each
execution/access.

6 Saving Memory Space

 8th chapter

 Considerations of limited memory space for ES systems

 Code is stored in ROM (loaded into RAM for execution), Data is stored in RAM (except
for initialization/shadowing. The two memory space types are not interchangeable
Tradeoffs: packed data saves RAM space, but unpacking code takes ROM space
 Estimate space by:
 A. Tasks take stack space, fewer tasks take less RAM space, inspect code to estimate
stack bytes per task – local variables, parameters, function nesting level, worst case
nesting of interrupt routines, space for the RTOS (or select features) from the manual
 B. Experimental runs of the code – not easy and won’t reflect worst case behavior.

7. Saving Power

 Some embedded systems run on battery, turning battery off for some or all devices is
good.
 Generally, how to do you save power?
 Look for the power saving modes (enablers) which the manufacturers provide
 Software can put microprocessor in one the modes – via special instruction or
writing a code to special register in the processor. The software must be fast!!
 Power saving modes: sleep, low power, idle, standby, etc. Typical: microprocessor stops
running, all built in devices, and clock circuit (but leave static RAM power on since the
wattage is very small)
 Waking microprocessor up is done by special circuitry and software (to avoid restart and
reset – write special code to RAM address and let software check if it is cold start or
restart from power saving mode)
 Alternative: microprocessor stops running but all devices stay alive, microprocessor is
resume by interrupt (this is less a hassle that stopping all devices)
 If software turns power of devices back on, status data for resumption must be in
EEROM, and for those devices Turn off built-in devices that signal frequently from high
low, low hi power hungry!