The document discusses some of the key challenges faced when using a real-time operating system (RTOS) for embedded applications. It outlines five main challenges: 1) deciding when to use an RTOS; 2) setting appropriate task priorities; 3) debugging complex RTOS-based systems; 4) managing memory across the operating system and application layers; and 5) overcoming the steep learning curve required to design RTOS-based applications. Addressing these challenges requires skills such as priority-based scheduling, tracing tools, memory optimization, and hands-on practice to effectively develop with an RTOS.

1. Subject: REAL TIME OPERATING SYSTEM
UNIT-I )INTRODUCTION TO OS, PROCESS MANAGEMENT
& INTER PROCESS COMMUNICATION.
MEMORY MANAGEMENT, I/O SUBSYSTEM, FILE SYSTEM
ORGANIZATION.
Er. SATEESH KOURAV

2. 1 OPERATING SYSTEM
DEFINITION-An operating system is a program that acts as an interface between the
user and the computer hardware and controls the execution of all kinds of programs.
Functions Of Operating System- important functions of an operating System.
1 Memory Management
2 Processor Management
3 Device Management
4 File Management
5 Security
6Control over system performance
7 Job accounting
8 Error detecting aids
9 Coordination between other software and users

3. 1Memory Management-Memory management refers to management of Primary Memory or
Main Memory. Main memory is a large array of words or bytes where each word or byte has its own
address.
Main memory provides a fast storage that can be accessed directly by the CPU.
2 - Processor Management
In multiprogramming environment, the OS decides which process gets the processor when and
for how much time. This function is called process scheduling. An Operating System does the
following activities for processor management −
Keeps tracks of processor and status of process. The program responsible for this task is known as traffic
controller.
Allocates the processor (CPU) to a process.
De-allocates processor when a process is no longer required.
3-Device Management
An Operating System manages device communication via their respective drivers. It does the
following activities for device management −
Keeps tracks of all devices. Program responsible for this task is known as the I/O controller.
Decides which process gets the device when and for how much time.
Allocates the device in the efficient way.
De-allocates devices.
4 -File Management
A file system is normally organized into directories for easy navigation and usage. These
directories may contain files and other directions.
5Security − By means of password and similar other techniques, it prevents
unauthorized access to programs and data.
6- Control over system performance − Recording delays between
request for a service and response from the system.
7 Job accounting − Keeping track of time and resources used by various jobs and
users.
8Error detecting aids − Production of dumps, traces, error messages, and
other debugging and error detecting aids.

4. 9-Coordination between other softwares and users − Coordination and
assignment of compilers, interpreters, assemblers and other software to the various users of the
Process managemen-Process is the execution of a program
that performs the actions specified in that program. It can be
defined as an execution unit where a program runs. The OS helps
you to create, schedule, and terminates the processes which is
used by CPU. A process created by the main process is called a
child process.
Process operations can be easily controlled with the help of PCB(Process
Control Block). You can consider it as the brain of the process, which
contains all the crucial information related to processing like process id,
priority, state, CPU registers, etc.
Process Architecture

5. Process architecture Image
Here, is an Architecture diagram of the Process
 Stack: The Stack stores temporary data like function parameters, returns addresses, and local variables.
 Heap Allocates memory, which may be processed during its run time.
 Data: It contains the variable.
 Text: Text Section includes the current activity, which is represented by the value of the Program Counter.
(3)INTER PROCESS COMMUNICATION (IPC)- inter process communication is a
mechanism which allows processes to communicate each other and synchronize
their actions. the communication between these processes can be seen as a
method of co-operation between them. processes can communicate with each
other using these two
Inter process communication (IPC) is a mechanism which allows
processes to communicate each other and synchronize their actions. The
communication between these processes can be seen as a method of co-
operation between them. Processes can communicate with each other using
these two ways:
1 Shared Memory 2 Message passing
1) Shared Memory Method -There are two processes: Producer and Consumer.
Producer produces some item and Consumer consumes that item. The two processes
shares a common space or memory location known as buffer where the item produced
by Producer is stored and from where the Consumer consumes the item if needed.
There are two version of this problem: first one is known as unbounded buffer problem
in which Producer can keep on producing items and there is no limit on size of buffer,
the second one is known as bounded buffer problem in which producer can produce up
to a certain amount of item and after that it starts waiting for consumer to consume it.
We will discuss the bounded buffer problem. First, the Producer and the Consumer will
share some common memory, then producer will start producing items. If the total
produced item is equal to the size of buffer, producer will wait to get it consumed by the
Consumer.

6. ii) Messaging Passing Method -start our discussion for the
communication between processes via message passing. In this method,
processes communicate with each other without using any kind of shared
memory. If two processes p1 and p2 want to communicate with each other,
they proceed as follow:

 Establish a communication link (if a link already exists, no need to
establish it again.)
Start exchanging messages using basic primitives.
We need at least two primitives:
– send(message, destinaion) or send(message)
– receive(message, host) or receive(message)
The message size can be of fixed size or of variable size. if it is of fixed size, it is easy
for OS designer but complicated for programmer and if it is of variable size then it is
easy for programmer but complicated for the OS designer. A standard message can
have two parts: header and body.
The header part is used for storing Message type, destination id, source id, message
length and control information. The control information contains information like what to
do if runs out of buffer space, sequence number, priority. Generally, message is sent

7. using FIFO style.

8. INTER PROCESS COMMUNICATION ADVANTAGES AND
DISADVANTAGES

9. MEMORY MANAGEMENT:- Memory management is the process of controlling
and coordinating computer memory, assigning portions called blocks to various running
programs to optimize overall system performance. Memory management resides in
hardware, in the OS (operating system), and in programs and applications.

10. RTOS trends and challenges:- Real-time Operating
Systems (RTOS) are becoming a necessary component that most embedded
software developers need to use in their applications. Developers who were once
traditional bare-metal developers are starting to transition to using an RTOS as their
microcontrollers move to 32-bit architectures and as their devices are starting to
connect to the Internet. Whether you are just starting to use an RTOS or have been
for years, there are several challenges that developers face when using an RTOS.
1 – DECIDING WHEN TO USE AN RTOS:- The first and foremost challenge
that bare-metal developers face is deciding when to use an RTOS. The fact is,
there is a lot that can be done by developers to emulate preemptive scheduling
before needing to make the switch. So, what are a few key indicators that an
RTOS is the right way to go? Below are several questions a developer should
consider:
1 Does the application include a connectivity stack such as USB, WiFi, TCP/IP, etc.?
2 Will the systems time management be simplified by using an RTOS?
3Will application management and maintenance be improved if an RTOS is used?
3 Is deterministic behavior needed?
4 Do program tasks need the ability to preempt each other?
5 Does the MCU have at least 32 kB of code space and 4 kB of RAM?
2– SETTING TASK PRIORITIES-Selecting task priorities can be a challenge. Which task
should have the highest priority? The next highest? Can the tasks even be scheduled? These are
the questions that often come into the minds of developers working with an RTOS. I’ve seen
quite a few developers who simply appear to randomly assign priorities based on how
important they feel the task is. Selecting priorities in this manner is a recipe for disaster.
Developers should start by using rate monotonic scheduling to get a general feel for whether
their periodic tasks can be scheduled successfully. RMS assumes that tasks are periodic and
don’t interact with each other so it only serves as a starting point but can get developers 80% of
the way to the finish line. After that, developers can use trace tools to observe how their system
behaves and make fine tuned adjustments.
3DEBUGGING-Debugging an embedded system is a major challenge. Developers can
spend anywhere from 20% - 80% of their development cycle debugging their
application code with averages typically being around 40%. That is a lot of time
spent debugging. Using an RTOS can complicate debugging. RTOSes can introduce
problems such as priority inversion, dead-lock, and task jitter to name just a few.
Developers who are new to using an RTOS probably don’t realize there are

11. entirely new debugging techniques such as tracing that can be used to debug
their system. These tools can record when tasks start and end execution and
when events occur such as data being placed in a message queue or a mutex
being locked. Tracing tools can even be used to verify that the application is
executing as expected. Needless to say, debugging is a big issue that every
development team is facing and needs to tackle.
4– MANAGING MEMORY-An important challenge for developers is managing memory.
There are several layers to memory management when using an RTOS. First,
developers may need to configure their RTOS to minimize code size if they are
using a resource constrained device. Usually RTOS optimization will require
adjusting the RTOS configuration file to disable features that use a lot of code
space or RAM. Second, developers need to properly manage their RTOS objects
and how they allocate memory in their system. Using the heap and byte pools can
result in non-deterministic behavior along with memory fragmentation. Using the
RTOS default stack size can result in using too much RAM, or worse, a stack
overflow. These issues can be solved by performing a worst case stack analysis
and by using block memory pools, but that doesn’t make the issues trivial.
5– THE LEARNING CURVE-Developers who are switching from bare-metal coding
techniques into an RTOS environment often struggle with learning about RTOSes.
There are a lot of great materials on the web and in books that give ideas about
the major RTOS objects and how to use them, but having a theoretical knowledge
of an RTOS application is one thing. Designing and implementing a real application
and fighting through all the nuances and issues is another. Developers making the
transition should pick up their favorite development kit, a port of the RTOS they
are interested in, and then start designing something simple in order to stretch
their legs and shrink the learning curve.
Conclusion-Whether you are new to using an RTOS or are a seasoned veteran, as
developers we face very similar challenges when designing and implementing our
RTOS-based applications. As system complexity increases, the need to be an
expert at using an RTOS is going to be a requirement for every embedded
software engineer.