RussellMc wrote:
> Any comments on "escape sequences" / Syncing etc?.
>
> If things never got lost and Murphy had died they might almost not be
> needed :-).
> But in real world use you are going to sync in some manner.
> Conceivably as "raw" and simple as a single escape sequence that
> otherwise lets the sender and receiver decide what to make of what's
> on the channel. Possibly packets with known preamble and word count
> and checksum/CRC or whatever. Proceeding upwards in complexity until
> you arrive at X25 or more (obviously not in the context mentioned
> here).
> What do you do and why? [ "You" there is notionally Olin, but there
> are liable to be a range of preferences and reasons].

This is rarely the problem you make it out to be.  Almost always, I send
commands starting with a opcode byte and followed by data bytes dependent o=
n
the opcode.  This does mean both ends need to understand the command set
else they will get out of sync.  However, this is no different from any of =
a
100 other things that have to be right else they are bugs.  Usually you tes=
t
each command and response (I call these same packets coming from the small
system to the host "responses" as apposed to "commands", although they may
not all be in direct response to commands) individually right after having
written the code.  Once it works, it's going to stay working.  There is
really very little problem with this in practise.

That's doesn't mean I always totally ignore the problem though.  Very simpl=
e
things you can do is to make 0 and 255 unused opcodes or specifically defin=
e
them as NULL opcodes.  That means each end can tolerate any number of 0s or
255s without problem.  Most unwanted bytes due to startup or whatever will
be 0 or 255.

Sometimes I have deliberately used this to sync on startup.  The embedded
system may send out 16 NULLs on startup, knowing that the longest possible
response totals less than 16 bytes, for example.  If in doubt, send 256 0
bytes on startup.  Startup time is rarely a issue.

Another trick that I have used occasionally is to add a timeout.  If nothin=
g
has been received for 100mS, for example, then the current packet will be
aborted and the next received byte interpreted as a opcode.  This means tha=
t
any command or response needs to be sent without a 100mS gap anywhere
between its bytes, but that usually happens anyway such that it would be
work to prevent it.  Even on a PC with a desktop operating system, the app
would generally be stuffing a command into its own buffer, then pass the
whole buffer to the OS to send.  The app might get interrupted for more tha=
n
100mS while stuffing the buffer, but once the low level driver deep in the
OS gets the buffer, it's going to get chugged out the serial line without
gaps.

In a few cases I did have to implement a packet protocol with checksums,
ACK, etc, for the reasons you cited.  This has been quite rare though.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.