Ishaan Dalal wrote:
> I have a USART, say A, sending out a continous stream of data. I'd
> like my receiver USART, say B, to sync to this continous stream and
> receive data, but without B itself transmitting anything, USART or
> otherwise (ACK/NACK...).
>
> Other than using something like a training byte/preamble (e.g. 0xAA)
> every few bytes, what ways are there to do this?

There are many ways to address this and the best answer depends on a lot of
factors unique to your application.  Can the electrical connection itself be
considered reliable?  Do both ends initialize at the same time, like at
power up?  Must a receiver be able to sync to the middle of an arbitrary
stream?  How much of the serial bandwidth is really needed for the data?

I usually structure my host to/from PIC serial communication in the form of
command and response packets.  "Commands" are sent by the host, and
"responses" sent by the PIC, although they may not always be in direct
response to a command.

Each packet starts with an opcode byte followed by whatever data bytes might
be defined for that command/response.  Each receiver knows about all
possible packets it might receive, and stays in sync by knowing how many
data bytes follow each different opcode byte.  All undefined opcodes are
ignored.  At least one opcode is specifically reserved as NOP, which means
it has no data bytes and should be ignored.  0, 255, or both are good
choices for NOP opcodes because these are the most likely results of line
glitches.

This scheme can be easily arranged to have a known upper packet length
limit.  Each side can send out at least that many NOP opcodes on startup or
whenever resync is required.  This guarantees the other side will interpret
the next byte as an opcode.

If packets are only sent occasionally, I often define a packet timeout.
Within a packet, bytes must be sent in rapid succession.  If a receiver sees
more than a 100mS gap, for example, then the next byte must be interpreted
as an opcode.

If the connection is unreliable or a receiver must synchronize mid stream,
checksums and short packets can help.  To synchronize, a receiver buffers as
many bytes as can be in the longest packet.  It treats each new byte as a
potential start of packet until all conditions (valid opcode, valid
checksum, possibly timeout) are met for a complete packet.  The sender can
make this easier by sending NOP opcodes on occasion, or when it has nothing
else to send.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics