PicDude wrote:
> I intend to read a proprietary serial data stream from another
> product into
> a spare PortA pin on a 16F pic.  Currently 8Mhz internal osc, but the
> PCB is
> setup for a 3-pin resonator (20Mhz or other) resonator if necessary.
>
> Essentially there is a relatively long idle period, followed by over
> 70
> sequential data bits which are around 400ms long each, and at approx
> 1%
> timing error from the sender.

Obviously this can't work.  Just from the sender's clock error alone you are
off by .7 bits in the middle of the last bit, with .5 bit time error being
the guaranteed to fail limit.  Any error in the receiving process adds to
this.  Either you got the specs wrong or some idiot designed a protocol that
can't be correctly received regardless of how much cleverness is applied in
the receiver.  If this is really NRZ encoding and the sender could send all
bits the same value, then you're screwed.

You can resync your clock on bit transitions, assuming these happen once
between bits and the bits are the same length.  Even though bit value
changes may not be guarantee within a particular time, you can still make
use of them when they do occur, and most likely they will occur often enough
in practise.

The easiest thing is to set up periodic interrupt and sample the input
signal there.  Fortunately your bit rate is very slow, so this interrupt
could every 10mS or more.  Even something as slow as 10mS still gives you 40
samples/bit.

Obviosly you watch for the start bit and start timing there, but you also
watch for transitions on the line and reset the clock to the middle between
two bits when you find one.  That resets any accumulated clock drift between
the sender and receiver on every bit value change.  The problem is that
these are not guaranteed to occur unless you haven't told us everything.

For extra credit, you not only reset the clock on input line transitions,
but also adjust your conception of a bit time a little.  After a few
messages, your PIC will have been trained on that sender, and subsequent
messages will work better, even with long sequences of the same bit value.

A easy way to do this is to keep a number that indicates how many samples
there are per bit.  This trick is to make this fixed point and keep some
fraction bits, like 8.  This allows making small changes in your assumed bit
period when edges are found.  I would adjust the bit period slowly, probably
by low pass filtering any new value into the in-use value with a couple of
poles and a low filter fraction.  The error between the sender's clock and
your clock shouldn't change much, and should change slowly when it does.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist