The ERSP - Euresys Remote Serial Protocol
ERSP (Euresys Remote Serial Protocol) is a wrapper protocol above TCP/IP that allows the transparent delivery of binary commands to serial devices over RS-232 and RS-485 connectors and the retrieval of the serial devices replies.
|
●
|
One ERSP server instance binds one TCP port with one serial connector. It allows exactly one client session before terminating. |
|
●
|
The current protocol version is 1. |
|
●
|
A sample client for this protocol is available in python 2.x language in the remoteSerial folder of the sample programs. |
Header structure
The commands and the replies use 4-byte headers structured as follow:
| command code |
options |
size (MSB) |
size (LSB) |
|
A command or reply can carry payload in addition to that header, in which case the size of the payload is stored in the two size fields.
Command Codes
To ease protocol supervision, command codes are ASCII letters.
| A |
ACKnowledge reply |
N |
sometimes |
| A |
AUTHorized |
Y |
N |
| E |
ERRor reply |
Y |
sometimes |
| G |
GET request |
N |
sometimes |
| H |
HELLO message |
Y |
Y |
| S |
SEND request |
N |
Y |
| W |
WAIT request |
Y |
N |
| Z |
ZAP request |
Y |
N |
|
Authentication
|
●
|
A client sends a {HELLO, opt=<client version number>, data=<authentication code>} message. |
|
●
|
A malformed hello message or invalid authentication codes terminate the connection but the server keeps running. |
|
●
|
The server replies with {AUTH, opt=<server version number>, size=0}. |
The current protocol version is 1, which is encoded as a V.
Data transfers
|
●
|
{SEND,size=N, data=<N bytes of raw data>} |
|
□
|
Request delivery of up to 65535 bytes of data over the serial line |
|
□
|
Replied with {ACK,size=0} or {ERR, opt=error pointer} |
|
□
|
Request discarding of all received bytes so far |
|
□
|
Replied with {ACK, size=0} |
|
□
|
Request read of up to 65535 bytes of data over the serial line |
|
□
|
Can return bytes buffered before the command was issued |
|
□
|
Replies {ACK, size=N, data=<N bytes of raw data>} on success |
|
□
|
Replies {ERR, opt=3, size=M, data=<M bytes of raw data} if retrieval timed out after M < N bytes |
Synchronization commands
|
●
|
{WAIT, opt=synchronization byte} |
|
□
|
Request discarding of all incoming bytes unless the synchronization byte is received |
|
□
|
The synchronization byte is still returned in the next GET request |
|
□
|
Replies {ACK, size=0} if the synchronization byte was found |
|
□
|
Replies {ERR, opt=1} if no synchronization byte was found when the reading timeout expired |
|
□
|
Replies {ERR, opt=4} if other I/O errors occurred while waiting for the synchronization byte |
|
●
|
{ZAP, opt=<byte to discard>} |
|
□
|
Request discarding of 0 or more bytes of a specific value |
|
□
|
Replies {ACK, size=0} if a byte of a value different than the byte to discard was found |
|
□
|
Replies {ERR, opt=1} if no byte different than the byte to discard was found when the reading timeout expired |
|
□
|
Replies {ERR, opt=4} if other I/O errors occurred while waiting for the synchronization byte |
Error replies
|
●
|
The options byte of the ERR message header indicates the offending byte in the corresponding request. |
For example:
|
□
|
opt=0 indicates an invalid command. |
|
□
|
opt=1 indicates an invalid option for a command. |
|
□
|
opt=2 indicates an excessive amount of data. |
|
□
|
opt=3 indicates an insufficient amount of data. |
|
●
|
The error messages can carry an additional error string for human debuggers. In such a case the size of the string is stored in size. |
|
□
|
A timeout while reading is the only non-fatal error in protocol version 1. |
|
□
|
All other errors will close the connection as soon as the error message is sent. |
