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