Architecture

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.

Historical Notes

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.
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:
1. A serial protocol module +which blocks does not stop other Serial Protocol Modules from running
2. A serial protocol module +can run faster than other modules by changing the configured thread priority
3. A serial protocol module +can use the Serial Communications Server API and request services of another +serial protocol module