Basic Design Using Rtos
Basic Design Using Rtos
UNIT-II
PART B
Contents:
Principles,
Encapsulating Semaphores and queues,
Hard real-time scheduling considerations,
Saving memory and power,
An example RTOS like µC-OS (open source)
I. PRINCIPLES:
A very normal embedded system design technique is to have each of the RTOS tasks spend most of the
time blocked, waiting for an interrupt routine or another task to send a message or cause an event or
free a semaphore to tell the task that there is something for it to do.
When an interrupt occurs, the interrupt routine uses the RTOS services to signal one or more of the
task, each of which then does its work and each of which may then signal yet other task. In this way,
each interrupt can create a cascade of signals and task activity.
The following figure1 shows a very simplified version of some of what happens inside the telegraph
system. In that figure the curvy arrows indicate message passed through the RTOS.
When the system receives a network frame, the hardware interrupts. The interrupts routine reset the
hardware and then passes a message containing the received frame to the DDP (datagram delivery
protocol) protocol task.
The DDP protocol task was blocked waiting for a message. When this message arrives, the task wakes
up and among many of other things, determines if the frame was intended for telegraph or received by
telegraph by mistake.
If the frame was intended for telegraph, the DDP protocol task sends a message containing the
received frame to the ADSP (Apple Talk data Stream Protocol) protocol task.
This message unblocks the ADSP protocol task, if the frame contains print data; the ADSP protocol task
sends a message containing the data to the serial-port task, which sends a data to the serial port
hardware and through it to the printer.
Similarly, when the system receives serial data from the printer, the interrupt routine resets the
hardware and forwards the data in a message to the serial port task.
If the data contains printer status, the serial port task forward the status to the ADSP, the ADSP uses it
when respond to later status request from the network.
4. Encapsulation of tasks
Short interrupt routines are preferable than long interrupt routines. Interrupt routine code requiring
immediate /quick response.
There are two reasons for this.
1. Even lowest priority IR’s are handled before the highest priority task code (minimize task code
response time), writing a longer interrupt routines translates directly into slower task code
response.
2. IR’s are error prone and hard to debug than task code (due to hardware-dependent software
parts)
Suppose that we are writing the software for the system with the following characteristics:
One wretched way to write this system is to do all of the work in the interrupt routine that receives
characters.
That interrupt routine will be long and complex and difficult to debug and it will be slow response
for every operation.
At the opposite extreme you could write this system with an entirely brainless interrupt routine
that simply forwards every character in an RTOS as message to command parsing task.
One possible compromise design uses an interrupt routine that saves the received characters in a
buffer and watches for the carriage return that ends each command.
When the carriage return arrives, the interrupt routine sends a single message to the command
parsing task, which reads the characters out of the buffer.
Advantages:
Disadvantages:
With more tasks you are likely to have more data shared among two or more tasks. This will make the
system to have more semaphores, and hence into more microprocessors time to handle semaphores
and into more semaphore related bugs.
With more tasks you are likely to have more requirements to inter task communication through pipes,
mailboxes queues and so on. This will also translate more microprocessor time and more chances for
bugs.
Each task requires a stack; therefore more tasks probably need more memory, at least for stack space.
Each time the RTOS switches tasks. It takes more microprocessor time for saving the context of the
task that is stopping and restoring the context of the task about to run.
3. Task Priorities:
Decomposing based on ‘functionality’ and ‘time criticality,’ separates ES components into tasks
(naturally), task prioritization will give the quicker response – high priority for time-critical ones, and
low priority for others.
It makes sense to have a separate task to deal with hardware shared by different parts of the system.
A single task that controls the hardware display can solve these problems.
When other task in the system has information to display, they send messages to the display task.
The RTOS will ensure that messages sent to the display task are queued properly; Simple logic in the
display task can then decide which message should be placed on the display.
The task structure will give the overall information about private data and its life time. And how
many number of times that will execute, and from which task it reads data and to which any number
of other tasks it write.
The task blocks in only one place. When another task puts a request on its task queue; this task is not
in the off waiting for some other event that may or may not happen in a timely fashion.
When there is nothing to for this task to do, its input queue will be empty, and the task will block and
use up on microprocessor time.
This task does not have public data that other tasks can share, so there is no shared data, and there
are no semaphores and semaphore problems.
Most RTOSs also allow us to create and destroy tasks while system is running.
The situation in which, if two or more ready tasks have the same priority and no other ready task has
a high priority.
One option that most other task offer in this situation is to time slice among those tasks.
EMBEDDED SYSTEMS-By BRN Page 5
UNIT-2 Basic Design Using a RTOS Contents ECE DEPARTMENT
Giving the microprocessor to one of the tasks for a short period of time, and then switching the
microprocessor to the other task for a small period of time and so on.
One might want to consider whether they want to have two tasks with the priority or whether they
could just as well be one task. RTOS allows turning off this option.
Measures read:
Set an alarm on leaking tank (when level slowly and consistently falls over time)
System can override user display options and show warning messages
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 float-hardware 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-calc, 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.
Low priority task to handle report formatting (one line at a time), and handle report queue
(See below table Table 8.2)
o User presses button, button hardware interrupts the microprocessor, the button IR sends
message to button-handling task to interpret command, which activates display task or
printer task
o Timer interrupts, timer IR -> signal to Overflow-Detection task
o User presses printer button, print IR signals print-formatting task -> which sends first line
to printer; printer interrupts for print IR to send next line to printer; when all lines (for
report) are done, print IR signals print-formatting task for next report
o A level task need to read, it interrupts the level-read-hardware routine; the level is read by
the hardware and the IR interrupts the task to read the new float level
Encapsulating Semaphores:
At least some of those bugs stem from undisciplined use. You can squash these bugs before they get
crawling simply by hiding the semaphore and the data that it protects inside of a module.
In the above code , rather than letting just any code that wants the value of the lSecondsToday variable
read it directly and hopping for the best, this construction forces any code that wants to know the
value of lSecondsToday to call lSecondSinceMidnight to get it. lSecondSinceMidnight uses the
semaphore correctly. This semaphore will cause no more bugs.
EMBEDDED SYSTEMS-By BRN Page 9
UNIT-2 Basic Design Using a RTOS Contents ECE DEPARTMENT
Encapsulating queues:
Similarly, you should consider encapsulating queues that task use to receive messages from other
tasks. We should write code to handle a shared flash memory. That code deals correctly with
synchronizing the requests for reading from and writing to flash memory. However, it would probably
be a bad idea to ship that code in a real system.
Consider this list of potential bugs.
Even if everyone uses the correct structure, some body may assign a value to flash other than one of
the two legal values.
Anybody accidentally write a message intended for the flash task to the wrong queue.
Any task might destroy the flash task input queue by mistake.
The flash task sends data it read from the flash back through another queue. Someone might send an
invalid queue ID.
Considerations:
A hard real time system is hard or software that must operate within the deadline, which comes from
fast code. A hard RTOS is one which has predictable performance with no deadline miss.
Saving Power:
Sleep mode
Low-power mode
Ideal mode
Standby mode
A very common power saving mode is one in which the microprocessor stops executing instructions,
stop any built in peripherals, and stops its clock circuit. This saves a lot of power, but the drawback is
that the only way to start the microprocessor is to restart it.
Another typical power saving mode is one in which the microprocessor stops executing instructions
but the on board peripheral continue to operate. Any interrupt starts the microprocessor up again, and
the microprocessor will execute the corresponding interrupt routine and then resume the task code
from the instruction that follows the one that put the microprocessor to sleep. This method saves less
power than the above method.
Another common method for saving power is to turn off the entire system and user turn it back on
when it is needed.
If we want to put our microprocessor in power saving mode, we should plan to write fast software. The
faster your software finishes its work, the sooner it can put the microprocessor back into a power
saving mode and stop using up the battery.