<?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_d0e115760_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_d0e115768_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>