Operating System Abstraction Layer (OSAL)

The framework incorporates an OSAL providing service abstraction classes of a fictitious operating system that can perform all the operations of a real operating system. This layer shows the user an abstraction of the common functionality provided by all real-time operating systems (RTEMS, VxWorks, Azure ThreadX, QNX, FreeRTOS, Zephyr,…) or not (Linux, macOS, WinCE,…). We find the following services:

1. multitasking management with prioritization ;
2. synchronization ;
3. file management;
4. message queues;
5. communication; and
6. timeout.

OSAL provides each of these services by wrapping the concrete operating system entities it encapsulates in thin wrappers. This layer enables the development and testing of adaptable software systems that do not depend on any particular operating system, allowing development to be performed at the development workstation. It reduces the time and effort required for developers to migrate a software system from one operating system to another.

Implementations of these classes are provided for Unix (POSIX) and Mac OS variants. Additional ports can be realized by providing additional implementations when a new operating system is added. This guide will walk through the critical files in this layer to allow developers to understand and provide an overview for those looking to port to a new operating system.

This guide discusses the following:

• Tasks
• Task Registry
• Mutexes
• Message Queues
• Interval Timer
• Watchdog Timer
• Interrupt Lock
• File
• FileSystem
• Log

Tasks

Tasks are called threads under Unix variants, and tasks under other OSes. A developer may wish to start tasks to wait on an event or a resource that is not a port invocation. The Os task class definition can be found in Os/OsTask.hpp. The OS implementations are found in various subdirectories. Active components require the use of tasks to implement their features. Table 23 describes the methods of the class.

Table 23. Task method descriptions.

Task Registry

Task registries are meant to be used to track all task instances in the system. The concept is that this registry would contain pointers to all the instances and be able to iterate over them and perform actions. The file Os/Task/Task.hpp provides a base class definition of a registry with the addTask() and removeTask() pure virtual function definitions. Developers would write their own derived classes to implement a registry that is appropriate for their system.

Mutexes

The class definition can be found in Os/Mutex.hpp. The functions lock() and unlock() lock and unlock the mutex. The mutex should be unlocked after construction is complete.

Message Queues

The class definition can be found in Os/Queue.hpp. This class implements message queues. Table 24 describes the methods.

Table 24. Message queues method descriptions.

Interval Timer

The class definition can be found in Os/IntervalTimer.hpp. An interval timer is a facility that starts and stops the measurement of the passage of time in the system. It is not an expiration timer that signals when it is complete. It is used to measure execution times of, or to timestamp, software activities. Table 25 provides the methods and their descriptions.

Table 25. Interval timer method descriptions.

Watchdog Timer

Note: This file implementation is not required for all OS adaptations. Only those needing watchdog functionality.

The class definition can be found in Os/WatchdogTimer.hpp A watchdog timer schedules a callback at the specified time in the future. It is a one-shot timer; it needs to be rescheduled each time. Table 26 provides the methods and their descriptions.

Table 26. Watchdog timer method descriptions.

Interrupt Lock

The class definition can be found in Os/InterruptLock.hpp. An interrupt lock prevents interrupts from preempting code execution. It can be used as a very lightweight mutex on platforms that support interrupt locking but should be used carefully as it is not subject to priorities like a conventional mutex. In addition, it defers interrupts that could be time critical, so the code executed between the locking and unlocking should be very short in duration. This is a portable interface, but the user should be aware of the behavior for each OS. Table 27 provides the methods and their descriptions.

Table 27. Interrupt lock method descriptions.

File

The class definition can be found in Os/File.hpp. The file class attempts to abstract the most common file functions to a class interface to make porting code that does file accesses easier. Table 28 provides the methods and their descriptions.

Table 28. File method descriptions.

File System

The file system OS classes found in Os/FileSystem.hpp contain the file system helper calls to create directories, remove directories, etc.

Note: There are also the Os/Directory.hpp classes that allow users to stream directories.

Log

This class definition can be found in Os/Log.hpp. It is an interface to a system logging facility. It is meant to abstract the VxWorks logging facility. It is a subclass of Fw::Logger and thus must be registered after construction. Compiling in Os/LogDefault.cpp into your deployment will automatically create an Os::Log and register it. Table 30 provides the methods and their descriptions.

Table 30. Log method descriptions.