<?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-107AE89E-901E-535F-8D1A-EE347D7822B1" xml:lang="en"><title>Architecture</title><shortdesc>This topic describes the architecture of the Serial Communications

Server. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>The Serial Communications Server uses the Symbian platform client/server

framework. Clients use <codeph>R</codeph> classes that send requests to the

Serial Communications Server. The server in turn passes requests to an appropriate

plug-in module that handles the particular communication protocol. These plug-in

modules are known as <i>Serial Protocol Modules</i> or <i>CSYs</i>. The Serial

Protocol Modules are loaded by the Serial Communications server, and are not

directly accessed by client applications. A Symbian platform phone may include

a number of Serial Protocol Modules as standard, such as for handling RS232

and infra-red serial communications. The Serial Protocol Module API allows

new Serial Protocol Modules modules to be developed. </p>

<p>The Serial Communications Server provides a publishedAll API to access

the serial ports of the device. The Serial Communications Server provides

functionality such as timeouts and port sharing for all Serial Protocol Modules.

The Serial Protocol Modules provide the specific protocol and communicate

with the serial device driver. To communicate with the serial device driver,

the Serial Protocol Modules use publishedPartner APIs such as <xref href="GUID-3B4E8ED5-72F7-3E51-B188-3C1045526DDF.dita"><apiname>RBusDevComm</apiname></xref>.

The <codeph>RBusDevComm</codeph> API provides a handle to a channel to the

serial device driver. This device driver only implements the basic data transfer

and break operations, and is not intended for use directly by client applications.

The device driver is implemented using a Physical Device Driver (PDD) and

a Logical Device Driver (LDD). The PDD and LDD must be loaded before a Serial

Protocol Module can be used. For a device being tested, the application client

may need to load the PDD and LDD. For a device that is shipped, the boot sequence

normally loads the LDDs and PDDs. Figure 1 below shows the architecture and

the appropriate APIs at each level. Figure 2 below shows the architecture

with three Serial Protocol Modules loaded. </p>

<fig id="GUID-4F316E33-41C6-5BF4-AAE1-2750C58CC1AA">

<title>           Figure 1 - The architecture and the appropriate APIs at

each level         </title>

<image href="GUID-44ADB485-69C2-5557-AB95-3B6D20870F73_d0e122298_href.png" placement="inline"/>

</fig>

<fig id="GUID-5B17051E-C4E7-5657-BB62-26072FB13D83">

<title>           Figure 2 - The architecture with three CSYs loaded     

   </title>

<image href="GUID-45DD08DB-FCB3-5546-91B4-25868C8ABAE4_d0e122306_href.png" placement="inline"/>

</fig>

<p>Each serial port has a limited availability when multiple clients attempt

to use the port. The Serial Communications Server provides some functionality

to mediate between competing clients. This mediation is provided by the <xref href="GUID-3B4E8ED5-72F7-3E51-B188-3C1045526DDF.dita"><apiname>RComm::Open()</apiname></xref> and <xref href="GUID-3B4E8ED5-72F7-3E51-B188-3C1045526DDF.dita"><apiname>RComm::OpenWithAvailable()</apiname></xref> APIs.

However, the first client to access a port has control. If a client must get

access to a serial port, then that client must ensure it connects to the serial

port before other clients. The reliable method of ensuring access to a serial

port is for a client to connect as part of the device boot procedure. If a

client must have access to a serial port, then the device manufacturer should

specify which clients access ports during device boot. </p>

<section id="GUID-39D0A44F-3E6D-486F-BC72-A4260374419C"><title>Historical Notes</title> <ol id="GUID-920828D6-9304-5E44-B82D-671097029B21">

<li id="GUID-EE61E2E6-EABB-58D1-AE5A-E452589F5D3C"><p>The framework supplied

by the Serial Communications Server for Serial Protocol Modules has a narrower

set of capabilities compared to the Socket Server for protocol developers. </p> </li>

<li id="GUID-DB979584-6BBE-56AA-8068-FC5650D40A46"><p>In Symbian platform,

the Serial Communications Server was converted into a multi-threaded server.

The Serial Protocol Modules can be run in separate threads. This change did

not change the behaviour of the Serial Communications Server except for three

changes: </p> <ol id="GUID-0BCD64C0-448E-5ACA-9928-AC30E42A59CF">

<li id="GUID-5EFB6685-D6E8-53D9-B3B6-5E1A944F4247"><p>A serial protocol module

which blocks does not stop other Serial Protocol Modules from running </p> </li>

<li id="GUID-71E76203-BA35-5854-AC89-E105BEBDB6B3"><p>A serial protocol module

can run faster than other modules by changing the configured thread priority </p> </li>

<li id="GUID-B844EEB9-B241-553B-8631-622BDA0B7A84"><p>A serial protocol module

can use the Serial Communications Server API and request services of another

serial protocol module </p> </li>

</ol> </li>

</ol> </section>

</conbody><related-links>

<link href="GUID-D0D27AEA-FDDB-5F6F-94F6-ADDF5910DC47.dita"><linktext>        

        Client/Server Overview</linktext></link>

</related-links></concept>