Collapse all Symbian^3 Product Developer Library

Personality Layer for Real Time Applications

A base port can add a software layer called a personality layer to the Kernel to provide an emulation of a real time operating system (RTOS)

. You can provide a personality layer so that a phone can run existing protocol stacks, for example, mobile telephony signalling stacks, or Bluetooth stacks, on the same CPU that runs the Symbian platform applications.

Such protocol stacks, often referred to as Real Time Applications (RTA), almost always run on an RTOS, and the aim of the personality layer is to provide the same API as the RTOS, or at least as much of it as is required by the RTA. The RTA can then run, using the Kernel Architecture 2 Nanokernel layer as the underlying real time kernel.

The following diagram illustrates the point simply.

There is sample code at ...\e32\personality\... that you should refer to while reading this.

RTOS environment features

As a basis for emulating an RTOS, the RTOS is assumed to provide the following features:

Threads
Thread synchronisation/communication
Thread scheduling following a hardware interrupt
Timer management functionality
Memory management.

Threads

Threads are independent units of execution, usually scheduled on a strict highest-priority-first basis. There are generally a fixed number of priorities. Round robin scheduling of equal priority threads may be available but is usually not used in real time applications. Dynamic creation and destruction of threads may or may not be possible.

Thread synchronisation/communication

Typical examples of such thread synchronisation and communication mechanisms are semaphores, message queues and event flags.

There is wide variation between systems as to which primitives are provided and what features they support. Again, dynamic creation and destruction of such synchronisation and communication objects may or may not be supported. Mutual exclusion protection is often achieved by simply disabling interrupts, or occasionally by disabling rescheduling.

Thread scheduling following a hardware interrupt

This is usually achieved by allowing interrupt service routines (ISRs) to make system calls which perform operations such as signalling a semaphore, posting a message to a queue or setting event flags, which would cause a thread waiting on the semaphore, message queue or event flag to run.

Some systems don't allow ISRs to perform these operations directly but require them to queue some kind of deferred function call. This is a function which runs at a lower priority than hardware interrupts (i.e. with interrupts enabled) but at a higher priority than any thread - for example a Nucleus Plus HISR. The deferred function call then performs the operation which causes thread rescheduling.

Timer management functionality

A timer management function is usually also provided, allowing several software timers to be driven from a single hardware timer. On expiry, a software timer may call a supplied timer handler, post a message to a queue or set an event flag.

Memory management

An RTOS often provides memory management, usually in the form of fixed size block management as that allows real time allocation and deallocation. Some RTOSs may also support full variable size block management. However most RTOSs do not support use of a hardware MMU and, even if the RTOS supports it (for example OSE does), the real time applications under consideration do not make use of such support since they are generally written to run on hardware without an MMU.

Parent topic: Concepts