Eminent Microsystems
Advanced Embedded Solutions
Turn-key project development
Our expertise and virtual component methodology delivers even the most complex application at a fraction of the cost.
Build the product you want instead of the product you end up with.               
ESF Serial Channel Protocols

 

The ESF Serial Channel Protocols provide reliable, high-performance full-duplex point-to-point packet transfer over any type of physical I/O channel. Through our custom proxy socket interface you can also network any legacy or new serial device without the need of an Ethernet controller or TCP/IP stack. The protocols offer a top transport layer that supports the specification and routing of packets to port endpoints. As shown below, a minimal Serial Datagram Protocol transport layer connects directly to a reliable Serial Link layer. The protocols use the same general framework used by the ESF TCP/IP protocols.

Serial Channel Protocol Layers

Serial Datagram Transport Protocol (SDP)
This is a barebones simple and efficient transport protocol designed for point-to-point packet transfer over some physical channel. The SDP socket is the interface to this transport protocol. This layer is also responsible for fragmenting and de-fragmenting large packets, i.e. packets larger than the maximum packet size supported by lower layer protocols. In the case of the serial link protocol, this is 2 kilobytes per packet.

Basic usage is to get an I/O port by creating a port object, and then binding a port number to it. E.g.

if( ((pPort = new(Timeout) SerialDatagram::Port) != NULL )
...
if( pPort->Bind(localPort, remotePort) )
...

If the remote port is unknown,
remotePort = Port::ANY;


The Table below shows the format for SDP packet headers.

Field

Number of Bytes

Definition
SRC PORT
2
Port Number of the local originating point of the packet
DST PORT
2
Port Number of the remote destination of the packet
FLAGS
2
One flag bit is presently defined,
FLAGS_FRAGMENT = 0x0001

SDP Packet Header Format & Definitions

Serial Link Protocol (SLP)
The Serial Link protocol layer is a high-performance, reliable protocol that marshals bytes flowing over the physical channel into packets and sends/receives these packets using a generic character device driver interface. Initialize this protocol with the appropriate particular type of physical channel device driver. The protocol supports:
• CRC packet error check.

• Full-duplex sequenced, windowed packet transfer (multiple outstanding unacknowledged packets allowed).

• Automatic retransmission of lost or damaged packets.

• Acknowledgement packet indicating successful receipt.

• Out of order packet handling.

• General callback if all error correction retry attempts fail, or a reset of the peer has been detected.

The general model for sending data is:
Allocate a network packet frame and workspace, e.g.
pFrame = new Frame();
Workspace *pWs = pFrame->Workspace.Push(sizeof(Workspace));

• Insert data into the frame and specify the packet type, e.g.
pFrame->Insert(pData, Length);
pWs->pktType = PACKET_TYPE_DATA;

• Send the frame
SendFrame(pWs);
To receive data, register a packet receive callback function using the protocol constructor.
The SLP protocol packet header format and definitions are listed in the table below.

Field
Number of Bytes
Definition
SYN 1 The first character is always a SYN (ASCII 026, or ^V). SYN may not appear anywhere else in the packet without an escape character. Any time a SYN is seen, a new packet will be assumed to have begun
PACKET TYPE 1 This byte contains a six bit Packet type code. The value is
0x40 + PACKET TYPE
LEN1
LEN2
2 These bytes contain a 12 bit logical length of the data section. The values of the length bytes are:
LEN1: 0x40 + ((len >> 6) & 0x3f)
LEN2: 0x40 + (len & 0x3f)
We always have (0 <= len <= 4095). Acknowledgement packets do not carry data, and must have a data length of 0.
SEQ 1 This byte contains the six bit sequence number of the packet. The value is
0x40 + (seq % 64)
An acknowledgment packet contains the sequence number of the packet being acknowledged. Data packets are transmitted in sequence There may be several outstanding unacknowledged data packets at a time. The sequence numbers are independent in each direction. If no acknowledgement is received within a timeout period the packet will be retransmitted. This has an unfortunate failure condition on a high-latency line, as a delayed acknowledgement may lead to a high number of duplicate packets. Packets are delivered in sequence order to higher level protocols.
DATA

<
40
96

The actual data bytes follow. The following characters are escaped inline with DLE (ASCII 020, or ^P):
SYN (026) DLE S
DLE (020) DLE D
^C (003) DLE C
^S (023) DLE s
^Q (021) DLE q
The additional DLE characters are not counted in the logical length stored in the LEN1 and LEN2 bytes.
CRC1
CRC2
CRC3
3 These bytes contain a 16 bit CRC of the complete contents of the packet excluding the SEQ byte and the CRC[123] bytes. The CRC is calculated with the following CCITT polynomial x^16+x^12+x^5+1.
The values of the CRC bytes are:
CRC1: 0x40 + ((crc >> 12) & 0x0f)
CRC2: 0x40 + ((crc >> 6) & 0x3f)
CRC3: 0x40 + (crc & 0x3f)

SLP Packet Header Format & Definitions

The protocol operational phases are:

• Send a CONNECT packet to the peer to inform him that you will commence sending packets. CONNECT in each direction is independent. (retryQ is initialized when the CONNECT is sent. outOfOrderPktQ is initialized when a connect is received).

• Wait for an ACK packet to confirm receipt of the CONNECT. Initialize unackedPktCount semaphore on receipt of this ACK).

• Commence sending data packets. The unackedPktCount semaphore throttles sending when MAX_UNACKED_PKT_COUNT has been reached.

Operational phases are managed using a separate state variable for packets going out (stateOut) and for packets coming in (stateIn) as shown in the figure below.

SLP Connection State Diagram

Thread Abstraction Library

The ESF Serial Channel Protocols include the ESF Thread Abstraction Library. This library acts as an operating system abstraction layer, where the real-time kernel interface provides the same multi-threaded service model for standard platforms and other real-time kernels. Supported environments currently include WIN32 and POSIX systems and several real-time kernels such as UCOS, VDK, ThreadX, or Integrity. Kernel base classes and modularity provide easy portability to new environments.