1 <?xml version="1.0" encoding="utf-8"?>

     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

     3 <!-- This component and the accompanying materials are made available under the terms of the License 

     4 "Eclipse Public License v1.0" which accompanies this distribution, 

     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

     6 <!-- Initial Contributors:

     7     Nokia Corporation - initial contribution.

     8 Contributors: 

     9 -->

    10 <!DOCTYPE concept

    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

    12 <concept id="GUID-2700AAC8-A034-5E7D-B0E0-26B49E68BB18" xml:lang="en"><title>Personality Layer for Real Time Applications</title><shortdesc>A base port can add a software layer called a personality

    13 layer to the Kernel to provide an emulation of a real time operating

    14 system (RTOS)</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    15 <p>. You can provide a personality layer so that a phone can run existing

    16 protocol stacks, for example, mobile telephony signalling stacks,

    17 or Bluetooth stacks, on the same CPU that runs the Symbian platform

    18 applications. </p>

    19 <p>Such protocol stacks, often referred to as Real Time Applications

    20 (RTA), almost always run on an RTOS, and the aim of the personality

    21 layer is to provide the same API as the RTOS, or at least as much

    22 of it as is required by the RTA. The RTA can then run, using the Kernel

    23 Architecture 2 Nanokernel layer as the underlying real time kernel. </p>

    24 <p>The following diagram illustrates the point simply. </p>

    25 <fig id="GUID-AA5502A3-37BE-5A73-A8D9-1B18DDCC8C96">

    26 <image href="GUID-058FAE44-DF72-53E2-BE62-EDC840A7C87F_d0e25110_href.png" placement="inline"/>

    27 </fig>

    28 <p>There is sample code at <filepath>...\e32\personality\...</filepath> that you should refer to while reading this. </p>

    29 <section id="GUID-D1217729-E0E4-5A02-A02F-524EA9F1D679"><title>RTOS

    30 environment features</title> <p>As a basis for emulating an RTOS,

    31 the RTOS is assumed to provide the following features: </p> <ul>

    32 <li id="GUID-107CEB20-80DA-5AF8-A116-C5FA5E437993"><p>Threads </p> </li>

    33 <li id="GUID-496701DC-E711-5509-B593-5B5A51A7DFC2"><p>Thread synchronisation/communication </p> </li>

    34 <li id="GUID-5ADDB09E-7528-50E0-8661-C64C91AF32CA"><p>Thread scheduling

    35 following a hardware interrupt </p> </li>

    36 <li id="GUID-4856FE5E-95E6-5455-B226-9314071F948E"><p>Timer management

    37 functionality </p> </li>

    38 <li id="GUID-C721F13B-14F9-5E01-9721-19E9475A421B"><p>Memory management. </p> </li>

    39 </ul> <p><b>Threads</b> </p> <p>Threads are independent units of execution,

    40 usually scheduled on a strict highest-priority-first basis. There

    41 are generally a fixed number of priorities. Round robin scheduling

    42 of equal priority threads may be available but is usually not used

    43 in real time applications. Dynamic creation and destruction of threads

    44 may or may not be possible. </p> <p><b>Thread synchronisation/communication</b> </p> <p>Typical examples

    45 of such thread synchronisation and communication mechanisms are semaphores,

    46 message queues and event flags. </p> <p>There is wide variation between

    47 systems as to which primitives are provided and what features they

    48 support. Again, dynamic creation and destruction of such synchronisation

    49 and communication objects may or may not be supported. Mutual exclusion

    50 protection is often achieved by simply disabling interrupts, or occasionally

    51 by disabling rescheduling. </p> <p><b>Thread scheduling following a hardware interrupt</b> </p> <p>This

    52 is usually achieved by allowing interrupt service routines (ISRs)

    53 to make system calls which perform operations such as signalling a

    54 semaphore, posting a message to a queue or setting event flags, which

    55 would cause a thread waiting on the semaphore, message queue or event

    56 flag to run. </p> <p>Some systems don't allow ISRs to perform these

    57 operations directly but require them to queue some kind of deferred

    58 function call. This is a function which runs at a lower priority than

    59 hardware interrupts (i.e. with interrupts enabled) but at a higher

    60 priority than any thread - for example a Nucleus Plus HISR. The deferred

    61 function call then performs the operation which causes thread rescheduling. </p> <p><b>Timer management functionality</b> </p> <p>A timer management

    62 function is usually also provided, allowing several software timers

    63 to be driven from a single hardware timer. On expiry, a software timer

    64 may call a supplied timer handler, post a message to a queue or set

    65 an event flag. </p> <p><b>Memory management</b> </p> <p>An RTOS often provides memory management,

    66 usually in the form of fixed size block management as that allows

    67 real time allocation and deallocation. Some RTOSs may also support

    68 full variable size block management. However most RTOSs do not support

    69 use of a hardware MMU and, even if the RTOS supports it (for example

    70 OSE does), the real time applications under consideration do not make

    71 use of such support since they are generally written to run on hardware

    72 without an MMU. </p> </section>

    73 </conbody></concept>