CS722PE: REAL TIME SYSTEMS

(Professional Elective - V)
IV Year [Link]. IT I -Sem
 UNIT – III
• Objects, Services and I/O:
– Pipes,
– Event Registers,
– Signals,
– Other Building Blocks,
– Component Configuration,
– Basic I/O Concepts,
– I/O Subsystem
 RTOS Objects
• In Real-Time Operating Systems (RTOS), managing tasks, inter-task communication,
synchronization, and handling input/output (I/O) are critical components to ensure
deterministic performance and meet real-time deadlines.
• A. Tasks/Threads: A task (or thread) is the smallest unit of execution in an RTOS. It represents
a sequence of instructions that the CPU executes.
• B. Semaphores: Synchronization primitives used to control access to shared resources and
prevent race conditions. They come in two types: binary semaphores (used for locking) and
counting semaphores (used to manage multiple instances of a resource).
• C. Mutexes: A mutex is a mutual exclusion object similar to a binary semaphore but with the
added functionality of priority inheritance. This prevents priority inversion, where a higher-
priority task is waiting for a lower-priority task to release the mutex.
• D. Message Queues: Message queues are used for inter-task communication by passing
messages between tasks. Queues ensure that data sent by one task is received and processed
by another in an ordered and synchronized manner.
 RTOS Services
• RTOS services include mechanisms that allow tasks to
communicate, synchronize, and cooperate with each other and
with the hardware.
– a. Task Scheduling: The RTOS schedules tasks based on their priority and
the scheduling algorithm (e.g., round-robin, priority-based preemptive
scheduling).
– b. Inter-Task Communication (IPC):IPC mechanisms like pipes, message
queues, and shared memory allow tasks to exchange data and
synchronize execution.
– c. Event Flags/Registers: Event flags or event registers are used to signal
events between tasks. A task can wait for one or more event flags to be
set before proceeding.
– d. Timers: Timers are used to execute tasks or perform actions after a
specified delay or at regular intervals.
 Basic I/O Concepts in RTOS
• I/O in an RTOS is typically event-driven to ensure tasks are
responsive and efficient. Key I/O concepts include:
• a. Polling vs Interrupt-Driven I/O
– Polling: In polling, a task continuously checks the status of an I/O
device, consuming CPU resources.
– Interrupt-Driven I/O: The CPU only responds to I/O events when the
device raises an interrupt, allowing tasks to perform other work in the
meantime.
• b. I/O Buffers: Buffers store data temporarily between I/O
devices and tasks, improving performance by allowing tasks to
proceed without waiting for I/O operations to complete.
 I/O Subsystem in RTOS
• The I/O subsystem is responsible for managing devices,
handling data transfers, and providing interfaces for
applications to access peripherals.
• a. Device Drivers: Device drivers provide a standardized
interface to hardware devices, abstracting the details of
hardware operation from the application layer.
• b. I/O Scheduling: I/O scheduling determines the order in
which I/O operations are performed, ensuring real-time
constraints are met.
 1. Pipes in RTOS
• Pipes are a form of Inter-Process Communication
(IPC) mechanism that allows tasks or threads in a
Real-Time Operating System (RTOS) to exchange
data.
• Pipes provide a buffered communication channel
between tasks, similar to message queues but
typically more suitable for streaming data or bulk
transfer.
• Pipes in RTOS are widely used when tasks need to
communicate in a producer-consumer fashion.
 What is a Pipe?
• A pipe can be thought of as a temporary buffer between
two endpoints, where one task (producer) writes data to
the pipe, and another task (consumer) reads from it.
Pipes can either be:
• Unidirectional: Only one task writes, and another reads.
• Bidirectional: Both tasks can write and read from the
pipe.
• A pipe often uses a FIFO (First In, First Out) buffer,
meaning that data written first to the pipe is read first.
This makes pipes useful for transferring ordered data
streams in real-time systems, such as sensor data or logs.
 Pipes: Key Characteristics
• Unidirectional/Bidirectional: Pipes can be either unidirectional (data flows in one
direction) or bidirectional (data flows in both directions).
• FIFO Structure: Pipes generally follow a First-In-First-Out (FIFO) principle, ensuring
that the order of the data sent by one task is the same as the order in which it is
received by the other task.
• Buffered Communication: A pipe has a finite buffer size, which defines how much
data can be held in the pipe at any given time.
• Non-blocking and Blocking Modes: Tasks can block (wait) if the pipe is full (for
writes) or empty (for reads). In non-blocking mode, a task either reads or writes
based on pipe availability without waiting.
• Synchronization: Pipes implicitly synchronize between tasks. A writer task can write
to the pipe only when space is available in the buffer, and a reader task can only read
when data is available.
• Streamed or Packet-based: Pipes are typically used to send continuous streams of
data, unlike message queues, which often work with discrete messages.
 Structure of RTOS Pipes
• Write Endpoint: A task writes data to the pipe.
• Read Endpoint: A task reads data from the
pipe.
• Buffer: The buffer stores the data until the
receiving task consumes it
 How Pipes Work in RTOS
• When a task writes data to the pipe:
– The RTOS checks if the pipe's buffer has enough space to store the incoming data.
– If the buffer has space, the data is written to the pipe, and the task continues.
– If the buffer is full, the behavior depends on whether the pipe is blocking or non-
blocking:
• In blocking mode, the writing task is suspended until the buffer has space.
• In non-blocking mode, the write operation fails or returns an error.

• Similarly, when a task reads from the pipe:

– The RTOS checks if the pipe contains any data.
– If the pipe has data, the task reads it, and the data is removed from the buffer.
– If the pipe is empty, the behavior depends on the mode:
• In blocking mode, the reading task is suspended until data becomes available.
• In non-blocking mode, the read operation fails or returns an error.
 Pipe Operations
• a. Creating a Pipe
• Before any data transfer, a pipe must be created with a defined buffer size. The
size limits the maximum amount of data that can be written into the pipe before
the writer task gets blocked (if the pipe is full).
• b. Writing to a Pipe
• A task can write data to the pipe buffer. If there is enough space, the data is
written immediately. If the pipe is full, the task may block until space becomes
available or return an error (in non-blocking mode).
• c. Reading from a Pipe
• A consumer task reads data from the pipe. If there is data available, it is read
into the task’s buffer. If the pipe is empty, the task may block until data becomes
available or return an error (in non-blocking mode).
• d. Deleting a Pipe
• Once the pipe is no longer needed, it can be deleted to free up memory and
resources.
 Blocking vs Non-blocking Pipes
• Blocking Mode: The calling task will block (wait) if the pipe is
full (for writes) or empty (for reads). This ensures that the
task waits until the desired condition (space or data
availability) is met.
– Use Case: When data exchange is critical, and the system must
ensure the data is transmitted/received correctly.
• Non-blocking Mode: The calling task will return immediately
with a success or failure code, based on the availability of
space (for writes) or data (for reads). This allows tasks to
continue other operations even if the pipe is not ready.
– Use Case: When the system is time-sensitive and cannot afford to
wait for pipe conditions to change.
RTOS Pipe Example: Producer-Consumer

• Imagine a system where Task A collects

temperature sensor data and Task B processes
this data. They use a pipe for communication.
Task A writes the sensor data to the pipe, and
Task B reads the data and logs or analyzes it.
 Advantages & Limitations.
• Advantages of RTOS Pipes
– Real-Time Communication: Tasks can exchange data quickly and in real
time, which is essential for embedded systems that require low-latency
communication.
– Task Synchronization: Pipes inherently synchronize tasks by ensuring
that the receiving task waits for data or the sending task waits for buffer
space.
– Simple API: Most RTOS provide simple and intuitive APIs for pipe
communication, making it easy to implement.
• Limitations
– Buffer Size: If the buffer size is too small, tasks may experience frequent
blocking, leading to potential performance bottlenecks.
– Priority Inversion: In some cases, lower-priority tasks may block higher-
priority tasks from accessing the pipe.
 2. RTOS- Event Registers
• In Real-Time Operating Systems (RTOS), event
registers (also known as event flags or event
groups) are mechanisms used for inter-task
synchronization and communication.
• They allow tasks to signal or wait for specific
events, often using bit-level signaling, making
them very useful in complex real-time
applications where tasks need to wait for
multiple conditions to be met before proceeding.
Characteristics of RTOS Event Registers
• Bit-Based Signaling: Event registers consist of multiple
bits, where each bit represents a specific event or
condition. Tasks can set, clear, or wait for one or more
bits in the event register.
• Synchronization Tool: Event registers are ideal for
synchronizing tasks with different conditions or events,
allowing tasks to wait for multiple events
simultaneously.
• Multi-Event Handling: A task can wait for one or more
bits (events) to be set, making it possible to synchronize
based on complex combinations of conditions.
 Structure of Event Registers
• Event Bits: Each bit in the event register corresponds to a
specific event or condition.
• Task Operations: Tasks can perform various operations on
the event register:
– Set: Set one or more bits to signal that specific events have
occurred.
– Clear: Clear one or more bits once the event has been handled.
– Wait: Wait for one or more bits to be set, meaning the task will
block until the desired event(s) occur.
• Event Group/Flag Object: RTOS provides a specific object to
represent event registers, usually called an "event group" or
"event flag."
 How RTOS Event Registers Work
• When a task sets one or more bits in the event
register, it signals that specific events have
occurred.
• Other tasks can wait for specific bits in the
event register to be set before they proceed.
• A task can clear event bits after handling the
event so that the event register can be reused
for new events.
 Common Event Register Operations
• xEventGroupSetBits(EventGroupHandle_t xEventGroup,
const EventBits_t uxBitsToSet):
– Sets the bits specified by uxBitsToSet in the event group.
• xEventGroupClearBits(EventGroupHandle_t
xEventGroup, const EventBits_t uxBitsToClear):
– Clears the bits specified by uxBitsToClear in the event group.
• xEventGroupWaitBits(EventGroupHandle_t xEventGroup,
const EventBits_t uxBitsToWaitFor, BaseType_t
xClearOnExit, BaseType_t xWaitForAllBits, TickType_t
xTicksToWait):
– Waits for the specified bits to be set.
 Example Scenario: Monitoring Multiple
Sensors
• Imagine a system where several sensors (e.g.,
temperature, humidity, and pressure) generate events
that need to be processed by a single task.
• Using event registers, each sensor can signal its data
readiness by setting a specific bit, and the processing
task waits for multiple bits to be set before proceeding.
• Task Flow:
– Each sensor task signals when new data is ready by setting
its corresponding event bit.
– The processing task waits for all sensor events (bits) to be
set before processing the sensor data.
 Example Scenario: Multi-Event
Synchronization in a Networked System
• Consider an RTOS-based networking system where
multiple network interfaces are monitored. Each
interface can signal the occurrence of different types of
network events, such as:
• Data Received Event: A bit is set when new data arrives.
• Connection Established Event: A bit is set when a
connection is successfully established.
• Error Event: A bit is set when a network error occurs.
• The task responsible for network management waits for
any of these events and handles them accordingly.
 Advantages of Event Registers
• Efficient Event Handling: Event registers allow tasks to wait for
one or multiple events without constant polling, making it an
efficient mechanism for synchronization.
• Multiple Event Sources: A single task can wait for events from
multiple sources (e.g., sensors, network interfaces) using the
same event register.
• Simplified Task Coordination: Tasks can be synchronized
based on complex conditions involving multiple events or
signals.
• Clear and Set Operations: Event bits can be cleared
automatically or manually, allowing for flexible handling of
recurring events.
 Limitations
• Bit Limitations: Event registers usually have a fixed
number of bits (e.g., 32 bits), limiting the number of
distinct events that can be represented.
• Task Priority Inversion: If not managed carefully,
lower-priority tasks setting or clearing event bits can
affect the behavior of higher-priority tasks waiting for
those bits.
 3. RTOS Signals
• In Real-Time Operating Systems (RTOS), signals
are a mechanism for inter-task communication
and synchronization.
• They allow tasks to send notifications or
interrupt other tasks when specific events occur.
• Signals are particularly useful in scenarios where
tasks need to respond to asynchronous events,
making them a crucial component of real-time
systems.
 Characteristics of RTOS Signals
• Asynchronous Notifications: Signals can notify tasks of
events that occur outside their normal execution flow.
• Event-Driven: Signals are often used in event-driven
programming, where tasks react to incoming signals
rather than continuously polling for conditions.
• Task Synchronization: Signals can synchronize the
execution of tasks, allowing them to wait for specific
conditions before proceeding.
• Low Overhead: Signals typically have low overhead,
making them suitable for performance-critical
applications.
 Types of Signals
• Simple Signals: Basic notifications that
indicate an event has occurred. For example, a
task can send a signal to indicate that data is
available for processing.
• Parameterized Signals: Signals can carry
additional information or parameters. For
instance, a signal might indicate that a timer
has expired, along with the elapsed time.
 Signal Mechanisms in RTOS
• Different RTOS implementations have various
mechanisms for handling signals. Below are
common signal-related operations:
– Send Signal: A task can send a signal to another task
to notify it of an event.
– Receive Signal: A task can wait for a signal to be
sent, allowing it to block until an event occurs.
– Signal Masking: Tasks may have the option to mask
(ignore) specific signals, providing control over
which signals can interrupt their execution.
 Example Scenario: Task Synchronization
with Signals
• Consider a system where multiple tasks need
to coordinate their actions based on external
events, such as a button press or timer
expiration.
• Using signals, one task can notify another
when it’s time to perform an action.
 Advantages & Limitations
• Advantages of RTOS Signals
– Efficient Communication: Signals allow for efficient communication
between tasks without continuous polling, saving CPU resources.
– Decoupled Design: Tasks can be designed independently, only needing
to know about the signals they send and receive, promoting modularity.
– Immediate Response: Signals enable immediate task responses to
events, which is crucial in real-time systems.

• Limitations
– Complexity: Managing signals, especially in complex systems, can lead
to intricate dependencies and timing issues.
– Priority Inversion: If not handled correctly, low-priority tasks can block
higher-priority tasks from responding to critical signals.
 4. Other Building Blocks
• These building blocks—mutexes, timers, event
flags, message queues, resource management,
power management, and IPC—are essential
components of an RTOS that enable developers to
create responsive, efficient, and robust real-time
applications.
• Understanding and effectively utilizing these
components can significantly enhance the
performance and reliability of embedded systems.
 5. Component Configuration
• Component configuration is a crucial aspect of
real-time operating systems (RTOS) that
enables developers to tailor the system's
behavior to specific application requirements.
• It involves defining the characteristics and
interactions of various components, such as
tasks, semaphores, mutexes, and timers,
within the RTOS environment.
 Key Considerations for component
confirurations
• Task Configuration:
– Priority: Assigns a level of importance to tasks, determining their execution
order.
– Stack Size: Allocates memory for task-specific data and function calls.
– Entry Point: Specifies the function that the task will execute.

• Semaphore/Mutex Configuration:
– Type: Determines whether the semaphore is counting or binary.
– Initial Value: Sets the starting value for the semaphore.

• Timer Configuration:
– Mode: Specifies whether the timer is one-shot or periodic.
– Time Value: Sets the duration for the timer to elapse.
– Callback Function: Defines the function to be executed when the timer expires.
 Configuration Methods
• Configuration Files:
– Text-based files (e.g., .h, .c) that contain configuration parameters.
– Easy to read and modify, but can be prone to errors if not carefully
managed.
• Configuration Tools:
– Graphical interfaces or command-line tools that simplify the
configuration process.
– Provide visual representations and validation checks to reduce errors.
• Dynamic Configuration:
– Allows for runtime modifications of component parameters.
– Offers flexibility but can introduce complexity and potential
performance overhead.
 Best Practices
• Prioritize Task Priorities: Carefully consider the relative
importance of tasks to ensure optimal system performance.
• Allocate Adequate Stack Sizes: Avoid stack overflows by
providing sufficient memory for tasks.
• Use Semaphores and Mutexes Appropriately: Choose the
right synchronization mechanism based on the specific
requirements of your application.
• Test Thoroughly: Rigorously test your component
configurations to identify and address any issues.
• Consider Performance Implications: Be mindful of the
potential impact of configuration choices on system
performance.
 Examples
• FreeRTOS: Offers a configuration header file
(FreeRTOSConfig.h) that defines various RTOS
parameters.
• uC/OS: Provides a configuration tool (uC/OS-II
Configuration Wizard) for easy setup.
 6. Basic I/O Concepts: Key I/O Primitives
• Character I/O:
– Involves reading and writing individual characters to/from devices.
– Commonly used for serial communication, keyboard input, and display output.
• Block I/O:
– Transfers data in fixed-size blocks between the system and devices.
– Suitable for file systems, network communication, and bulk data transfers.
• Interrupt-Driven I/O:
– Utilizes interrupts to signal the completion of I/O operations.
– Enables efficient handling of multiple I/O requests without blocking the processor.
• Polling I/O:
– Continuously checks the status of I/O devices to determine if they are ready for
data transfer.
– Can be less efficient than interrupt-driven I/O, especially for high-speed devices.
Common I/O management mechanisms
• I/O Device Drivers: Software components that manage the interaction between
the RTOS and specific I/O devices.
– Provide a standardized interface for the RTOS to access device-specific
hardware.
– Typically handle device initialization, data transfer, error handling, and
interrupt processing.

• I/O Synchronization: Ensures that multiple tasks or processes can access I/O
devices without conflicts.
– Commonly achieved using semaphores, mutexes, or other synchronization
mechanisms.

• I/O Buffering: Temporarily stores data to improve I/O performance.

– Can be used to reduce the frequency of device access and to handle data
transfers of different sizes.
 Examples
• Serial Communication: Reading and writing
characters to/from a serial port.
• File System Access: Reading and writing data blocks
to/from a storage device.
• Network Communication: Sending and receiving
data packets over a network interface.
 7. I/O Subsystem
• The I/O subsystem is a critical component of
real-time operating systems (RTOS),
responsible for managing the communication
between the system and external devices.
• It provides a standardized interface for
developers to interact with various I/O
devices, such as serial ports, network
interfaces, storage devices, and sensors.
 Key Components
• Device Drivers:
– Software modules that interface between the RTOS and specific I/O devices.
– Provide a standardized API for the RTOS to access device-specific hardware.
– Typically handle device initialization, data transfer, error handling, and interrupt processing.
• I/O Primitives:
– Basic functions that the RTOS provides for I/O operations.
– Common primitives include:
• Character I/O (reading and writing individual characters)
• Block I/O (transferring data in fixed-size blocks)
• Interrupt-driven I/O (using interrupts to signal the completion of I/O operations)
• Polling I/O (continuously checking the status of I/O devices)
• I/O Buffering:
– Temporarily storing data to improve I/O performance.
– Can be used to reduce the frequency of device access and to handle data transfers of different sizes.
• I/O Synchronization:
– Ensuring that multiple tasks or processes can access I/O devices without conflicts.
– Commonly achieved using semaphores, mutexes, or other synchronization mechanisms.
• I/O Interrupt Handling:
– Efficiently managing interrupts generated by I/O devices.
– Involves saving the processor's state, executing the interrupt service routine (ISR), and restoring the processor's
state.
 Design Considerations
• Performance: The I/O subsystem should be
optimized for efficient data transfer and minimal
latency.
• Reliability: The subsystem should be robust and able
to handle errors and unexpected conditions.
• Flexibility: The subsystem should support a wide
range of I/O devices and configurations.
• Real-Time Constraints: The I/O subsystem must meet
the real-time requirements of the application,
ensuring timely response to I/O events.