6.0 Introduction To Real-Time Operating Systems (Rtos)

6.
0 INTRODUCTION TO REAL-TIME OPERATING SYSTEMS (RTOS)
 6.0 Introduction
 A more complex software architecture is needed to handle multiple tasks,
coordination, communication, and interrupt handling – an RTOS architecture
 Distinction:
 Desktop OS – OS is in control at all times and runs applications, OS runs in
different address space
 RTOS – OS and embedded software are integrated, ES starts and activates the
OS – both run in the same address space (RTOS is less protected)
 RTOS includes only service routines needed by the ES application
 RTOS vendors: VsWorks (we got it!), VTRX, Nucleus, LynxOS, C/OS
 Most conform to POSIX (IEEE standard for OS interfaces)
 Desirable RTOS properties: use less memory, application programming interface,
debugging tools, support for variety of microprocessors, already-debugged
network drivers
6.0 INTRODUCTION TO RTOS
 6.1 Tasks and Task States
 A task – a simple subroutine

 ES application makes calls to the RTOS functions to start tasks, passing to the
OS, start address, stack pointers, etc. of the tasks
 Task States:
 Running
 Ready (possibly: suspended, pended)
 Blocked (possibly: waiting, dormant, delayed)
 [Exit]
 Scheduler – schedules/shuffles tasks between Running and Ready states

 Blocking is self-blocking by tasks, and moved to Running state via other tasks’
interrupt signaling (when block-factor is removed/satisfied)
 When a task is unblocked with a higher priority over the ‘running’ task, the scheduler
‘switches’ context immediately (for all pre-emptive RTOSs)
 (See Fig 6.1)
 6.1 Tasks – 1
 Issue – Scheduler/Task signal exchange for block-unblock of tasks via function calls
 Issue – All tasks are blocked and scheduler idles forever (not desirable!)
 Issue – Two or more tasks with same priority levels in Ready state (time-slice, FIFO)
 Example: scheduler switches from processor-hog vLevelsTask to vButtonTask (on user

interruption by pressing a push-button), controlled by the main() which initializes the
RTOS, sets priority levels, and starts the RTOS
 (See Fig 6.2, Fig 6.3, Fig 6.4)

 6.3 Tasks and Data
 Each tasks has its won context - not shared, private registers, stack, etc.
 In addition, several tasks share common data (via global data declaration; use of
‘extern’ in one task to point to another task that declares the shared data
 Shared data caused the ‘shared-data problem’ without solutions discussed in Chp4 or
use of ‘Reentrancy’ characterization of functions
 (See Fig 6.5, Fig 6.6, Fig 6.7, and Fig 6.8)
 6.2 Tasks – 2
 Reentrancy – A function that works correctly regardless of the number of tasks

that call it between interrupts
 Characteristics of reentrant functions –

 Only access shared variable in an atomic-way, or when variable is on callee’s stack
 A reentrant function calls only reentrant functions
 A reentrant function uses system hardware (shared resource) atomically
 Inspecting code to determine Reentrancy:
 See Fig 6.9 – Where are data stored in C? Shared, non-shared, or stacked?
 See Fig 6.10 – Is it reentrant? What about variable fError? Is printf reentrant?
 If shared variables are not protected, could they be accessed using single assembly
instructions (guaranteeing non-atomicity)?
 6.3 Semaphores and Shared Data – A new tool for atomicity
 Semaphore – a variable/lock/flag used to control access to shared resource (to avoid

shared-data problems in RTOS)
 Protection at the start is via primitive function, called take, indexed by the semaphore
 Protection at the end is via a primitive function, called release, also indexed similarly
 Simple semaphores – Binary semaphores are often adequate for shared data problems
in RTOS
 (See Fig 6.12 and Fig 6.13)

 6.3 Semaphores and Shared Data – 1
 RTOS Semaphores & Initializing Semaphores
 Using binary semaphores to solve the ‘tank monitoring’ problem

 (See Fig 6.12 and Fig 6.13)
 The nuclear reactor system: The issue of initializing the semaphore variable in a
dedicated task (not in a ‘competing’ task) before initializing the OS – timing of tasks
and priority overrides, which can undermine the effect of the semaphores
 Solution: Call OSSemInit() before OSInit()
 (See Fig 6.14)

 Reentrancy, Semaphores, Multiple Semaphores, Device Signaling,
 Fig 6.15 – a reentrant function, protecting a shared data, cErrors, in critical section
 Each shared data (resource/device) requires a separate semaphore for individual

protection, allowing multiple tasks and data/resources/devices to be shared
exclusively, while allowing efficient implementation and response time
 Fig 6.16 – example of a printer device signaled by a report-buffering task, via

semaphore signaling, on each print of lines constituting the formatted and buffered
report
 Semaphore Problems – ‘Messing up’ with semaphores

 The initial values of semaphores – when not set properly or at the wrong place
 The ‘symmetry’ of takes and releases – must match or correspond – each ‘take’
must have a corresponding ‘release’ somewhere in the ES application
 ‘Taking’ the wrong semaphore unintentionally (issue with multiple semaphores)
 Holding a semaphore for too long can cause ‘waiting’ tasks’ deadline to be missed
 Priorities could be ‘inverted’ and usually solved by ‘priority inheritance/promotion’
 (See Fig 6.17)
 Causing the deadly embrace problem (cycles)
 (See Fig 6.18)

 Variants:
 Binary semaphores – single resource, one-at-a time, alternating in use (also for
resources)
 Counting semaphores – multiple instances of resources, increase/decrease of
integer semaphore variable
 Mutex – protects data shared while dealing with priority inversion problem
 Summary – Protecting shared data in RTOS

 Disabling/Enabling interrupts (for task code and interrupt routines), faster
 Taking/Releasing semaphores (can’t use them in interrupt routines), slower,
affecting response times of those tasks that need the semaphore
 Disabling task switches (no effect on interrupt routines), holds all other tasks’
response

6.0 Introduction To Real-Time Operating Systems (Rtos)

Uploaded by

Copyright:

Available Formats

6.0 Introduction To Real-Time Operating Systems (Rtos)

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

6.0 Introduction To Real-Time Operating Systems (Rtos)

Uploaded by

Copyright:

Available Formats

6.

0 INTRODUCTION TO REAL-TIME OPERATING SYSTEMS (RTOS)

 6.1 Tasks and Task States

 A task – a simple subroutine

 Scheduler – schedules/shuffles tasks between Running and Ready states

 Example: scheduler switches from processor-hog vLevelsTask to vButtonTask (on user

 (See Fig 6.2, Fig 6.3, Fig 6.4)

 6.3 Tasks and Data

 Reentrancy – A function that works correctly regardless of the number of tasks

 Characteristics of reentrant functions –

 Inspecting code to determine Reentrancy:

 6.3 Semaphores and Shared Data – A new tool for atomicity

 Semaphore – a variable/lock/flag used to control access to shared resource (to avoid

 (See Fig 6.12 and Fig 6.13)

 6.3 Semaphores and Shared Data – 1

 RTOS Semaphores & Initializing Semaphores

 Using binary semaphores to solve the ‘tank monitoring’ problem

 Solution: Call OSSemInit() before OSInit()

 (See Fig 6.14)

 6.3 Semaphores and Shared Data – 2

 Reentrancy, Semaphores, Multiple Semaphores, Device Signaling,

 Each shared data (resource/device) requires a separate semaphore for individual

 Fig 6.16 – example of a printer device signaled by a report-buffering task, via

 6.3 Semaphores and Shared Data – 3

 Semaphore Problems – ‘Messing up’ with semaphores

 (See Fig 6.17)

 Causing the deadly embrace problem (cycles)

 (See Fig 6.18)

 6.3 Semaphores and Shared Data – 4

 Summary – Protecting shared data in RTOS

You might also like