Andrew Warren <PICLIST@MITVMA.MIT.EDU> wrote:
> Arrays of bits (and/or pointers to bits) are VERY commonly used in PIC
> applications;

James Musselman <james@RADIXGROUP.COM> replied:
> As long as we are all PICking this apart-
> How do you know this?

Arrays of bits are certainly commonly used in *my* PIC programs.  I often
have to sample an input signal at a very high rate for a short interval,
such that I can't do any processing on the fly.  I preinitialize an array
of bits to zero, then use a sequence like:
        btfsc   inport,inbit
        bsf     buffer+0,0
        btfsc   inport,inbit
        bsf     buffer+0,1
        [...]
        btfsc   inport,inbit
        bsf     buffer+0,7
        btfsc   inport,inbit
        bsf     buffer+1,0
        [...]

For example, I use this in my closed-caption decoder to acquire the line 21
data stream:
        http://www.brouhaha.com/~eric/pic/caption.html

While I wouldn't expect a compiler to generate the code above to acquire
the data, it would be nice if a compiler (either non-C, or C with a
non-standard extension) allowed arrays of bits so that I could easily
do the initialization and (later) the processing of the aquired data in
a high-level language.  As it is now, I use a subroutine which extracts
one sequential bit from the buffer on each call, maintaining a byte pointer
and a bit mask in two RAM locations.

I am now using the same technique for a SMPTE VITC reader, however since the
data rate is much higher I am using a 74HC4046 PLL to sync the PIC clock
to a multiple of the horizontal sync rate such that each sample is guaranteed
to be exactly one bit of the time code.  However, I haven't yet determined
whether in practice the time code really remains phase synchronous to the
hsync, so I'm not sure whether my current design is a workable product.

Cheers,
Eric