1. CSCI1600: Embedded and Real Time Software Lecture 26: Real Time Operating Systems Steven Reiss, Fall 2015

2. What is a RTOS  It’s an operating system  Similar to UNIX, Windows, Linux, Mac OS, Solaris  Provides all the low level services one expects  So they don’t have to be rewritten for each application  Shares the CPU and other hardware resources  Except it’s different in some ways

3. RTOS Differences  More control over scheduling  Real time tasks  Real priorities (not hints)  Simpler scheduling techniques  Easier to reason about  Provable properties  More “embeddability”  Application might remain in control  RTOS is a library  Footprint/size is a concern  Compile time configurations, only basis services

4. RTOS Basic Functions  Kernel (scheduler, resource management)  Error handling  System clock functions  Device drivers, network stack send/receive  IPC  Initiate and start  Task state switching  ISR  Memory management

5. Device Drivers  Goal  Provide a standard interface to any I/O device  Motivation  Lets OS control the device and its resources  Lets programs be easily written for new devices  Lets new devices be attached to the system

6. OS & Device Drivers  User/kernel boundary  Supported as part of the CPU  Privileged vs non-privileged instructions  I/O instructions are privileged  Interrupts are privileged  Memory mapping instructions are privileged  Kernel takes care of  Memory management  Process scheduling  All I/O

7. I/O Devices  Can be broken down by category (flavor)  CHAR : device accessed like a stream  Serial I/O, tty, mouse, sound  Also simple devices (parallel I/O)  BLOCK : device accessed in bulk  Often DMA access  NETWORK : device is a network device  Devices of the same flavor have much in common

8. Device Numbers  Devices Identified by a device number  Number: (major,minor)  Major number: driver ID  Minor number: used by the driver  Allocated dynamically in modern OS  /dev/xxx -> identifies major and minor numbers

9. Kernel Modules  Modern kernels allow you to add/remove drivers  Dynamically  Without rebuild, reboot, recompile  Kernel code is restricted programming  No general libraries available  Kernel functions are callable  Some (limited) memory allocation, delay, synch, logging

10. User Access to Devices  Uses the file interface (device = file)  open() : provides access to the device  Can be exclusive (write) or nonexclusive (read)  close() : releases the device  Standard access calls  read, write  seek  ioctl, fcntl  What do these operations mean?  Whatever the driver says they mean

11. Device Driver Interface  module_init, module_exit  Routines called on installation and removal  Init  Registers the device  Sets the device to a known state  Gets the IRQ, addresses of I/O  Exit  Releases the memory addresses

12. Device Driver Interface  Driver provides other methods  open(), read(), write(), llseek(), ioctl(), fasync(), release()  These can be omitted is not relevant  All calls provided with a common kernel structure (filp)  That can hold local information about the device  open/release – fill in the data structure  read/write provided with pointers to user space  fasync – indicates asynchronous I/O desired

13. Device Driver Interface  ioctl(int device,int command,{data})  command is device specific (header file defined)  data might be a reference to user address space  Commands can be used to control the device  Pinball: RESET, READREG, WRITEREG, DATA, DISPLAY, INTERR

14. RTOS Scheduling  Tasks  State: RUNNING, READY/RUNNABLE, WAITING/BLOCKED  Waiting: TIMER, INTERRUPTS, LOCK  Priority  Context (stack pointer, registers) for preemption  Valid state transitions  RUNNING -> READY, READY -> RUNNING  sched() : makes proper task running  RUNNING -> WAITING  suspend() : moves current job to waiting state  WAITING -> READY  wakeup() called when job gets an interrupt

15. RTOS Task Interface  Task interface to scheduler  yield() [RUNNING->READY], sleep() [RUNNING->TIMERS]  acquire(), release()  read(), write()  Locks  Each lock maintains a queue and a state  Handle acquire and release appropriately  I/O  Each device maintains a queue  Timing  Maintain a timer queue (ordered by wake up time)  Processed on timer interrupts

16. RTOS Tasks  What does a task look like in a RTOS?  Consider outputting a sound sample  Loop while samples exist  Output current sample  Get time until next sample  Sleep  Note that waiting here is okay (why?)  Consider checking switches in tic-tac-toe

17. RTOS Tasks  What information does a scheduler need about a real time (periodic) task  For RM/DM scheduling  For EDF scheduling  How might that information be conveyed?

18. Task Priorities  Suppose each task has a priority  Based on its rate (period)  Smaller rates have higher priority  Sporadic tasks have lower priority  What happens then?  Assume that periodic tasks use less than 50% of time  What can you say about them meeting deadlines

19. RTOS Scheduling  Real time tasks and real time priorities  Other tasks: simple method  Round robin, FIFO, priority based; fair share  Priority approach using dynamic priority (UNIX)  Priority increases if suspended voluntarily  CPU-bound processes are penalized  Low-priority “snubbed” processes are increased  Limit to priority fluctuation  This doesn’t work for real time tasks

20. RTOS Examples: Arduino  Operating system is a set of libraries  Provide access to I/O lines (analog/digital)  PWM output, analog input, pull-up  Read/write from SD or memory  Provide access to timers, interrupts  Provide network access  Initialization/Loop  No scheduling

21. RTOS: μCOS (MUCOS, Micro-C OS)  Library of C routines implementing OS functions  User stays in control  Highly protable, ROM-able, scalable, preemptive, deterministic  Up to 64 tasks (56 user)  Connectivity to GUI and file system interfaces (drivers)  8 to 64 bit processors supported  Functions  Task management, memory management, time management, IPC

22. μCOS Task Management  Rate monotonic scheduling  All tasks are periodic  Tasks have priority (based on period)  Same priority tasks are handled via round robin  Assumes true periodic load is < 69%  States  Processing: new, ready, waiting, running, terminated  Critical regions  OS_ENTER_CRITICAL, OS_EXIT_CRITICAL  Task switching  OS_TASK_SW switches task  Saves registers, restores registers, returns to new task

23. μCOS Functionality  Memory Management  Done in terms of partitions (fixed size blocks)  Allocation is constant time and deterministic  Multiple partitions provide blocks of different sizes  Time Management  Clock tick every 10-100ms increments a counter  Delay and resume based on the counter  IPC  Semaphores, mailboxes, message queues  ISR routines can interact using wait/signal

24. μCOS Features  Addons (additional libraries)  Bitmapped graphics  FAT file system  Embeddability  Individually enable or disable features  Semaphores, mailboxes, message queues  Task manipulations (delete, change priority)  Number of tasks, events, queue sizes  Small footprint (15k with everything enabled)

25. 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

26. 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

27. 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

28. Next Time  We’ll look at real operating systems for RT/embedded programming