A challenge of this project is a creating of pure object-oriented small footprint real-time operating system (RTOS) for embedded devices. C++ language, Active Object (AO) and hierarchical state machine (HSM) design templates are chosen as implementation bases. Using of message driven synchronization of Active Object allows refusing any other synchronization mechanisms. It is making developing of embedded application easy, improves response time, eliminates priority inversion problem, dismisses thread blocking and increase stability of RTOS.

Object oriented approach (OOA) allows encapsulate data in address space of objects. AO expanses idea of data encapsulation in time domain. OOA makes easier developing of embedded systems and allows using UML design tools for automation of embedded software developing.

Avoid semaphore, blocking of threads and priority inversion. Using only AO message mechanism.

Design of described RTOS is based on object oriented approach. Why so important to use a pure OOA? OOA itself is not a technology or instrument but using one can directly improves characteristics of designed system. On the contrary, OO compilers produce a larger and slower code than non-OO ones. But OOA is a methodology that allows to developer who uses it to make a systems substantially reliable and scalable, allows using analysis and synthesis theory's methods.

The key problem of multitasking RTOS is problem of data protection or how avoid an undesirable access to data. OO approach gives a good conception of data protection - this is a data encapsulation inside object. Data of given object can be read and modified only by methods of class that owns the object. Other objects of given class and an objects of another classes are forbidden to directly access the inner data of the object. This situation guarantees that given data can be accessed only from well defined and limited piece of code (methods of given class). Let's take a look at Fig. 3.1.(b). This diagram shows a permitted ways to access object data. So data in address space is protected from unauthorized access with using OOA. But this is not true when we consider data protection in time domain (in time base).

When RTOS executes a multitasking application then a different threads of the application try to concurrently access the same data (or invokes the same method of different objects that is equivalent). This situation can lead to unpredictable changes and destroying of data. In order to regulate it the data processing by one thread has to be blocked for accessing of other threads. Concurrent access to data can be prevented by synchronization mechanism such as semaphore or mutex [1]. Lets look at Fig. 3.2. Here is three threads are running and are trying access data of the same object. When thread 3 asks for data and gets an access to one by invoking of some object's method then thread 3 have to lock the object's data (to prevent access from others ones - T1 and T2). Then thread 1 try to access the data but the object's semaphore does not allow the operation. So T1 (high priority thread) have to wait for T3 (low priority ) while it releases this resource. Faremore slice time (t3-t4) that can be used by high priority thread 3 now is used by middle priority thread 2 so priority inversion occurs in this period. Attempt to fix up this behavior by using of more complex semaphores and mutexes leads to complexity of software and to degradation of system's reliability. If OOA gives us a hard data protection in address space may be one can do the same things in time? Active Object design pattern that widely using in other software areas [2] can do it.

Active Object (see Fig. 3.3.) consists of data object itself (D and C), inner own thread (Tao) and FIFO (first input first output) queue (Q) for keeping of incoming messages (R1, R2, R3). When other thread (T1, T2 or T3) wants to access data this thread put request to AO queue instead of direct calling of an object's method. The inner AO thread (Tao) is running in loop and is checking the queue for unprocessed request and then invokes needed object's method. The all requests from different threads are sequentially processed and situation when one thread is blocking other is impossible. The main idea of the project is a building of RTOS as a container of Active Objects which are running independently and are exchanging of messages between them. The only entity of this RTOS is Active object and the fact tremendously simplifies design and synchronization mechanism of the system.

There are two generic types of object in AO RTOS, this is active object (AO) and active object for interrupt processing (ISAO) that is subclass of AO. AO can receive and send messages to any other AO and ISAO. ISAO can moreover receive and process external and internal (programming) interrupts. There are two ISAO those are necessary for kernel work, ones are Timer and Scheduler ISAO's. After processing interrupt Timer executes epilogue code (as any other ISAO) and transfers control to Scheduler that switches processor context to AO with highest priority. The Timer ISAO receives and processes interrupts from system clock (or other timing service) as shown on Fig. 4.1.

A super class of the AORTOS class hierarchy is Thread that supports of processor context switching or multithreading in other words. An AObject is a direct subclass of Thread and encapsulates a data and functionality for active object control. A RingBuffer and ListenerList classes help to uphold a functioning of AObject. A custom active objects have to subclass this class. Next class in the hierarchy is ISAObject that subclasses AObject. The ISAObject defines interrupt processing service. This class is a super class for Timer and Scheduler those control the running of RTOS. Other custom objects for external interrupt serving have to subclass one. Now take a look more close to these classes.

Thread class (Fig 4.3.) is responsible for keeping AO thread context while active object is not active. It contains a few fields:

• ready is a flag which signals to RTOS scheduler that the AO is ready to resume a work (become an active). When AO have no events in buffer 'ready' is unset.
• priority keeps priority level of AO. RTOS scheduler makes decision of what AO will be active next time slice, depend on the priority
• stack[TH_STACK_LENGTH] represents stack memory segment where the AO makes stack operations produced C++ runtime and save thread context (CPU registers pool) during interrupt processing
• *sp is pointer to current position in stack[]

This class has a few methods but only one init() requires explanation. The goal of the method is preparing of AO for start up or in other words we have to simulate usual inactive state of AO so after activation by RTOS scheduler it can properly run. In active state AO executes method run() and after interruption become inactive. So in inactive state AO stack includes trace of run() call and interrupt trace (about the RTOS interruption mechanism see below) as showed in Fig. 4.4. First init() puts in stack value of object's this then puts return address from run() (it is fictive, because AO does not going return from run()). After that it puts CPU FLAGS = 0x00000202, value CS register and value IP register equals start address of run() method. init() prepares stack for RTI command. For POPA command it includes in stack values of CPU registers as showed in Fig. 4.4.

AObject class is main class of the architecture. The all objects of RTOS are a subclasses of the class.

AObject has a following fields:

• ringBuffer - implementation of FIFO queue for keeping incoming events (messages).
• list - keeps a list of references to other AOs which are listening to events generated by this AO
• stateMachine - state machine that implements all functional logic of the AO

Methods of AObject:

• AObject( prio ) - creates object with priority = prio.
• addListener(), removeListener() - adds or removes AO that is a listener of events from this object.
• publishEvent() - sends an event to the all listeners.
• receiveEvent() - this AO is listening other AO in its turn. Other AOs call this method and send an event to this AO.
• run() - executes forever loop. It checks the event queue and if queue is empty then delegates control to RTOS scheduler by generatig of programming interrupt. If the queue contains an event run() calls processEvent() method.
• processEvent() - sends an event to the state machine.

4.3.1. Helper class RingBuffer

4.3.2. Helper class ListenerList

ISAObject is subclass for all AO that are going to process of interrupt. The each interrupt makes execute Interrupt Service Routine (ISR) that is written in Assembler (see porting RTOS below). The ISR save CPU context and invoke static method of ISAObject processInterrupt( DWORD iN, TH_STACK * stk ) and passes two parameters: iN - interrupt number (corresponds to CPU interrupt descriptor table (IDT)); stk - pointer to current stack. After an interrupt has been served RTOS scheduler gets control to decide what Active object have to become active depend on them priority and ready state.

Fields :

• interruptTable[TH_INTERRUPT_TABLE_LENGTH] - this table keeps the references to ISAObjects. Index of the table is an interrupt number. So we can get from this table an object that is processing a needed interrupt.

Methods :

• ISAObject( prio, intNumber ) - constructor for ISAObject with priority = prio and interrupt number = intNumber.
• processInterrupt() - static function that gets object from interrupt table by interrupt number and executes serviceInterrupt() method of the object.
• serviceInterrupt() - virtual function that serves the interrupt and processes an interrupt's data.

There are a few notes about processInterrupt() code. Execution of the function starts with increment of nestedInterrupt variable. The all nested interrupts will be processed but its do not activate a scheduler. Scheduler is invoked during an epilog of first interrupt processing.

Scheduler object can be activated in two way:

• each time a ISAO finished a processing of an interrupt, interrupt handler invokes the scheduler.
• if a generic AO finished processing own task it can generate programming interrupt for activating of the scheduler. Scheduler will switch on to other AO that waiting for processor resource.

Fields:

• scheduledAOTable[TH_SCHEDULED_LIST_LENGTH + 1] - array keeps a references to all AO of RTOS including Scheduler and Timer ISAO. The object with highest priority has index equals 0, the lowest priority object (usually scheduler) has index equals TH_SCHEDULED_LIST_LENGTH. Element of the table with TH_SCHEDULED_LIST_LENGTH index is a fictive AO using to start up RTOS.
• N
• currentPrio

Methods :

• AOScheduler() - constructor.
• processEvent( Event * ) - this is optional event handler. If scheduler is listening other AO, this handler processes incoming events.
• serviceInterrupt( AO_STACK * stp ) - the routine processes programming interrupt linked to the scheduler. This is a main method of the class.
• add( AObject * ) - add an Active object to inner table 'scheduledAOTable[]' for scheduling.
• remove( AObject * ) - remove an Active object from table 'scheduledAOTable[]'

Active objects added to the RTOS scheduler have to have unique priority number from range 0 - (TH_SCHEDULED_LIST_LENGTH-2). Scheduler has priority (TH_SCHEDULED_LIST_LENGTH-1). Starting of RTOS has a few steps:

• Create/allocate active objects.
• Link the active objects using addListener() method of the objects.
• Add the all objects to the scheduler object using scheduler's add() method.
• Start up the RTOS using scheduler's startOS() method. The method save current thread context to the idle Active Object (index TH_SCHEDULED_LIST_LENGTH in scheduledAOTable ) stack. Then program interrupt generates and scheduler thread takes control. Scheduler find first high priority Active object and switches context to one's thread. RTOS is started now!

RTOS has to have at least two ISAO Scheduler and Timer. Timer is a heart of system it makes the scheduler to find high priority AO that is ready to run.

The design of HSM in C++ is close to design of Java HSM. See detailed explanation here and in code comments.

The project is implemented under Linux using GCC and Eclipse IDE with CDT plugin. The project is building by ANT.

Eclipse's Project folder consist of follows:

• Application - folder for custom application code that implements developed system functionality. This application will run under control of AO RTOS. Structure of the application is just set of custom AO classes linked between each others. The folder is divided to few application folder : Application/Test_1, Application/Test_2 ...
• HSM - folder keeps an implementation of Hierarchical State Machine. HSM is very convenient design template for implementing custom AO functionality.
• Kernel - folder holds an implementation of kernel of Active Object real-time OS
• Porting - folder contains a classes for porting the RTOS to different targets. There is only one target Intel 80x86 processor for now. It resides in folder Porting/Ix86.
• obj - helper folder.

Sub folders looks like sub-projects and contains source code and ANT script file build.xml for compiling this code:

• Application/Test_1/build.xml
• HSM/build.xml
• Kernel/build.xml
• Porting/ix86/build.xml

The root of project has a main building script file (build.xml too) and file with set of variable for building process (build.properties).

The result of building of project is a bootable floppy disk with real-time application. Then produced floppy disk is used to boot and run embedded application on Intel-x86 PC target - just put the floppy-disk to drive and push 'reset' button (of course you have to set PC BIOS to start to boot from floppy).

Porting to Ix86 target is provided by assembly code modules that is contained in follows files:

• InitLoader.asm - provides a loading the application from floppy disk to target memory.
• PMStarter.asm - sets up data structures for running target in protected mode. Then places application code to runtime memory location and starts up.
• ScreenLib.asm - optional library for PC display control.
• os_cpu.asm - buffer code layer between C++ modules and low-level (hardware level) assembly code
• pc.cpp - optional library that implement printf()-like procedures for PC display.

Start up process has a few steps :

• 1. PC BIOS loader reads and runs initial loader from floppy.
• 2. Initial loader loads PMStarter from floppy and runs it.
• 3. PMStarter loads AORTOS application from floppy.
• 4. Then prepares and switches on the system to protected mode with flat memory model.
• 5. Relocates and starts application.

Project building starts with running of ANT script build.xml from root folder of project. The build script uses build.properties file as a input arguments:

• appDir - folder where application code resides
• targetDir - folder where binary application will be written after linkage
• Compile_Flags - set of flags for compiler (g++) input
• Link_Flags - set of flags for linker (ld) input
• libCpp - folder where GCC object libraries resides
• listingDir - folder for compiler and linker listing
• objDir - folder with .ld file for linker

The main build.xml script has a three targets:
init, prepare - prepare build space.
compile - the target run other ant build scripts for sub-projects: Kernel, Porting, HSM and application itself.
link - the target collects and links compiled object files from above target and makes binary file.
floppy - makes a floppy disk for booting and deploying the application on target PC.

Build scripts in sub-folders Kernel, HSM and Application/... make compilation tasks using GCC compiler g++. Porting/Ix86 folder contains script for compiling source files using assembly compiler NASM.

The application defines two classes DisplayAO and MyAO. Both are an Active object subclasses. The task implements a simple exchange of messages between three Active object : AO_1, AO_2 and display.

DisplayAO is a wrapper for Display object (Display class is defined in Porting/Ix86/pc/pc.cpp). DisplayAO is waiting for messages (or events) with ID = 'show' or 'show1' or 'tick'. If 'show*' message comes then DisplayAO retrieves the message from ring buffer, extracts from the message a reference to AO that sent this one. Then it gets a string from the AO and displays the string. And finally sends to the AO message 'done' to notify the AO that operation is over. 'tick' message is used to clean a display after delay.

MyAO is a custom active object that waiting for messages 'tick', 'task' or 'done'. After MyAO gets 'tick' message from Timer counts it and selects one second moment for sending information message to DisplayAO. MyAO sends each max seconds message to other AOs. If the AO receives 'task' message from other AO then it publishes message 'show' for DisplayAO.

Description coming soon. See code for details.

Download source code