Scott wrote:
> The bitstream may not be in the right direction, i.e. I either receive
> it forwards or backwards, and have to do some processing to determine
> this. Also, I receive different bitstreams with different sized
> "bytes," so I want a generic solution.
> I need to look for a "start byte" at either end of the stream, and
> that start byte may be corrupted, so i need to calculate parity on
> each byte, or what I think a byte is. Once I get, say, three positive
> parity checks in a row, I have found my data and process the
> remainder. It's a lossy stream, but I'd like to pull as much valid
> data out of it as I can. Because of this, I decided to have a "start"
> bit that could be somewhere in the middle of the stream, so that I can
> "unpack" bytes from anywhere - basically shift the stream and get rid
> of the first X bits until I find some bytes that pass the parity
> check.

You want to give us a hint as to what the application is? :)


> After thinking about it for a while and driving home, a solution came
> to me. Use "bit pointers."
> I basically use bitmasks to determine what bits are set, then set the
> bits in the "unpacked" buffer. I made it generic for any sized "bytes"
> from 1 bit to 7 bits and implemented the "start bit" that could occur
> somewhere in the middle of a byte.
>
> Initial testing shows it works pretty well. Sometimes all you need is
> a drive to clear your mind.

I prefer showers myself, but that's besides the point.. Where's the code? ;)

VItaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist