View previous topic :: View next topic |
Author |
Message |
MO
Joined: 07 Nov 2008 Posts: 4
|
unique start and end characters for serial packet? |
Posted: Mon Sep 07, 2009 2:51 pm |
|
|
Hallo,
I'm sure I have seen this discussed in a topic before, but cannot find it again?
How can I ensure that the serial data packet's start and end characters are unique?
For example if I choose to use the CR for the start char that would be 0x0D and I cannot ensure that one of my data bytes will not have this value.
Is there a better way of encoding my data? At the moment I send bytes, some with the posibility of being anything from 0x00 to 0xFF.
Or should I stop looking for the start and end chars while(Length)?
Structure in bytes:
<start char><Sender's ID><Receiver's ID><Function><Length><data bytes up to Length><CRC><CRC><end char>
Thank you for the suggestions!
Regards,
Madri |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Sep 07, 2009 3:00 pm |
|
|
Quote: |
For example if I choose to use the CR for the start char that would be
0x0D and I cannot ensure that one of my data bytes will not have this
value. |
It will if you send ASCII bytes. It's very easy to have message
delimiters if you use ASCII. For example, NEMA-0183 messages start
with a '$' character and end with CR LF characters. |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Mon Sep 07, 2009 3:21 pm |
|
|
fixed length blocks and handshaking can do what you want also
if this is between one of multiple - smart addressable nodes
and ultra hi thuput is not required there are several ways
you can create a means of sending fixed length blocks
a sequence might be:
** if error or startup ( nosync) THEN host waits for agreed timeout ( idle duration - like sending "break" but no char xmitted )
**host sends fixed length <0xC55C><nodeid><checksum> TO ALL nodes
** the addressed node answers with <0x5cc5><nodeid><checksum>
** host sends fixed length packet as you describe it - but NO cr or start char required - as the LENGTH must be met and CRC satisfied - right ?
** adressed node replies with <0x5cc5><nodeid><crc_echo_of packet>
OR <0x5cc4><nodeid><crc_echo_of packet> // FAILED header
( repeat of packet can now be done - OR wait timeout interval and start new sequence)
** packet exchange complete - channel idle again
you can implement various recovery routines , but that is the essence
of a method i've used before between pics and PC's in a distributed RS-422( quasi 485 with TX build out resistors for sharing the TX pair ) 4 wire net in the past . at speeds of 19200 over 100 feet or more - no problem.
not the fastest way to do it - but deterministic and pretty failure resistant |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Mon Sep 07, 2009 3:34 pm |
|
|
It's very simple. With binary transmissions and 8-bit character frame, control characters can't be unique unless you add specific elements, particularly escape characters. This is done in many serial protocols, e.g. PPP or various industrial communication protocols. Fixed frames and CRC allow a reliable rejection of bad packets, but resynchronisation may be an issue. If not using escape characters, a transmission idle time is the most common means for resynchronisation. |
|
|
Wayne_
Joined: 10 Oct 2007 Posts: 681
|
|
Posted: Tue Sep 08, 2009 2:09 am |
|
|
Just use an escape char, for instance 0x1B (ESC) then when you actually want to transmit the start or end char as part of the data you place the escape char just before it. But, in order to actually send the escape char you must send it twice.
You receiver then knows that when it sees the escape char that the next char is an actual data value and not the start, end or escape char.
So:-
0x0D 0x01 0x1B 0x1B 0x02 0x1B 0x0D 0x1B 0xFF 0xFF
Would be
(start)0x0D 0x01 0x1B 0x02 0x0D 0xFF (end)0xFF |
|
|
|