1. An Embedded Software Primer
David E. Simon

2. Chapter 8: Basic Design Using a Real-Time Operating System
Overview
Principles
An Example
Encapsulating Semaphores and Queues
Hard Real-Time Scheduling Considerations
Saving Memory Space
Saving Power
4/9/2006

3. Overview
For a RT system, its function as well as response time are required.
Criticality of meeting deadlines is also important and based on whether it is a hard or soft RT system.
Knowledge of system hardware – e.g. if a serial port receives 1K characters/sec and each character causes an interrupt, system should be able to handle it.
Software design in accordance with previous chapters i.e. structure, modularity, encapsulation and maintainability to be accounted for.
Principles
General Operation
RTOS tasks normally are idle until an external event occurs or until the next period of operation starts. The event might be freeing of a semaphore or a message sent by another task which releases the task from its blocked state.
4/9/2006

4. Principles (contd.)
An e.g. Telegraph system is shown below (Fig. 8.1 – Simon)
4/9/2006

5. Principles (contd.) Write Short ISRs
ISRs should be short mainly because
Longer ISRs translate to slower task-code response
ISRs are more bug-prone and harder to debug
Common practice to make ISRs do the critical actions and pass on the rest to the tasks.
Suppose a system has following requirements
Commands come from a serial port
Commands end with a carriage return.
Next command only arrives after system responds to previous one
Characters at the serial port are not buffered
System can respond to commands relatively slowly
A bad design would be to implement everything in the ISR.
A better way would be to have ISR buffer received characters until it finds a carriage return, then send the buffered characters to another (command parsing) task through a mailbox
This keeps the ISR short and simple
4/9/2006

6. Principles (contd.) How Many Tasks? 4/9/2006
Work needs to be divided among an optimum number of tasks
Following are some advantages and disadvantages of having a large no. of tasks
Advantages
More control over response times. Critical tasks can be given higher priority as opposed to a single task doing the entire work.
More modularity, cleaner code
Better data encapsulation. e.g. only the task for a network connection needs the status of the network interface
Disadvantages
More tasks  more shared data  more semaphore  more semaphore bugs and corresponding handling time
Same problem with mailboxes, pipes, queues etc.
More stack space (memory)
Increases context switching, hence less throughput
More tasks  more RTOS calls  slower system. Often advisable to call RTOS functions as less as possible
Conclusion – Tasks should be as less as possible. More tasks should be added only when necessary
4/9/2006

7. Principles (contd.) You Need Tasks for Priority
An e.g. where multiple tasks are needed is when some parts of the work have tighter response times than others like in an embedded system, a task handling power failure can be given higher priority than the one performing mathematical calculations
You Need Tasks for Encapsulation
More sense in having a task for hardware shared by other tasks
E.g. a printer display is used to respond to the user, report paper empty, paper jams etc.
A separate display task ensures messages displayed in correct order, stay long enough to be read
Fig. 8.3 shows this diagrammatically
Similarly when several system parts need to store data in a flash memory, a task can be assigned for the purpose
Task can allow one write at a time and set/reset a flag to indicate when next write can take place
4/9/2006

8. Principles (contd.) Other Tasks You Might or Might Not Need
Many small tasks, simpler code
Trade-off – more shared data and context switching
Separate tasks for work that is in response to separate stimuli
Trade-off – same as above
4/9/2006

9. Principles (contd.) Recommended Task Structure
Fig. 8.5 shows the pseudo-code for a recommended task structure
4/9/2006

10. Principles (contd.) Avoid Creating and Destroying Tasks 4/9/2006
Task waits for a system signal (through a queue) in an infinite queue
Advantages
Task only blocks in one place
Tasks blocked when idle so no processor time used
Task uses private data so no semaphores needed
Structure similar to a window routine in MS Windows.
Embedded systems tasks often modeled as state machines – state variables stored in private variables in task
Avoid Creating and Destroying Tasks
Two reasons to avoid doing this while system running
These functions are the most time-consuming. Nothing constructive done so throughput reduced
Destroying a task often leaves bugs. If killed task holding a semaphore, all tasks waiting for it blocked forever unless the RTOS handles this automatically
Hence better to create all tasks at system startup and block idle tasks. Only thing wasted is task stack space and a small overhead for tracking the task.
4/9/2006

11. Principles (contd.) Turning Time-Slicing OFF Restricting RTOS Use
Time-Slicing done in some RTOSs when 2 ready tasks have same priority.
If allowed consider turning this option off
Normally embedded systems have several compute-intensive tasks and in most cases
Either they have different urgency levels and hence given different priorities
All have equal importance  either one can finish first
Time-Slicing not helpful in both cases
More context switches  less throughput
Conclusion – Unless there is an advantage, avoid using it
Restricting RTOS Use
Most RTOSs allow scaling to reduce memory.
Hence if user code uses 10 pipes and 1 queue, it might be advisable to replace queue with a 11th pipe and scale off the RTOS queue code
Better to limit accesses to pipes, mailboxes etc. to reduce chances of bugs.
Many RTOSs consist of an outer shell around actual RTOS. User can only access this.
Makes code portable, only shell needs to be rewritten when moving to another OS
4/9/2006

12. An Example Underground Tank Monitoring System 4/9/2006
System monitors up to 8 underground tanks by reading thermometers and levels of floats in them.
Float level is read by sending a command to the hardware which on obtaining the level interrupts the microprocessor for later reading
Temperature can be read anytime.
Both temperature and float level used to find gasoline volume (gallons)
Monitor tanks – set flag and set off alarm when level dropping consistently (leak), or when level rising rapidly during tank refueling (overflow).
User Interface – consists of a 16-button keypad, 20-char LCD and a thermal printer.
Keypad used to give commands like displaying levels, request reports, histories etc.. Buttons interrupt the microprocessor
A connector to an alarm bell to warn about system leaks or overflows. Turned off through one of the keypad buttons
Printer interrupts after printing each line, indicating it is ready for the next
Display shows most recent data. Retains data on screen until changed by the processor
4/9/2006

13. An Example (contd.) Resolving a Timing Problem Deciding to Use an RTOS
System needs to check tanks with rising floats several times per second.
Also it takes 4-5 sec to calculate the gasoline quantity after the read which is a problem
Resolved by detecting overflows based on float levels alone and not calculating the gasoline volume
Deciding to Use an RTOS
4-5 sec gasoline quantity calculation is the most time consuming and must be pre-empted when other processing is required to be done
Without an RTOS, ISRs required to do tasks.
Possible to manage with ISRs in current case but RTOS is a better option
Dividing Work into Tasks
Following are the tasks needed
Level Calculation Task
Calculates gasoline volume in each tank based on temperature and float level
Takes 4-5 sec, hence modeled as a low priority task
4/9/2006

14. An Example (contd.) Overflow Detection Task Float Hardware Task
One task for all tanks
Overflow Detection Task
Higher priority than level calculation task and leak detection
Float Hardware Task
Tasks requiring the float level send requests to it
Button Handling Task
Uses a state machine to keep track of buttons already pressed
Display Task
Prevents tasks from interfering with each others displays.
Alarm Bell Task
Shared hardware as several of the tasks can turn it on or off.
Print Formatting Task
Lower priority than button handling task since it might take more than 1/10th of a second to format reports which must not interfere with the button response
Using interrupts is the most common way to signal tasks to start or stop
4/9/2006

15. An Example (contd.) Dealing with Shared Data
Gasoline level is shared by several tasks (level calculation, display, print etc. tasks)
Can be dealt with either by having a semaphore or a separate task
If a semaphore is used, longest time a task will hold onto it is 1-2 ms – print formatting task, assuming all needed data is first copied to its private variables.
Hence no need for added complication of extra task
Fig. 8.9 shows the final task division and message flow
4/9/2006

16. An Example (contd.)
4/9/2006

17. Encapsulating Semaphores and Queues
Done by hiding the semaphore and corresponding shared data in a module.
Removes semaphore bugs
Fig below shows an e.g., shared variable lSecondsToday can only be read through the function lSecondsSinceMidnight
If lSecondsToday is read directly it will lead to bugs.
Encapsulating Queues
If direct access is given to queues, following problems might occur.
Task might accidentally delete the queue
Wrong format sent through the queue
Programmer writes data intended for a task to the wrong queue.
Solution – same as above, encapsulate queue in a module.
If a function is used to encapsulate the queue, all shared data must be protected by semaphores and function must be reentrant
4/9/2006

18. Encapsulating Semaphores and Queues (contd.)
4/9/2006

19. Hard Real-Time Scheduling Considerations
System must guarantee hard deadlines are met.
Some simplifying assumptions,
Task n restarts every Tn units of time (period), hence it must complete before Tn
Worst-case execution time: Cn
Priority: Pn
Tasks don’t block for semaphores, events etc.
Deadline: Dn (in some cases ≠ Tn)
Jitter: Jn
All these used to determine whether system meets deadlines
Being predictable more important then being fast, so that Cn well defined.
This to be considered while writing subroutines – they need to have relatively constant execution times
Buffer allocation time should be constant, independent of the number of buffers (all or none) allocated. Hence malloc should be avoided since its execution time depends on current amount of free memory
4/9/2006

20. Saving Memory Space Code stored in ROM, data in RAM
If an RTOS is used, stack size needs to be decided on.
This is determined by no. of function calls, function parameters and local variables. The RTOS needs some space for itself
For worst-case, also include nesting of ISRs
An experimental way to determine stack space – fill stack with recognizable data pattern at startup, run for certain time, see amount of data overwritten
Following are some ways to save code space:
Check if 2 functions not doing same task. E.g. if code calls memcpy at 20 places and memmove once, try removing this one call with memcpy and removing memmove from program
Check development tools. If memcpy calling causes tools to call memmove, memset, strcpy etc. try writing your own function that does not do this.
Scale down RTOS as much as possible
Check if C code doesn’t translate into too many assembly instructions e.g. each of the following 3 methods to initialize a struct variable result in different no. of assembly instructions
4/9/2006

21. Saving Memory Space (contd.)
struct sMyStruct aMyData[3];
struct sMyStruct *pMyData[3];
int i;
// Method 1
aMyData[0].iMember = 0;
aMyData[1].iMember = 5;
aMyData[2].iMember = 10;
// Method 2
for(i=0;i<3;i++)
aMyData[i].iMember = i*5;
// Method 3
i=0;
pMyData = aMyData; Do {
pMyData ->iMember = i;
i +=5;
pMyData++;
}while (i<10);
4/9/2006

22. Saving Memory Space (contd.)
Use static variables instead of stack ones as the read and write translates to fewer assembly instructions in most microprocessors
Use char instead of int for 8-bit processors.
As last option, write code directly in assembly
Saving Power
Several embedded systems run on batteries so power is an important issue.
Most have at least one power saving mode (sleep mode, idle mode, standby mode etc.)
Common power-saving mode, one where processor stops executing instructions, stops clock and any built-in peripherals
Drawback – system needs to be restarted to function again  program starts again from the beginning unless necessary measures taken by software
Another mode – microprocessor stops executing instructions but on-board peripherals continue to operate. An interrupt resumes operation from next instruction after it was put to sleep
Saves less power than 1st method, but no special h/w or s/w required. Other things continue to function, e.g. DMA can continue to send data to a UART
Another method – turn entire system off, user will turn it back on when needed. Values that might be needed at restart again need to be stored in non-volatile memory (EEPROM or flash)
4/9/2006