Dan Oelke wrote:

> Not to be disrespectful - but this looks like you just re-invented
> byte-stuffed HDLC.
>
> Punching HDLC and "byte stuffing" into google gets you a number of
> hits.  Apparently PPP uses a form of HDLC byte stuffing.
>
> I know data-link/network protocols really well, but I don't know the PIC
> USART very well.
>
> If you have byte synchronization from the port, then you can just use a
> byte stuffing scheme and as someone else said, just keep checking your
> check sequence.  If your CRC/checksum fails repeatedly (usually 3x in a
> row) then declare loss of frame and start hunting for a new start of frame.
>
> If you don't have byte synchronization then things get more interesting as
> you need to check for your start of frame flag, shift a *bit* then check
> again, and repeat.  Once you have start of frame found you just declare
> that as your byte boundary and read 8 bits at a time.  That's something
> usually easier done in hardware than software, but doable.
>
> That's probably more information than you need - especially since I gave
> two options not knowing enough about the PIC hardware in that area.....
>
> Dan

No offense taken Dan.

I read the original post as meaning synchronising data not the bit stream - as
in sending groups of binary data bytes (maybe floating point or long integer) as
a stream. Without knowing a lot more about the data being sent it just struck me
that this was the simplest way to inject markers into binary data. I was
actually borrowing from HDLC rather than trying to re-invent it :-)

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads