Basic Design Using An RTOS Basic Design Using An RTOS: General Operation General Operation

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 4

Basic Design using an RTOS

8
Embedded Systems
Basic Design using an RTOS
Embedded Systems
Dept. of Electrical Engineering
Kangnung National University
Dept. of Electrical Engineering
Kangnung National University
J ungho Moon
Kangnung National University Kangnung National University
General Operation General Operation
1
b dd d b d Embedded systems are based on interrupts
Embedded systems have nothing to do until the
passage of time or some external event requires a
response
A normal embedded system design
To have each of the RTOS tasks spend most of the
time blocked, waiting for an ISR or another task to tell
that there is something for it to do
Embedded Systems Embedded Systems
Interrupts Interrupts
2
h d f f b dd d f The driving force of embedded software
Make interrupt routines as short as possible p p
Even the lowest-priority interrupt routine is executed
in preference to the highest-priority task code p g p y
Longer interrupt routines result in slower task-code
response
Interrupt routines tend to be more bug-prone and
harder to debug than task code
Make the interrupt routine do the immediate
actions and then signal a task to do the rest g
Embedded Systems Embedded Systems
HowMany Tasks? How Many Tasks?
3
One of the first problems in an embedded
system design is to divide your systems work y g y y
into RTOS tasks
Advantages with more tasks Advantages with more tasks
Better control of the relative response times of the
diff t t f t k different parts of your systems work
More modular software
More effective encapsulation of data
Embedded Systems Embedded Systems
HowMany Tasks? (Contd) How Many Tasks? (Cont d)
4
d h k Disadvantages with more tasks
More data shared among two or more tasks
More requirements to pass messages from one task to
another
More memory, at least for stack space, and perhaps
for inter-task messages as well
Less throughput due to more context switches
More calls to the RTOS
Conclusion
Use as fewtasks as you can get away with; add more Use as few tasks as you can get away with; add more
tasks to your design only for clear reasons
Embedded Systems Embedded Systems
When to Add More Tasks When to Add More Tasks
5
d k f You need tasks for priority
You can assign higher priorities to parts of the work
with tighter response time requirements
You need tasks for encapsulation p
It makes sense to have a separate task to deal with
shared hardware
Suggestions about dividing your system into
tasks tasks
Have many small tasks, so that each is simple
Have separate tasks for work that needs to be done in Have separate tasks for work that needs to be done in
response to separate stimuli
Embedded Systems Embedded Systems
Recommended Task Structure Recommended Task Structure
6
void vTaskA(void *pdata) {
!! More private data declared here, either static or on the stack
!! Initialization code if needed !! Initialization code if needed
while(FOREVER)
{
!! Wait for a system signal (event, message, etc.)
switch(!! type of signal)
{
case !! signal type 1:
Ad t
case !! signal type 1:
:
break;
Advantages
The task blocks in only one place
When there is nothing to do the input
case !! signal type 2:
:
break;
When there is nothing to do, the input
queue will be empty and the task will
block
There is no public data that other
:
}
}
There is no public data that other
tasks can share
Embedded Systems Embedded Systems

You might also like