--- a/Symbian3/PDK/Source/GUID-2700AAC8-A034-5E7D-B0E0-26B49E68BB18.dita Thu Mar 11 15:24:26 2010 +0000
+++ b/Symbian3/PDK/Source/GUID-2700AAC8-A034-5E7D-B0E0-26B49E68BB18.dita Thu Mar 11 18:02:22 2010 +0000
@@ -1,69 +1,69 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License
-"Eclipse Public License v1.0" which accompanies this distribution,
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
- Nokia Corporation - initial contribution.
-Contributors:
--->
-<!DOCTYPE concept
- PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<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 layer
-to the Kernel to provide an emulation of a real time operating system (RTOS)</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>. 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. </p>
-<p>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 <xref href="GUID-5B1D8D9C-90EF-5FCC-8D7D-01B13D6C2E68.dita">Nanokernel</xref> layer
-as the underlying real time kernel. </p>
-<p>The following diagram illustrates the point simply. </p>
-<fig id="GUID-AA5502A3-37BE-5A73-A8D9-1B18DDCC8C96">
-<image href="GUID-058FAE44-DF72-53E2-BE62-EDC840A7C87F_d0e366434_href.png" placement="inline"/>
-</fig>
-<p>There is sample code at <filepath>...\e32\personality\...</filepath> that
-you should refer to while reading this. </p>
-<section id="GUID-D1217729-E0E4-5A02-A02F-524EA9F1D679"><title>RTOS environment
-features</title> <p>As a basis for emulating an RTOS, the RTOS is assumed
-to provide the following features: </p> <ul>
-<li id="GUID-107CEB20-80DA-5AF8-A116-C5FA5E437993"><p>Threads </p> </li>
-<li id="GUID-496701DC-E711-5509-B593-5B5A51A7DFC2"><p>Thread synchronisation/communication </p> </li>
-<li id="GUID-5ADDB09E-7528-50E0-8661-C64C91AF32CA"><p>Thread scheduling following
-a hardware interrupt </p> </li>
-<li id="GUID-4856FE5E-95E6-5455-B226-9314071F948E"><p>Timer management functionality </p> </li>
-<li id="GUID-C721F13B-14F9-5E01-9721-19E9475A421B"><p>Memory management. </p> </li>
-</ul> <p><b>Threads</b> </p> <p>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. </p> <p><b>Thread
-synchronisation/communication</b> </p> <p>Typical examples of such thread
-synchronisation and communication mechanisms are semaphores, message queues
-and event flags. </p> <p>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. </p> <p><b>Thread scheduling following a hardware interrupt</b> </p> <p>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. </p> <p>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. </p> <p><b>Timer management functionality</b> </p> <p>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. </p> <p><b>Memory management</b> </p> <p>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. </p> </section>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<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 layer
+to the Kernel to provide an emulation of a real time operating system (RTOS)</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>. 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. </p>
+<p>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 <xref href="GUID-5B1D8D9C-90EF-5FCC-8D7D-01B13D6C2E68.dita">Nanokernel</xref> layer
+as the underlying real time kernel. </p>
+<p>The following diagram illustrates the point simply. </p>
+<fig id="GUID-AA5502A3-37BE-5A73-A8D9-1B18DDCC8C96">
+<image href="GUID-058FAE44-DF72-53E2-BE62-EDC840A7C87F_d0e366434_href.png" placement="inline"/>
+</fig>
+<p>There is sample code at <filepath>...\e32\personality\...</filepath> that
+you should refer to while reading this. </p>
+<section id="GUID-D1217729-E0E4-5A02-A02F-524EA9F1D679"><title>RTOS environment
+features</title> <p>As a basis for emulating an RTOS, the RTOS is assumed
+to provide the following features: </p> <ul>
+<li id="GUID-107CEB20-80DA-5AF8-A116-C5FA5E437993"><p>Threads </p> </li>
+<li id="GUID-496701DC-E711-5509-B593-5B5A51A7DFC2"><p>Thread synchronisation/communication </p> </li>
+<li id="GUID-5ADDB09E-7528-50E0-8661-C64C91AF32CA"><p>Thread scheduling following
+a hardware interrupt </p> </li>
+<li id="GUID-4856FE5E-95E6-5455-B226-9314071F948E"><p>Timer management functionality </p> </li>
+<li id="GUID-C721F13B-14F9-5E01-9721-19E9475A421B"><p>Memory management. </p> </li>
+</ul> <p><b>Threads</b> </p> <p>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. </p> <p><b>Thread
+synchronisation/communication</b> </p> <p>Typical examples of such thread
+synchronisation and communication mechanisms are semaphores, message queues
+and event flags. </p> <p>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. </p> <p><b>Thread scheduling following a hardware interrupt</b> </p> <p>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. </p> <p>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. </p> <p><b>Timer management functionality</b> </p> <p>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. </p> <p><b>Memory management</b> </p> <p>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. </p> </section>
</conbody></concept>
\ No newline at end of file