Your SlideShare is downloading. ×
0
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Rtos ss
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rtos ss

985

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
985
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
97
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. REAL TIME OPERATING SYSTEM Sudheesh S Madhav
  • 2. What is Real Time ? • “ Real time in operating systems: The ability of the operating system to provide a required level of service in a bounded response time.”
  • 3. WHAT IS RTOS. • It responds to inputs immediately(Real-Time). • Here the task is completed within a specified time delay. • In real life situations like controlling traffic signal or a nuclear reactor or an aircraft. • The operating system has to respond quickly. • Necessary signaling between interrupt routines and task code is handled by RTOS. • RTOS can suspend one task code subroutine in the middle of its processing in order to run another.
  • 4. What a RTOS is • Real time computing is equivalent to fast computing. • Real time systems operate in a static environment • Real time programming involves assembly coding, priority interrupt programming, writing device drivers.
  • 5. SELECTING AN ARCHITECTURE • Select the simplest architecture that will meet your response requirements. • If response requirements not possible, RTOS can be used.
  • 6. INTRODUCTION TO RTOS – A more complex software architecture is needed to handle multiple tasks, coordination, communication, and interrupt handling – an RTOS architecture – Distinction: • RTOS – OS and embedded software are integrated, ES starts and activates the OS – both run in the same address space • RTOS includes only service routines needed by the ES application • Desirable RTOS properties: use less memory, application programming interface, debugging tools, support for variety of microprocessors, already- debugged network drivers
  • 7. CHARACTERISTICS OF RTOS. Reliability Predictability Performance Scalability Consistency
  • 8. FUNCTIONS OF RTOS • Task management • Scheduling • Resource Allocation • Interrupt Handling
  • 9. Task management • In Real Time Applications the Process is called as Task which takes execution time and occupies memory. • Task management is the process of managing tasks through its life cycle.
  • 10. TASK STATES
  • 11. TASK 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 (Executing task) – Ready (possibly: waiting, dormant, delayed) – Blocked (possibly: suspended, pended)
  • 12. Task States Suspended Pended Ready Delayed Run
  • 13. Task/Process States • Each task/Process can belong to one and only one state • The Scheduler only operates on the processes in the Ready state • There is a single process in the Run/current state at any time. • Transitions to and from the Ready queue are affected as a part of the execution of the RTOS resource/object services or as a result of timing events
  • 14. Typical Task Operations • creating and deleting tasks, • controlling task scheduling, and • obtaining task information.
  • 15. SCHEDULER – Scheduler – keeps track of the state of each task and decides which one task should go to running state. – 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)
  • 16. EXAMPLE PROGRAM
  • 17. Preemptive and Non preemptive RTOS Preemptive RTOS Stops low priority task as soon as high priority task unblocked Non preemptive RTOS Takes microprocessor away from the lower priority task when that task blocks
  • 18. 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
  • 19. 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
  • 20. RTOS Semaphores & Initializing Semaphores – Using binary semaphores to solve the „tank monitoring‟ problem – 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()
  • 21. Semaphores and Shared Data – Reentrancy, Semaphores, Multiple Semaphores, Device Signaling – 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 – 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
  • 22. 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
  • 23. Semaphores and Shared Data – 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

×