CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.
-
Upload
lauren-tate -
Category
Documents
-
view
218 -
download
2
Transcript of CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.
![Page 1: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/1.jpg)
CSCI1600: Embedded and Real Time SoftwareLecture 27: Real Time Linux
Steven Reiss, Fall 2015
![Page 2: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/2.jpg)
Conventional Operating Systems Memory model
Independent address spaces
Allocation and deallocation
Stack management
Device support Abstraction based on descriptors
Clock and other basic devices built in
High-level I/O support (e.g. networking)
Thread / process model (with scheduling)
IPC support (pipes, sockets, shared memory) Synchronization primitives
![Page 3: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/3.jpg)
Conventional OS Problems Size (for embedded)
Micro-kernel based architectures help here
Unpredictable (and poor) latency
Slow interrupt handlers
Unpreemptible kernel code
Latency might be built into hardware
System management interrupts on x86
DMA bus mastering; USB handling; VGA console; Page faults
Unpredictable Scheduling
Desktop/server heuristics
Scheduling overhead grows with workload
Poor support for precise timing
Timing accuracy related to tick overhead
![Page 4: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/4.jpg)
Are the Problems Fixable?
Want to retain the bulk of prior work Hundreds of device drivers
Many abstractions make programming easier
TCP/IP, File systems, IPC, Memory
How can we do this?
Two approaches to this are used Fixing the problems
Sidestepping the problems
![Page 5: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/5.jpg)
RT-Linux
Assume most of the program is non-real time There is a small hard (soft) real-time component
Attempt to side step the problem Run the OS as a real time task
Allow other RT tasks (outside the OS)
Provide the benefits of an OS and still have a real time environment Except that Linux tasks are now sporadic
![Page 6: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/6.jpg)
Linux on a RTOS We’ve seen this before
Scheduling sporadic tasks
Bandwidth servers (Total and Constant)
Group all the sporadic tasks together
Provide a real-time task (with fixed bandwidth)
This executes the various sporadic tasks
Using their priorities
This is basically RT-Linux Linux is “ported” to use RTOS primitives instead of hardware
Like running on a virtual machine
![Page 7: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/7.jpg)
RT Linux
![Page 8: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/8.jpg)
RT-Linux Details RTLinux core
Non-preemptible
Hard real time scheduler
Basic OS functionality
Deterministic interrupt-latency ISRs run in core
Others are transferred to Linux via a FIFO
Primitive tasks
Only statically allocated memory, no virtual memory, fixed priority
Run as real time threads
![Page 9: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/9.jpg)
RT-Linux Details
Real time tasks No address space protection
Run with disabled interrupts
FIFO (message queue) Connects real time tasks with LINUX
Shared memory synchronization
Non-real time tasks Run as Linux processes
![Page 10: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/10.jpg)
RT-Linux Pros and Cons Pros
Hard real-time guarantees (low tens of microseconds)
OS code is virtually unchanged
Applies equally well to other OS’s
Supports BSD as well as Linux
Cons
Real time task lose the convenience of a mature well-understood API
Communication with Linux processes is ad-hoc
Message queues – but user needs to define the messages
![Page 11: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/11.jpg)
Fixing the Problems
Problems to tackle Scheduling, latency, timing
Techniques Priority scheduling and priority inheritance
Limit un-preemptible code
Offer high-resolution timers
![Page 12: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/12.jpg)
Scheduling Real time schedulers are actually simpler
Support for fixed (absolute) priority
Ability to bind tasks to specific processors (cores)
Create new classes of processes (RR, FIFO) Round robin runs for a fixed time slice
FIFO is never guaranteed
Enhance mutexes to support priority (PIP,PCP)
Problem: scheduling latency Support fixed priorities
But scheduling decisions might be deferred
Interrupt handlers cannot be preempted
Spin-locked code can not be preempted
![Page 13: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/13.jpg)
Minimizing Latency Simple Solution:
Threaded interrupt handling
Move interrupt handlers into kernel threads; true ISR is now very short
Handling can be preempted
Preemptible spin locks
Turn spin locks into mutexes
This almost works Timer interrupts need to be handled directly
Individual handlers are still atomic
Spinlocks not always equivalent to mutexes
Programming devices, modifying page tables, in the scheduler
Read-copy-update synchronization in Linux make non-preemption assumptions
New type: raw_spinlock_t
![Page 14: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/14.jpg)
Other Improvements Dynamic tick
Ask for timer IRQ as needed, not periodically
High resolution timers
O(1) scheduler
Robust mutexes
O(1) kernel memory allocation
Ability to lock pages into memory (avoid page faults)
Most problems can be minimized But retrofitting them to an OS make hard real time unlikely
![Page 15: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/15.jpg)
Solaris Attempt to fix the problems
Starting with the initial OS design
Not retrofitted
Features of Solaris for real time Interrupts are handled by threads
Kernel is fully preemptible and multithreaded
Real time scheduling is supported
Deterministic with real time priorities
Fixed priority scheduling supported
![Page 16: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/16.jpg)
Solaris Real Time Threads Separate classes of threads
Fixed-priority (non-varying)
But lower priority than Operating System
Real-Time (fixed priority with fixed quantum)
Higher priority than operating system
Real time threadss Lock their pages in memory
Can call OS (but then run at lower priority)
![Page 17: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/17.jpg)
Solaris Features Priority inheriting synchronization primitives
Processor sets The ability to isolate one or more CPUs for scheduling
Ability to lock tasks to a particular core
Full support for the Posix real time standard Real time threads
High-precision timers and clocks
Fast TCP/IP (zero copy)
Memory locking
Early binding of shared libraries
![Page 18: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/18.jpg)
Solaris
Has been used as a hard real time environment
But not as an embedded environment Too large
![Page 19: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/19.jpg)
Embedded Linux
Linux is a common tool for embedded systems Linux itself is relatively small
Linux is fairly modular
It can run in 1M (or less) of memory
![Page 20: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/20.jpg)
Requirements on RT/Embedded
Safety Requirements The car won’t crash
Trains won’t crash
Both traffic lights won’t be green at the same time
You won’t blow a fuse
The system won’t deadlock
The heat and air conditioning won’t be on at the same time
![Page 21: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/21.jpg)
More Requirements: Timing Forms
X will occur within k ms of event Y
X will occur every 10 +/- 1 ms
Examples The solenoid will trigger within 10 ms of the bumper being
hit
The switches will be sensed every 20 ms
The heat will come on within 5 minutes of detecting the room is too cool
![Page 22: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/22.jpg)
More Requirements: Fairness Forms
Eventually X will occur
If X occurs, then eventually Y will occur
X will occur infinitely often
As long as Y is true, X will occur infinitely often
Examples Eventually you will add K to the score when you hit Y
As long as the heating system is on, the room will eventually be comfortable
![Page 23: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/23.jpg)
Requirements
Are often mandatory (hard)
Failure is not a viable option Car or plan crashes
Broken devices
Heart stops pumping
Water is supplied unfiltered
The nuclear plant does not shut down
This is what hard real time means
![Page 24: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/24.jpg)
What Are Your Requirements?
![Page 25: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/25.jpg)
Problems
How do you show the system is safe
How do you get confidence in the system’s safety
When can you reasonably deploy the system
Can the system be used in a medical device
Can peoples lives depend on the system
![Page 26: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/26.jpg)
Exercise
Suppose you wanted to sell your tic-tac-toe box What would you want as requirements
How would you check these?
Take the ankle-mounted obstacle finder example What would be the requirements
How would you check these?
![Page 27: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/27.jpg)
Helpful Techniques: SE Good requirements analysis
Understanding all the possible problems and solutions
Good specifications Accurate modeling
Showing the models are correct
Petri net and FSA validation
Design for security Defensive coding
Building monitors as part of the code
Enter a safe state if the monitor detects anything wrong
Enter a safe state if the monitor detects anything unusual
Checking tools: lint, compiler, modeling analysis
![Page 28: CSCI1600: Embedded and Real Time Software Lecture 27: Real Time Linux Steven Reiss, Fall 2015.](https://reader035.fdocuments.in/reader035/viewer/2022062423/5697bfc11a28abf838ca4353/html5/thumbnails/28.jpg)
Homework
Read chapter 13