06ec6035 - Advanced Microcontrollers and Real Time Operating Systems

06EC6035 - ADVANCED MICROCONTROLLERS
AND REAL TIME OPERATING SYSTEMS
Compiled by
Jagadeesh Kumar P
jagadeeshkumarp@mec.ac.in
Module2 Part1
2
Reference Book
3
What is an RTOS?
A Real Time Operating System, commonly known as an RTOS, is a software
component that rapidly switches between tasks,
- giving the impression that multiple programs are being executed at the
same time on a single processing core.
In actual the processing core can only execute one program at any one time, and
what the RTOS is actually doing is rapidly switching between individual
programming threads (or Tasks)
- to give the impression that multiple programs are executing

simultaneously.
4
OS or RTOS?
The difference between an OS (Operating System) such as Windows or Unix and an RTOS
(Real Time Operating System) found in embedded systems,
- is the response time to external events.
OS’s typically provide a non-deterministic, soft real time response, where there are no
guarantees as to when each task will complete, but they will try to stay responsive to
the user.
An RTOS differs in that it typically provides a hard real time response, providing a fast,
highly deterministic reaction to external events.
The difference between the two can be highlighted through examples – compare, for
example, the editing of a document on a PC to the operation of a precision motor control.
5
RTOS
Inconsistent terminology - when we discuss real-time operating systems.
Many people use the acronym RTOS (which they pronounce “are toss").
Others use the terms kernel, real-time kernel, or the acronym for this, RTK.
Some use all of these terms synonymously; others use kernel to mean some subcollection
containing the most basic services offered by the larger RTOS.
These latter people consider things like network support software, debugging tools, and
even memory management to be part of the RTOS but not part of the kernel.
Since there is no general agreement about where the kernel stops and the RTOS begins, the
reference book ignores these distinctions and use the term RTOS indiscriminately.
6
RTOS vs OS
The First Place --
Despite the similar name, most real-time operating systems are rather different from
desktop machine operating systems such as Windows or Unix
On a desktop computer, the OS takes the control of the machine as soon as it is turned on
and lets start the application.
- We compile and link the application separately from the OS.
In an Embedded System we usually link the application and RTOS.
- During boot-up time the application usually gets the control first, and then it starts the
RTOS.
- Thus the application and the RTOS are much more tightly tied to one another than an
application and its OS.
7
RTOS vs OS
The Second Place --
Many RTOS do not protect themselves as carefully from the application as do desktop
OS.
Eg. Most desktop OSs check any pointer we pass into a system function is valid, but many
RTOSs skip this step in the interest of better performance.
if the application is doing something like passing a bad pointer into the RTOS, the
application is probably about to crash anyway;
- for many embedded systems, it may not matter if the application takes the RTOS down
with it - the whole system will have to be rebooted anyway.
8
RTOS vs OS
The Third Place --
In the third place, to save memory RTOSs typically include just the services, that we need for
our embedded system and no more.
Most RTOSs allow us to configure them extensively before we link them to the application,
letting us leave out any functions we don't plan to use
Unless we need them, we can configure away such common operating system functions as
file managers, I/O drivers, utilities, and perhaps even memory management,
9
RTOS vs OS
The Third Place --
10
Architectures for Embedded Software
The most important factor that determines which architecture will be the most
appropriate for any given system is how much control we need to have over
system response.
How hard it will be to achieve good response depends not only on the absolute
response time requirements but also
- on the speed of our microprocessor and the other processing

requirements.
11
A system with little to do whose response-time requirements are few and not
particularly stringent can be written with a very simple architecture.
A system that must respond rapidly to many different events and that has
various processing requirements, all with different deadlines and different
priorities, will require a more complex architecture.
12
Will discuss four architectures,
- starting with the simplest one, which offers us practically no control of our
response and priorities, and moving onto others that give us greater control
but at the cost of increased complexity.
The four are
- round -robin , round -robin with interrupts, function-queue-scheduling and

real-time operating system.
13
Round -Robin
Simplest architecture
No interrupts
No shared data
No latency concerns
14
Round -Robin
Adequate for simple jobs – Digital
Multimeter
To measure resistance, current &

Potential
System makes continuous

measurements and changes the
display to reflect the most recent
measurement
15
Round -Robin
Round –robin works well for this
system
There are only 3 I/O devices
No particularly lengthy processing
No tight response requirements
Round robin architecture has only

one advantage – simplicity- but
inadequate for many systems
16
Round -Robin
17
Round -Robin
18
Round -Robin
19
Round-Robin with Interrupts
Interrupt routines deals with very urgent needs of h/d and set flags
Main loop polls the flags and does the follow-up processing required by the
interrupts
Gives a little bit more control over priorities – possible to assign priorities for
various interrupts
Interrupt routines can get good response – μC stops what ever it is doing in main
fn.
20
21
22
Disadvantage
fDeviceA, fDeviceB…. fDeviceZ and other data are shared between the ISR and
the task code in main
Shared data problems …
Committed to use various techniques discussed
23
24
25
Disadvantage
Example: communications bridge
Device with two ports on it that forwards data

traffic received on the first port to the second and
vice versa.
Also assume that – data on one of the ports is

encrypted – bridge has to encrypt and decrypt
the data passes through it
26
Whenever a character is received on one of the ports – it
causes an interrupt – μC must read from the I/O h/d - it must
be serviced reasonably quickly
Must read before the next one arrives
μC write characters to the I/O h/d
I/O h/d sends the characters over the communication link –

and interrupts the μC when it is ready for the next
Routines are there to read characters from and write

characters to queues and test whether a queue is empty or
not.
27
The encryption routine can encrypt characters one at a
time and
Decryption routine can decrypt characters one at a time
28
29
30
31
μC executes the ISRs vGotCharacterOnLinkA and vGotCharacterOnLinkB
whenever the h/d receives a character
The ISR reads the characters from the h/d and put them into the queues
qDataFromLinkA and qDataFromLinkB
The task code in the main routine calls vEncrypt and vDecrypt which
- reads these queues,

- encrypt and decrypt the data and
- write the data to qDataToLinkA and qDataToLinkB
32
The variables fLinkAReadyToSend and fLinkBReadyToSend keep track of
whether I/O h/d is ready to send characters on the two communication links
Whenever the task code sends a character
- It sets the corresponding variable to FALSE

- I/O h/d is now busy – sending characters
When character has been sent ,
- I/O h/d will interrupt and

- ISR sets the variable to TRUE
33
When the task code writes to the h/d or to these varaibles – interrupt is disabled
– to avoid the shared data problem
The ISRs receives the characters and write them to the queues
This process get priority over the process of moving characters among the
queues,
- Decrypting and Encrypting them

- and sending them out
This way a sudden burst of characters will not overrun the system – even if
encryption & decryption process are time consuming
34
Characteristics of Round-Robin-with-Interrupts
All task codes execute at the same priority
Let the task codes that deal with devices A, B, and C take 200ms each
If devices A, B, and C all interrupt when the controller is executing the statements
at the top of the loop
Then task code for C may have to wait 400 milliseconds before it starts to execute.
35
Function Queue Scheduling
The interrupt routines add function pointers to a queue of function pointers
– for the main function to call
The main routine just reads pointers from the queue and calls the functions
No rules says that main has to call the function in the order that the routines
occurred
It can be called based on any priority that suits the purpose
36
37
With a little clever coding that queue up the function parameters
- any task code that need quicker response can be executed earlier
The worst wait for the highest priority task code function is the length of the
longest task code function
- this happens if the longest task code function has just started when the
interrupt for the highest-priority device occurs
This is better than the round-robin-with-interrupts
- is the sum of times taken by all the handlers
38
The trade-off for this better response –
The response for the lower priority task functions may get worse
Under round-robin-with-interrupts all of the task code gets a chance to run each
time main goes around the loop
But here, lower priority functions may never execute if the interrupt routines
schedule the higher priority functions frequently
39
Real Time Operating System Architecture
Interrupt routines take care of most urgent operations
Then they signal that there is work for the task code to do
void interrupt vHandleDeviceA (void)
{ !! Take care of Device A
!!Set signal X }
void interrupt vHandleDeviceB (void)
{ !! Take care of Device B
!!Set signal Y } ………

40
void Task1 (void)
{ while (True)
{ !!wait for signal X
!!Handle data to or from i/o device A} }
void Task2 (void)
{ while (True)
{ !!wait for signal Y
!!Handle data to or from i/o device B}
} ………
41
Features
The signaling between the interrupt routines and the task code is handled by the RTOS
Need not use shared variables for this
Code inside the RTOS decides which of the task code function to run
RTOS knows about the various task code routines and run based on urgency
RTOS can suspend one task code routine in the middle of its processing to run another
42
In the previous example
If task1 is of higher priority than task2 and If task2 is in the middle of processing and If interrupt routine
vHandleDeviceA sets the signal X, then
- RTOS will suspend Task2 and run Task1
The worst case wait time for the highest priority task code is zero
changes to lower priority tasks do not generally affect the response of higher priority ones
43
Disadvantage of using RTOS
RTOS itself uses a certain amount of processing time
We are getting a better response at the expense of a little bit of throughput
Selecting an architecture
Select the simplest architecture that will meet the response requirements
Writing embedded system software itself is complicated enough
If the system has requirements that necessitate an RTOS then lean toward using it
Select an appropriate RTOS which has a collection of useful tools to test and debug the system
If it make sense for the system – create hybrids of architectures

44
Characteristics of various architectures
Round Robin
Priorities available
- None
Worst response time for Task Code
- Sum of all task code
Stability of response when the code changes
- Poor
Simplicity
- Very simple
45
Round Robin with interrupts
- Interrupt routines in priority order – then all task code at the same priority
- Sum of all task code
- Good for interrupt routines but Poor for task code
Simplicity
- Must deal with data sharing problem

46
Function Queue scheduling
- Interrupt routines in priority order – then task code in priority order
- Execution time of the longest function
- Relatively Good
Simplicity
- Must deal with data sharing problem and write function queue code
47
Real Time OS
- Interrupt routines in priority order – then task code in priority order
- Zero
- Very Good
Simplicity
- Most complex – much of the complexity is inside the OS
48
49

06ec6035 - Advanced Microcontrollers and Real Time Operating Systems

Uploaded by

Copyright:

Available Formats

You might also like

06ec6035 - Advanced Microcontrollers and Real Time Operating Systems

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

06ec6035 - Advanced Microcontrollers and Real Time Operating Systems

Uploaded by

Copyright:

Available Formats

06EC6035 - ADVANCED MICROCONTROLLERS

AND REAL TIME OPERATING SYSTEMS

- to give the impression that multiple programs are executing

- is the response time to external events.

- We compile and link the application separately from the OS.

In an Embedded System we usually link the application and RTOS.

- on the speed of our microprocessor and the other processing

The four are

- round -robin , round -robin with interrupts, function-queue-scheduling and

To measure resistance, current &

System makes continuous

There are only 3 I/O devices

No particularly lengthy processing

No tight response requirements

Round robin architecture has only

Shared data problems …

Committed to use various techniques discussed

Example: communications bridge

Device with two ports on it that forwards data

Also assume that – data on one of the ports is

Must read before the next one arrives

μC write characters to the I/O h/d

I/O h/d sends the characters over the communication link –

Routines are there to read characters from and write

Decryption routine can decrypt characters one at a time

- reads these queues,

Whenever the task code sends a character

- It sets the corresponding variable to FALSE

When character has been sent ,

- I/O h/d will interrupt and

- Decrypting and Encrypting them

It can be called based on any priority that suits the purpose

This is better than the round-robin-with-interrupts

- is the sum of times taken by all the handlers

void interrupt vHandleDeviceA (void)

{ !! Take care of Device A

void interrupt vHandleDeviceB (void)

{ !! Take care of Device B

!!Set signal Y } ………

{ !!wait for signal X

!!Handle data to or from i/o device A} }

void Task2 (void)

{ !!wait for signal Y

!!Handle data to or from i/o device B}

Need not use shared variables for this

- RTOS will suspend Task2 and run Task1

RTOS itself uses a certain amount of processing time

We are getting a better response at the expense of a little bit of throughput

Writing embedded system software itself is complicated enough

If it make sense for the system – create hybrids of architectures

Worst response time for Task Code

- Sum of all task code

Stability of response when the code changes

Worst response time for Task Code

- Sum of all task code

Stability of response when the code changes

- Good for interrupt routines but Poor for task code