Scribd
Upload
155 views

6.0 Introduction To Real-Time Operating Systems (Rtos)

This document introduces real-time operating systems (RTOS). It discusses key RTOS concepts like tasks, states, scheduling, shared data, reentrancy, and semaphores. Semaphores provide protection for shared resources and help avoid issues caused by concurrent access to shared data from multiple tasks. Care must be taken to initialize semaphores properly and ensure symmetric taking and releasing to avoid problems. [/SUMMARY]

Uploaded by

dhananjaypatilme
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
155 views

6.0 Introduction To Real-Time Operating Systems (Rtos)

This document introduces real-time operating systems (RTOS). It discusses key RTOS concepts like tasks, states, scheduling, shared data, reentrancy, and semaphores. Semaphores provide protection for shared resources and help avoid issues caused by concurrent access to shared data from multiple tasks. Care must be taken to initialize semaphores properly and ensure symmetric taking and releasing to avoid problems. [/SUMMARY]

Uploaded by

dhananjaypatilme
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 35

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.0 INTRODUCTION TO RTOS

 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.0 INTRODUCTION TO RTOS

 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.0 INTRODUCTION TO RTOS

 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
6.0 INTRODUCTION TO RTOS

 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.0 INTRODUCTION TO RTOS

 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.0 INTRODUCTION TO RTOS

 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)


6.0 INTRODUCTION TO RTOS

 6.3 Semaphores and Shared Data – 2

 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
6.0 INTRODUCTION TO RTOS

 6.3 Semaphores and Shared Data – 3

 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)


6.0 INTRODUCTION TO RTOS

 6.3 Semaphores and Shared Data – 4

 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

You might also like