I have found it best in almost all cases to send data values in ascii decimal terminated with a CR character (13). You can monitor this with any termial program to confirm that the data is tansmitted properly.
What advantage do you intend to gain from the SNAP protocol?
THat is ok for small time work and debug outputs, but unfortunately it does not work well when you want reliable error free comms, unless the ascii you are sending contains, or is layered on some form of error detection.
Question: How are the frames delimited in SNAP? What I mean is: when I start listening to an ongoing SNAP transmission, how do I know when a frame is finished and when a new one begins? The sync byte can also be present in the data stream and there is nothing defined in terms of escape characters or guard times around frames. So I have now way of knowing when if a received sync byte is really a sync byte or just a part of the transmitted payload. Considering all this, I think SNAP sucks.
I would go for a simple SLIP-like protocol where start/end bytes are defined and where similar bytes in the payload have to be escaped.
I don't know, I have never looked at the SNAP protocol. I assume that it has a len field, and based on that you can find the crc and subsequently validate.
I agree. The bonus about escaping and data that shares the same start sequence is that synchronization becomes much faster.
Most protocols I have ever designed have been loosley based on HDLC / DDCMP. Thats only because it is what I have used and grown used too.
It does have a length field, but if I missed that, and "drop in" in the middle of a packet, how do I know it's finished?
Indeed. The code for this is very straightforward. Heck, I'll include it here and now. This is C code written on a Philips XA, so a few bits a registers must be adapted to the OP's processor. This is the low level link protocol which provides framing of a binary packet. Add your flow control and CRC to suit your needs. Below is the complete description and source code.
Meindert
------------------------------------- Link protocol The reader uses a link protocol to communicate with the host. This link protocol provides a transparant 8 bit serial link for binary data. The link protocol defines frames of a fixed or variable length which are framed by START and END markers.
The link protocol is derived from the SLIP protocol according to RFC-1055 and slightly modified. Three special link control bytes are defined to uniquely frame a packet of data:
ESC (0xFF): This byte is inserted in the serial stream immediately before a data byte identical to one of the three link control bytes. START (0xFE): This byte marks the start of a frame. END (0xFD): This byte marks the end of a frame.
The link protocol only provides framing of binary data. There is no error handling or checksum. Both parties shall ignore a frame in case of a timeout between bytes or START and END.
Implications for the transmitter The choice of the values of the control bytes is such that no testing is required on the presence of all three if them in the datastream. A simple test whether a byte is greater then or equal to 0xFD is sufficient. When the byte to be transmitted is lower, it can be transmitted immediately. When equal or greater, an ESC is inserted in the datastream.
Implications for the receiver When and ESC is received, the next byte will always be regarded as data and not as link control byte. When a START or END is received without an ESC, they will be regarded as start or end markers. The advantage of having separate START and END markers is that on reception of a START, all previously received bytes can be regarded as noise and therefore discarded. Unlike SLIP, which uses only one marker for both the start and end of a frame, in which case the receiver always has to check the validity of the previously received bytes.
Code example (this is production code, which has proved to work) Reception is done in rx_int() and send() and recv() are called to send and receive frames.
**/ /*
*/ /* init_comm(): Initialise serial driver to desired speed.
*/ /*
*/ /* The baudrate generator is T2, which is initialised in the
*/ /* timer module.
*/ /*
*/ /***************************************************************************
**/ void init_comm(void) { // serial port configuration S0STAT = 0; // clear serial status, no interrupts on events S0CON = 0; SM1_0 = 1; // set 8 bit UART with variable speed REN_0 = 1; // enable reception TI_0 = 1; // 'enable' transmission
**/ /*
*/ /* recv(): Check if a packet is received. Returns a pointer to a packet when
*/ /* data is received, nil if not.
*/ /*
*/ /***************************************************************************
**/ PACKET *recv(void) { if (rx_state == S_RDY) { rx_state = S_IDLE; return &packet; } else return 0; }
First of all, SNAP is a network protocol, what you seem to be asking for is a point to point protocol.
For the actual coding level, I like to use plain old asynchonous serial using UARTS already in most micros today. Then it just depends on how important it is to detect errors in transmission. The ascii/decimal is fine if occasional errors going undetected are not an issure in your specific use.
Since you are specifying only one-way transmission, error correction is cumbersome, but error detection is quite easy. Send your 10 bit number as decimal ascii, send a comma, then invert all of the original 10 bits and send that as decimal ascii with a CR character to end it.
This slows down the theoretical data transmission rate by a factor of 4 or 5. If that is not an issue, its a clean and easy way to send the data.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.