Architecture

This topic describes the architecture of the Serial Communications Server.

The Serial Communications Server uses the Symbian platform client/server framework. Clients use R 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 Serial Protocol Modules or CSYs. 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.

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 RBusDevComm. The RBusDevComm 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.

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 RComm::Open() and RComm::OpenWithAvailable() 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.