This presentation talks about Real Time Operating Systems (RTOS). Starting with fundamental concepts of OS, this presentation deep dives into Embedded, Real Time and related aspects of an OS. Appropriate examples are referred with Linux as a case-study. Ideal for a beginner to build understanding about RTOS.
Real-time systems are those systems in which the correctness of the system depends not only on the logical result of computation, but also on the time at which the results are produced.
Embedded System,
Real Time Operating System Concept
Architecture of kernel
Task
Task States
Task scheduler
ISR
Semaphores
Mailbox
Message queues
Pipes
Events
Timers
Memory management
Introduction to Ucos II RTOS
Study of kernel structure of Ucos II
Synchronization in Ucos II
Inter-task communication in Ucos II
Memory management in Ucos II
Porting of RTOS.
RTOS-MicroC/OS-II
It is a priority-based real-time multitasking operating system kernel for microprocessors, written mainly in the C programming language.It is intended for use in embedded systems.
Introduction to Real-Time Operating Systemscoolmirza143
shared by Mansoor Mirza
Understanding Real-Time Operating Systems
Types of Real-Time Operating System
Requirements for Real-Time Operating System
Difference between General Purpose Operating System (GPOS) and Real-Time Operating System (RTOS)
Conversion Linux kernel to support Real-Time operations
Patching the linux kernel
Major changes in patched kernel
Hands-on labs
Conversion of Linux kernel to support real time
Code a real time application (Audio Feedback removal)
Real-time systems are those systems in which the correctness of the system depends not only on the logical result of computation, but also on the time at which the results are produced.
Embedded System,
Real Time Operating System Concept
Architecture of kernel
Task
Task States
Task scheduler
ISR
Semaphores
Mailbox
Message queues
Pipes
Events
Timers
Memory management
Introduction to Ucos II RTOS
Study of kernel structure of Ucos II
Synchronization in Ucos II
Inter-task communication in Ucos II
Memory management in Ucos II
Porting of RTOS.
RTOS-MicroC/OS-II
It is a priority-based real-time multitasking operating system kernel for microprocessors, written mainly in the C programming language.It is intended for use in embedded systems.
Introduction to Real-Time Operating Systemscoolmirza143
shared by Mansoor Mirza
Understanding Real-Time Operating Systems
Types of Real-Time Operating System
Requirements for Real-Time Operating System
Difference between General Purpose Operating System (GPOS) and Real-Time Operating System (RTOS)
Conversion Linux kernel to support Real-Time operations
Patching the linux kernel
Major changes in patched kernel
Hands-on labs
Conversion of Linux kernel to support real time
Code a real time application (Audio Feedback removal)
1. What is the value of requiring the OS to provide status informati.pdfudit652068
1. What is the value of requiring the OS to provide status information?
2. What is the difference between a true layered structure and the way that MS-DOS
used layering?
3. Why is an operating system thought to be a \"mandatory middleman\"?
§ be able to explain the services and value of this
4. What is a virtual machine and why is it necessary?
§ How does it work (i.e., be able to discuss and/or draw a VM structure in a
computer system)
5. Why is debugging a concern for an OS?
§ How can it be accomplished?
6. Why is a bootstrap loader needed?
Solution
Ans 1. In context switching among process before a process switched we have to store
PCB(Process control Block) by the Operating System.It consists of Process State,Program
Counter,Values of Registers,CPU Sheduling Information,Memeory Management
Information,Accounting Information and IO Status Information.
Value of Status Information is such as How much devices are allocated /occupied,Open File
Tables information etc.
Ans.2
In MS-DOS
Application Program -> Resident system Program->MS-DOS Device Drivers-
>ROM-BIOS Device Drivers
This architecture is applied. There is no well-structured architecture is defined. There is no
CPU Execution Mode (Kernel and User) So if there is error whole system is crashed.
In case of Layered approach it follows modular approach. OS is broken into the layer Bottom
Layer which is hardware and Top Layer is User. Its main advantage is simplicity of construction
and debugging. If error is found at any layer it remains same on that layer system does not crash.
Ans 3.
Operating system work as a middleman between a user and computer hardware.Its main
objective to make system convenient to use and utilitze computer hardware in efficient
manner.Variuos types of OS are there such as-INIX,MS-DOS,Windows-98/XP/Vista,Windows-
NT/2000,OS/2 and Mac OS.
It provides its service to user as well as Programs too:
To Program it provide environment to exceute .
To user provide platform to execute the program.
These are following services provided by OS:-
6.) Error Detection-
Ans 4:
Virtual Machine- It is based on computer architecture, it is an emulation of a computer system.It
also provides the functionality of physical computer Too.
It is of following type like:-
Advantage Of Virtual Machine:-
Architecture:-
Guest Operating System and Application
|
Virtual Machine
|
Virtual Server 2005
|
Windows Server 2003(Host OS)
|
Physical Computer
Ans.5
Debugging is a concern for an OS.As it made up of multi layered architecture so it is easier to
find at which layer error is prone .There is two mode for debugging User Mode and Kernal
Mode.Kernal mode debugging is very hard. Because we can not rely on crashing machine to
communicate that what happened.
There are four methods of debugging an operating system:-
Sanity Checks
Debugger
Deterministic Reply
Moving Everything to User Space
Ans 6.)Bootstrap Loader:- It is a program that is required to loads an operating system after
completion on power-on .
in this chapter we would be discussing about real time operating system used in embedded systems, concept of multi-tasking and multi-threading, kernel used in real time operating system, and about the concept of real time scheduling
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Search and Society: Reimagining Information Access for Radical FuturesBhaskar Mitra
The field of Information retrieval (IR) is currently undergoing a transformative shift, at least partly due to the emerging applications of generative AI to information access. In this talk, we will deliberate on the sociotechnical implications of generative AI for information access. We will argue that there is both a critical necessity and an exciting opportunity for the IR community to re-center our research agendas on societal needs while dismantling the artificial separation between the work on fairness, accountability, transparency, and ethics in IR and the rest of IR research. Instead of adopting a reactionary strategy of trying to mitigate potential social harms from emerging technologies, the community should aim to proactively set the research agenda for the kinds of systems we should build inspired by diverse explicitly stated sociotechnical imaginaries. The sociotechnical imaginaries that underpin the design and development of information access technologies needs to be explicitly articulated, and we need to develop theories of change in context of these diverse perspectives. Our guiding future imaginaries must be informed by other academic fields, such as democratic theory and critical theory, and should be co-developed with social science scholars, legal scholars, civil rights and social justice activists, and artists, among others.
4. Let us ponder…
•
What exactly is an Operating System (OS)?
•
Why do we need OS?
•
How would the OS would look like?
•
Is it possible for a team of us (in the room) to create an OS of our own?
•
Is it necessary to have an OS running in a Embedded System?
•
Will the OS ever stop at all?
5. Types of OS
OS can be of two types as follows:
General Purpose Operating Systems (GPOS)
Real Time Operating Systems (RTOS)
Where and all the OS can run?
•
•
•
PC
Server
Embedded device
OS characteristics:
OS type
Size
User Interface
Security
Reliability
Cost
PC
Server
Embedded
7. OS – In action
CPU loads boot program from ROM (e.g. BIOS in PC’s)
Boot program:
Examines/checks machine configuration (number of CPU’s, how much
memory, number & type of hardware devices, etc.)
Builds a configuration structure describing the hardware
Loads the operating system, and gives it the configuration structure
8. OS – In action
After basic processes have started:
The OS runs user programs, if available
Otherwise enters the idle loop
In the idle loop:
OS executes an infinite loop (UNIX)
OS wakes up on:
Interrupts from hardware devices
Exceptions from user programs
System calls from user programs
Two modes of execution:
User mode: Less privilèges
OS performs some system management
& profiling
OS halts the processor and enter in
low-power mode (notebooks)
Supervisor mode: Unrestricted
access to everything (OS)
10. Control flow - Interrupts
Hardware calls the OS at a pre-specified location
OS saves state of the user program
OS identifies the device and cause of interrupt
Responds to the interrupt
OS restores state of the user program
Execute an RTI instruction to return to the user program
User program continues exactly at the same point it was interrupted.
Key Fact: None of this is visible to the user program
11. Control flow - Exceptions
Hardware calls the OS at a pre-specified location
OS identifies the cause of the exception (divide by 0)
If user program has exception handling specified, then OS adjust the user
program state so that it calls its handler
Execute an RTI instruction to return to the user program
If user program did not have a specified handler, then OS kills it and runs
some other user program, as available
Key Fact: Effects of exceptions are visible to user programs and cause
abnormal execution flow
12. Control flow – System calls
Hardware calls the OS at a pre-specified location
User program executes a trap instruction (system call)
Hardware calls the OS at a pre-specified location
OS identifies the required service and parameters (e.g. open(filename,
O_RDONLY))
OS executes the required service
OS sets a register to contain the result of call
Execute an RTI instruction to return to the user program
User program receives the result and continues
Key Fact: To the user program, it appears as a function call executed under program
control
13. Summary
An OS is just a program:
It has a main() function, which gets called only once (during boot)
Like any program, it consumes resources (such as memory), can do silly
things (like generating an exception), etc.
But it is a very strange program:
It is “entered” from different locations in response to external events
It does not have a single thread of control, it can be invoked
simultaneously by two different events (e.g. system call & an interrupt)
It is not supposed to terminate
It can execute any instruction in the machine
15. What is a system call?
A set of interfaces to interact with hardware devices such as the CPU, disks,
and printers.
Advantages:
Freeing users from studying low-level programming
It greatly increases system security
These interfaces make programs more portable
16. System call - Usage
A set of interfaces to interact with
hardware devices such as the CPU,
disks, and printers.
Advantages:
Freeing users from studying low-level
programming
It greatly increases system security
These interfaces make programs more
portable
For a OS programmer, calling a system call is no different from a normal function
call. But the way system call is executed is way different.
17. Calling sequence
Logically the system call and regular interrupt follow the same flow of steps. The
source (I/O device v/s user program) is very different for both of them. Since
system call is generated by user program they are called as ‘Soft interrupts’ or
‘traps’
19. What is a task?
What is a Task?
A task is an individual execution unit of an application.
A task:
Starts with some parameters or inputs.
It does a specific job assigned to it.
It either runs forever in a loop or terminates.
It communicates results to other tasks of the application.
Types of Tasks:
Pre-emptive
Non-Pre-emptive
Round Robin
20. Application to tasks
Any application can be split into a number of tasks based only on parallel
operations possible for the application:
For example, a car can have different tasks for controls such as for the
following:
• Driving Gears
• Windows
• Temperature
• Door-lock/Theft-lock-alarm
• Brakes/Accelarator
• Air-Bag, Accident/Emergency
• Ignition, Fuel Tank/Brake Oil
These parts can run independently. However, at times they will need to
communicate with each other. Alternatively, there can be a “master” task
supervising these tasks which it creates, manages and destroys.
21. What is a task?
What is a Task?
A task is an individual execution unit of an application.
A task:
Starts with some parameters or inputs.
It does a specific job assigned to it.
It either runs forever in a loop or terminates.
It communicates results to other tasks of the application.
Types of Tasks:
Pre-emptive
Non-Pre-emptive
Round Robin
22. Task v/s Program
A Task is a running Instance, whereas
a Program is just the code which
resides in primary or secondary
memory.
A program is a passive entity, such as
file containing a list of instructions
stored on a disk, whereas a task is a
active entity, with a program counter
specifying the next instruction to
execute and a set of associated
resources.
A program gives rise to one or more
active tasks when an executable file is
loaded into main memory and
execution of the tasks begin
23. Task states
A task goes through multiple states
ever since it is created by the OS
new: The task is being created.
running: Instructions are being
executed.
waiting: The task is waiting for some
event to occur.
ready: The task is waiting to be
assigned to a processor.
terminated: The task has finished
execution
24. Task descriptor
To manage tasks:
• OS kernel must have a clear picture of what each task is doing.
• Task's priority
• whether it is running on the CPU or blocked on some event
• what address space has been assigned to it
• which files it is allowed to address, and so on.
This is the role of the task descriptor
Usually the OS maintains a structure whose fields contain all the information
related to a single task
25. Task descriptor - Fields
Information associated with each
task:
• Task state
• Program counter
• CPU registers
• CPU scheduling information
• Memory-management information
• I/O status information
26. Context switching
Switching the CPU to another task
requires saving the state of the old
task and loading the saved state for
the new task.
The time wasted to switch from one
task to another without any
disturbance is called context switch
or scheduling jitter.
28. Why Synchronization?
When multiple tasks are running simultaneously:
either on a single processor, or on
a set of multiple processors
They give an appearance that:
For each task, it is the only task in the system.
At a higher level, all these tasks are executing efficiently.
Tasks sometimes exchange information:
They are sometimes blocked for input or output (I/O).
This asynchronous nature of scheduled tasks gives rise to race conditions
29. Race condition
The ultimate cause of most bugs involving multiple-tasks is that the
tasks are accessing the same (shared) data.
If one task is only partway through updating a data structure when
another task accesses the same data structure, it’s a problem.
These bugs are called race conditions; the tasks are racing one
another to change the same data structure.
Debugging a muti-tasking application is difficult because you cannot
always easily reproduce the behavior that caused the problem.
You might run the program once and have everything work fine; the
next time you run it, it might crash.
There’s no way to make the system schedule the tasks exactly the
same way it did before.
30. Critical section
A piece of code that only one task can execute at a time.
If multiple tasks try to enter a critical section, only one can run and
the others will sleep.
31. Critical section
Only one task can enter the critical section; the other two have to
sleep.
When a task sleeps, its execution is paused and the OS will run some
other task.
32. Critical section
Once the thread in the critical section exits, another thread is
woken up and allowed to enter the critical section.
It is important to keep the code inside a critical section as small as
possible
33. Mutual Exclusion
A mutex works like a critical section.
You can think of a mutex as a token that must be grabbed before
execution can continue.
34. Mutual Exclusion
During the time that a task holds the mutex, all other tasks waiting
on the mutex sleep.
35. Mutual Exclusion
Once a task has finished using the shared resource, it releases the
mutex. Another task can then wake up and grab the mutex.
36. Locking & Blocking
A task may attempt to lock a mutex by calling a lock method on it.
If the mutex was unlocked, it becomes locked and the function
returns immediately.
If the mutex was locked by another task, the locking function blocks
execution and returns only eventually when the mutex is unlocked
by the other task.
More than one task may be blocked on a locked mutex at one time.
When the mutex is unlocked, only one of the blocked tasks is
unblocked and allowed to lock the mutex; the other tasks stay
blocked.
37. Deadlocks
Mutexes provide a mechanism for allowing one task to block the
execution of another.
This opens up the possibility of a new class of bugs, called
deadlocks.
A deadlock occurs when one or more tasks are stuck waiting for
something that never will occur.
38. Semaphores
A semaphore is a counter that can be used to synchronize multiple
tasks.
As with a mutex, OS guarantees that checking or modifying the value
of a semaphore can be done safely, without creating a race
condition.
Each semaphore has a counter value, which is a non-negative
integer.
39. Semaphore - Operations
A wait operation
decrements the value of the semaphore by 1.
If the value is already zero, the operation blocks until the value of
the semaphore becomes positive (due to the action of some other
task).
When the semaphore’s value becomes positive, it is decremented by
1 and the wait operation returns.
A post operation
increments the value of the semaphore by 1.
If the semaphore was previously zero and other tasks are blocked in
a wait operation on that semaphore, only one of those tasks is
unblocked and its wait operation completes (which brings the
semaphore’s value back to zero).
41. Why ITC?
ITC allows tasks to communicate and synchronize their actions without
sharing the same address space
•
•
•
•
Data Transfer
Sharing Data
Event notification
Resource Sharing and Synchronization
ITC
Synchronization
Communication
(Ex: Semaphore,
Mutex)
(Ex: Message queue,
shared memory)
In Synchronization, there is always a resource in contention which needs to
be handled properly failing which will result in a race condition or
deadlock
In communication, it is about message or information exchange between
two tasks offering various types depending on the need
42. ITC mechanisms
Mechanisms used for communication:
•
•
•
•
•
•
Message Passing:
Mailboxes
Message Queues
Sockets
Pipes
Shared Memory
Synchronization:
•
•
•
•
Mutex
Semaphore
Monitors
Event Notification/Signals
Let us focus on some of these mechanisms and build better understanding
43. Message passing
In a Message system there are no shared variables.
Two operations for fixed or variable sized message:
•
•
send(message)
receive(message)
If tasks P and Q wish to communicate, they need to establish a
communication link exchange messages via send and receive
Implementation of communication link
•
•
physical (e.g., memory, network etc.)
logical (e.g., syntax and semantics, abstractions)
44. Message passing
Message queues pass message in
both directions thereby making it
as a ‘bi-directional’ mechanism of
communication
In a multi-processor or multitasking system this comes handy
for ITC
Before tasks starts communicating,
they need to create appropriate
queues to establish the connection
Can be related with protocol
request-response mechanism
45. Pipes
A pipe is a communication device that permits unidirectional
communication.
Data written to the “write end” of the pipe is read back from the
“read end.”
Pipes are serial devices; the data is always read from the pipe in
the same order it was written.
A pipe’s data capacity is limited. If the writer task writes faster
than the reader task consumes the data, and if the pipe cannot
store more data, the writer task blocks until more capacity
becomes available.
If the reader tries to read but no data is available, it blocks until
data becomes available. Thus, the pipe automatically synchronizes
the two tasks.
46. Pipes
Pipes are used in implementation
where output of one process to be
input of another, not vice-versa
Some of the popular Linux utilities
implement pipes for command
handling
Several powerful functions can be
in a single statement using Pipes
Streams of processes can be
redirected to user specified
locations using Pipes
47. Shared memory
Shared memory allows two or more tasks to access the same
memory.
When one task changes the memory, all the other tasks see the
modification.
Shared memory is the fastest form of Inter-Task communication
because all tasks share the same piece of memory.
It also avoids copying data unnecessarily.
48. Shared memory
To use a shared memory segment,
one task must allocate the
segment.
Then each task desiring to access
the segment must attach the
segment.
A task can make use of the shared
memory using the attached location
(pointer). It must use the memory
in conjunction with synchronization
methods using mutex and
semaphore.
After finishing its use of the
segment, each task detaches the
segment.
At some point, one task must
deallocate the segment.
50. Quick re-cap….
Operating system is a program that runs on a super loop
OS has come critical components – Scheduler, Task, Memory,
System call interface, File systems etc…
All of these components are very much part of Embedded and
Real-time systems
However some of the parameters need to be tuned/changed in
order to meet the needs of these systems
Fundamentals remain same, only specifics change
Real time & Embedded systems – Coupling v/s De-coupling
Engineers need to understand these differences in order to be
effective during the product development
51. Real Time systems
Characteristics:
•
•
•
•
Capable of guaranteeing timing requirements of the processes under its
control
Fast – low latency
Predictable – able to determine task’s completion time with certainty
Both time-critical and non time-critical tasks to coexist
Types:
•
Hard real time system
•
•
•
•
Guarantees that real-time tasks be completed within their required deadlines.
Requires formal verification/guarantees of being to always meet its hard deadlines
(except for fatal errors).
Examples: air traffic control , vehicle subsystems control, medical systems.
Soft real time system
•
•
Provides priority of real-time tasks over non real-time tasks.
Also known as “best effort” systems. Example – multimedia streaming, computer
games
52. Classification
The type of system can be either a:
•
•
•
Uni-processor,
Micro processor
Distributed System.
There are two different execution models:
•
In a preemptive model of execution a task may be interrupted (preempted)
during its execution and another task run in its place.
•
In a non-preemptive model of execution after a task that starts executing no
other task may execute until this task concludes or yields the CPU.
53. Characteristics
RTOS for Embedded systems are:
Single purpose
Small size
Inexpensively mass-produced
Specific timing requirements
Features missing in an RTOS:
•
Support for variety of peripheral devices.
•
Protection and Security mechanisms
•
Multiple Users
•
Multiple Modes
•
Dynamic Allocation of memory
54. Why so?
Real-time systems are typically single-purpose.
Real-time systems often do not require interfacing with a user.
Features found in a desktop PC require more substantial hardware
than what is typically available in a real-time system.
High overhead required for protected memory and for switching
modes.
Memory paging increases context switch time.
Creates fragmentation adding to timing unpredictability.
55. Scheduling in RTOS
Handling Priority & Scheduling
Scheduling algorithms
Meeting deadlines
Avoiding conflicts like deadlocks
Real-Time Systems Development
56. Event latency
The Event latency is nothing but
the “amount of time from when
and event occurs to when it is
serviced”
In a Real-Time system, this
latency should always be within
a particular limit
This is known as responding in
“real-time”
Scheduler part of the OS to be
configured to respond in this
manner
57. Real Time CPU scheduling
Periodic processes require the CPU at specified intervals (periods)
•
•
•
p is the duration of the period
d is the deadline by when the process must be serviced
t is the processing time
By ensuring CPU responds within given time interval, real-time
response can be guaranteed
58. Real Time CPU scheduling
Periodic processes require the
CPU at specified intervals
(periods)
•
•
•
p is the duration of the period
d is the deadline by when the
process must be serviced
t is the processing time
By ensuring CPU responds within
given time interval, real-time
response can be guaranteed
•
•
Priority based scheduling
Earliest deadline first scheduling
59. RTOS - Issues
Interrupt Latency should be very small
•
•
Kernel has to respond to real time events
Interrupts should be disabled for minimum possible time
For embedded applications Kernel Size should be small
•
Should fit in ROM
Sophisticated features can be removed
•
•
No Virtual Memory
No Protection