Real Time Operating Systems Memory Management & Device Control

4-Jun-16 Major RW Smith Memory Management & Device Control- 2 Outline  Memory Management  Classic Memory Problems  Processes, Threads & Partitions  Memory Management in  C/OS-II  Device Control  Device (Hardware) Input / Output Mechanisms  Status Driven Device Control  Interrupt Driven Device Control  An Example: the Bytronic IBM PPI Card

4-Jun-16 Major RW Smith Memory Management & Device Control- 3 “Classic” Memory Problems  What memory issues / errors are common to programs written in low-level languages like C?  How do languages like Java address many of these issues?  Why is that solution not suitable for most real-time systems?

4-Jun-16 Major RW Smith Memory Management & Device Control- 4 Memory Leaks  Putting the power of direct dynamic memory allocation in the hands of the developer can often lead to memory leaks  for example, malloc( ) and free( ) in ANSI C  A memory leak occurs when allocated memory is not returned to free memory after it is no longer needed  An accumulation of the leak, usually over a long period of continuous execution, can lead to a catastrophic system failure Why are so many real-time systems susceptible to this problem?

4-Jun-16 Major RW Smith Memory Management & Device Control- 5 Memory Fragmentation  Even if a program is free of memory leaks, the use of functions such as malloc( ) and free( ) over long periods of execution can often lead to memory fragmentation  Fragmentation occurs as free memory gets segmented into smaller and smaller blocks of contiguous memory  Besides introducing fragmentation issues, malloc( ) and free( ) also exhibit non-deterministic execution times, particularly due to the increasing difficulty of finding contiguous memory as fragmentation grows

4-Jun-16 Major RW Smith Memory Management & Device Control- 6 Processes, Threads & Partitions  A process is a heavy-weight unit of concurrency that executes within its own protected memory space  A thread is a light-weight unit of concurrency that executes within the same memory space as other threads  A memory partition is a contiguous region of memory made up of an integer number of fixed size blocks  accessible by any thread within the process

4-Jun-16 Major RW Smith Memory Management & Device Control- 7 Memory Management in  C/OS-II   C/OS-II provides a memory management module in support of memory partitions  Developers are encouraged to use these services instead of the dynamic memory allocation C functions malloc( ) & free( )  The system calls that make up the memory management services are all deterministic; they run in constant time {O(1)} Careful and consistent use of these services is still required if memory problems are to be avoided!

4-Jun-16 Major RW Smith Memory Management & Device Control- 8  C/OS-II OSMem services  OSMemCreate( ) 1  OSMemGet( ) 2  OSMemPut( ) 3  OSMemQuery( ) 1.Each memory partition has its own memory control block to keep track of its status. 2.The application must not use more memory than that specified by the block size. 3.Returned blocks must be put back into the correct partition. null OSMemAddr

4-Jun-16 Major RW Smith Memory Management & Device Control- 9 Example  See handout on use of memory partitions in  C/OS-II

4-Jun-16 Major RW Smith Memory Management & Device Control- 10 How does a real-time system interact with the real world?  Recall that one the main characteristics of a real-time system is to interact with its environment. In order for it to do so, software must interface to hardware via special purpose input / output devices.  Interfaces to these devices and techniques to control them vary widely because:  of different computer architectures  of different control interfaces  of different device requirements

4-Jun-16 Major RW Smith Memory Management & Device Control- 11 Device Input / Output Mechanisms  Separate bus architecture  access to a device is typically through a set of registers  logically separate bus for memory and device I/O  two sets of assembly instructions  example Intel x86 architectures CPU MemoryDeviceA DeviceBDeviceC

4-Jun-16 Major RW Smith Memory Management & Device Control- 12 Device Input / Output Mechanisms  Memory-mapped architecture  devices still typically accessed through registers  addresses divided among memory and devices  a single set of assembly instructions  example Motorola architecture CPU Memory DeviceADeviceB

4-Jun-16 Major RW Smith Memory Management & Device Control- 13 Status Driven Device Control  In this mechanism, a controlling program explicitly checks (polls) the status of a device through its register(s)  Typical hardware instructions include:  test operations which allow the program to determine the status of a device  control operations which allow the program to send device-dependent action commands to a device  input/output operations which allow the program to transfer data to/from a device

4-Jun-16 Major RW Smith Memory Management & Device Control- 14 Interrupt Driven Device Control  In this mechanism, the device itself generates an interrupt which must then be handled by the controlling program  Allows I/O to be performed asynchronously, thus avoiding the busy waiting or constant polling of pure status controlled systems  However this requires support for:  context switching  interrupt device & handler identification  interrupt control

4-Jun-16 Major RW Smith Memory Management & Device Control- 15 An Example: the Bytronic IBM PPI Card  See handouts for example showing how to control a robotic arm  The arm consists of two pulse-width modulated stepper motors which control the azimuth and elevation movement of the arm  The position of the motors is fed back via two potentiometers

4-Jun-16 Major RW Smith Memory Management & Device Control- 16 References [1] Labrosse, J.J., “MicroC/OS-II” 1 st and 2 nd Editions (1999, 2002). [2] Burns, A. and Wellings, A., “Real-Time Systems and Programming Languages”, Chapter 15, Addison Wesley, [3] Bytronic handbook, “The Bytronic IBM Internal and External Interfaces MPIBM1 and MPIBM2”, Version No 2.2.