This topic gives a summary of the APIs that must be implemented for a new Serial Protocol Module.
The flexibility of the Comms Architecture allows a Serial protocol module to use the Socket API to use a protocol stack and the protocol stack then uses the Serial Communications Server API ( RCommServ and RComm APIs) to use a serial protocol. In some cases this re-entrant configuration causes a deadlock.
A Serial protocol module can avoid deadlock when the following conditions are met:
The serial protocol module never uses code which causes an RComm request on the same serial protocol module
The serial protocol module must be in a different thread to the other serial protocol module.
Other tips:
Always call RSocketServ::StartProtocol() which is asynchronous before calling RSocket::Open() which is synchronous, but may cause an RComm class to be instantiated.
The Serial protocol module must correctly implement the CPort::Destruct() function. A standard C++ destructor must run synchronously, so CPort::Destruct() allows the Serial protocol module to complete asynchronous operations during the close of the port. For example, a Serial protocol module that needs to close an RComm object must do this asynchronously.