Ohhhhhh...you want to do something else besides Comms ?? Hmmmmmmmm....
Oops, add another one to the assumption list!

I was planning on synching my processing to the comms:
1.  wait to receive a byte
2.  do processing stuff
3.  goto 1

I think this loop should take between 2/4 cycles (3-5 cycles before
the TMR0 is cleared.

waitStart:
      btfss    PIN_RX
      goto     waitStart
      clr      TMR0

which is executed by the PIC as:
      btfss
      goto
      nop
      btfss

If the start bit is received 1 nano-second after the btfss samples the
pin, the processor executes 4 full instructions (plus the last cycle of
the btfss instruction) as follows:
      goto
      nop
      btfss
      nop

However, this 'missed' timing is also compensated by the fact that we
have the same 'miss' overhead when polling for the end of the start bit.

Best case, the "start" of the start bit and the "end" of the start bit
occur at exactly the same point in both polling loops. TMR0 is then the
actual time of the bit (minus the TMR0 2 cycle reload).

Worst case, the "start" of the start bit is sampled when it occurs and
the "end" of the start bit occurs right after the pin is sampled.  Now
we are setting TMR0 off by 2...with averaging this should not be a
problem...

Similiar analysis of the data bit polling is left as an exercise to the
reader :-)

Hope I haven't missed anything...Enjoy,

Ralph

Geeze, where's my samples...I can't wait to try this....Maybe I'll just
call Digi-key and get some in, of course, then I'll have to get my hands
dirty and enter the real world.  It's so comfy here in the simulator
world...


J Nagy wrote:
>
> >
> >>2.  First bit sent (bit0) is a 'one' which is used to
> >>    allow us to time the start bit pulse width
> >>3.  Transmitters and receivers may vary over time/temperature
> >>    so we do synchronization on every byte
> >
> >It's a good idea.  It should work at any speed since the error is a
> >percentage.  But at higher speeds, the precision with which the start bit
> >can be measured and the speed adjusted is less.
> >
>
>         The one thing I've run into, though is the 'latency' in detecting
> the start bit. Since the '508 has no capture or interrupt modes, you have
> to poll really rapidly while doing your other (main?) function. Even a
> tight loop can take as much as 10uS to detect a start condition. This error
> is relatively constant, and limits your highest data rate.
>
>         Jim Nagy
>         Elm Electronics
> Makers of unique integrated circuits
> http://www.elmelectronics.com/