Personality Layer for Real Time Applications

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

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.