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

    13 Layer for Real Time Applications</title><shortdesc>A base port can add a software layer called a personality layer

    14 to the Kernel to provide an emulation of a real time operating 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, or Bluetooth

    17 stacks, on the same CPU that runs the Symbian platform applications. </p>

    18 <p>Such protocol stacks, often referred to as Real Time Applications (RTA),

    19 almost always run on an RTOS, and the aim of the personality layer is to provide

    20 the same API as the RTOS, or at least as much of it as is required by the

    21 RTA. The RTA can then run, using the Kernel Architecture 2 <xref href="GUID-5B1D8D9C-90EF-5FCC-8D7D-01B13D6C2E68.dita">Nanokernel</xref> layer

    22 as the underlying real time kernel. </p>

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

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

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

    26 </fig>

    27 <p>There is sample code at <filepath>...\e32\personality\...</filepath> that

    28 you should refer to while reading this. </p>

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

    30 features</title> <p>As a basis for emulating an RTOS, the RTOS is assumed

    31 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 following

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

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

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

    38 </ul> <p><b>Threads</b> </p> <p>Threads

    39 are independent units of execution, usually scheduled on a strict highest-priority-first

    40 basis. There are generally a fixed number of priorities. Round robin scheduling

    41 of equal priority threads may be available but is usually not used in real

    42 time applications. Dynamic creation and destruction of threads may or may

    43 not be possible. </p> <p><b>Thread

    44 synchronisation/communication</b> </p> <p>Typical examples of such thread

    45 synchronisation and communication mechanisms are semaphores, message queues

    46 and event flags. </p> <p>There is wide variation between systems as to which

    47 primitives are provided and what features they support. Again, dynamic creation

    48 and destruction of such synchronisation and communication objects may or may

    49 not be supported. Mutual exclusion protection is often achieved by simply

    50 disabling interrupts, or occasionally by disabling rescheduling. </p> <p><b>Thread scheduling following a hardware interrupt</b> </p> <p>This is usually

    51 achieved by allowing interrupt service routines (ISRs) to make system calls

    52 which perform operations such as signalling a semaphore, posting a message

    53 to a queue or setting event flags, which would cause a thread waiting on the

    54 semaphore, message queue or event flag to run. </p> <p>Some systems don't

    55 allow ISRs to perform these operations directly but require them to queue

    56 some kind of deferred function call. This is a function which runs at a lower

    57 priority than hardware interrupts (i.e. with interrupts enabled) but at a

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

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

    60 is usually also provided, allowing several software timers to be driven from

    61 a single hardware timer. On expiry, a software timer may call a supplied timer

    62 handler, post a message to a queue or set an event flag. </p> <p><b>Memory management</b> </p> <p>An RTOS often provides memory management,

    63 usually in the form of fixed size block management as that allows real time

    64 allocation and deallocation. Some RTOSs may also support full variable size

    65 block management. However most RTOSs do not support use of a hardware MMU

    66 and, even if the RTOS supports it (for example OSE does), the real time applications

    67 under consideration do not make use of such support since they are generally

    68 written to run on hardware without an MMU. </p> </section>

    69 </conbody></concept>