>> I have a buffer of "packed" "bytes" where each byte is less that
>> 8-bits in length.
>>
>> This buffer is generated by capturing a bitstream (LSB first) and
>> right shifting in to the LSB of a buffer.
>>
>> e.g. for bytes sized 7 bits, if the first byte is all ones, the second
>> is all zeros, and the third is all ones,
>> my buffer looks as such:
>>
>> 01111111
>> 11000000
>> xxx11111
>> xxxxxxxx
>> ...
>
> OK, I understand this is what happens, but I don't understand why. Why not
> have the receiving function put them in the right order from the getgo? Is
> it because you have no control over it?
>

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.

>> What I would like to do is break each "byte" out of the buffer and put
>> it into another buffer, e.g.
>>
>> 01111111
>> 00000000
>> 01111111
>> 0xxxxxxx
>> 0xxxxxxx
>> ...
>>
>>
>> I've started writing a function (in C) to do this, but I was wondering
>> if anyone had anything similar (no need for me to reinvent the wheel).
>
> They may exist, but I don't recall seeing one.
>
>
>> Ideally, I was going to create a generic C function that would take as
>> parameters the input and output buffer pointers, length of the input
>> buffer, the size of each "byte," and where to begin processing the
>> first byte (e.g. if the first bit of the first byte in the buffer was
>> not at the LSB position, but somewhere in the middle, ex: bit 3:
>> xxxx1xxx).
>
> YAGNI. I would write the function to solve the problem at hand, and not
> worry about making it generic until you actually need to.
>


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.

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