<?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 xml:lang="en" id="GUID-1DE160DB-8054-5522-95F7-4CE5D8FFBF2E"><title>What is Serial Port Contention?</title><shortdesc>Serial Port Contention occurs when ports are not available to open client applications. This topic outlines problems and suggests solutions that Serial Port Contention raises with the C32 Serial Server Client. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>The Root Server process includes a server which allows access to the serial ports of a device. This server is known as C32 Serial Server and it sits on top of the Kernel <xref href="GUID-FF55CA91-883E-3FC3-849D-6C69EBBD1FE5.dita"><apiname>RBusDevComm</apiname></xref> APIs. The <codeph>RBusDevComm</codeph> APIs provide access to the serial ports. Serial port configuration is important because each device has a specific hardware configuration and serial ports are highly susceptible to contention issues. </p> <section><title>Serial port co-operation and contention</title> <p>The first client to open a serial port effectively owns that port and can then choose to share it or keep exclusive access. This logic can cause problems for C32 Serial server clients. C32 Serial server clients cannot use <codeph>RBusDevComm</codeph> to track clients that use the serial ports directly. In these circumstances, C32 can only see that the port is in use and reports this to all of its clients. </p> <p>To ensure a specified process can access a serial port, do one of the following: </p> <ul><li id="GUID-DA3D42DF-1E53-5811-83D4-79C9747D53C2"><p>Configure the device startup so that the specified process can open the serial port before all other applications. </p> </li> <li id="GUID-F331356C-8C75-5651-8702-FB5E47FBAEF0"><p>Implement the serial port driver so that only the specified process can access it. For example, the driver might require that the client has a particular process ID. </p> </li> </ul> <p>Both of these solutions require an understanding of the serial port hardware and potential client software before the solutions can be implemented. For C32 Serial Server the device boot order is very important since it affects both solutions. </p> <p>The C32 Serial Server is started after Root Server starts. The Root Server and C32 startups are specified in each associated CMI file. They are started early in the boot process, but the serial ports might be ready for use by <codeph>RBusDevComm</codeph> at an earlier stage. If the strategy of guaranteeing port access is based on the client opening the port using the C32 Serial Server, then no other client can open a port using RBusDevComm before C32 starts. </p> <p>The C32 Serial Server loads plug-ins that act as high-level drivers for each serial port. You can implement any requirements for access within these plug-ins, such as requiring the client to have a specific process ID. This strategy only works within the C32 Serial Server, since any client using the serial port through <codeph>RBusDevComm</codeph> does not load the C32 Serial Server plug-in. </p> </section> </conbody><related-links><link href="GUID-FEB6F717-C86C-54A5-B8D1-B2D882C5AC55.dita"><linktext>What are CMI files?</linktext> </link> </related-links></concept>