At 10:23 PM 12/02/97 -0800, you wrote:
>John Payson is right. As long as only one bit jitters back and forth, you
>don't need to test the two encoder lines any faster than the maximum count
>rate you expect. The count is only jittering back and forth between the
>same two numbers, and if you miss some of the jitter, you don't miss any
>real counts, because the count is always accurate when you sample the pins.
>
>If the jitter involves both bits, then you have a problem, but in that case
>I would suggest that the mechanical aspect of your device needs to be
>looked at(backlash or slop reduction), or you need to sample the encoder
>faster than the physical limits of the system.

The whole point in my original response to the first thread was:-

        Interrupt prcoessing using the MC68705P3 was ideal since we could
        generate the actual inc or dec instruction direct from the output
        of the decoder chip which read the phases A and B.

This approach was ideal in that it allowed several other operations, the
control/display routines only had to check a register and not sample the pins,
the software complexity was reduced and the allowed input frequency could be
much higher than a conventional software approach - such as used on the PICs.

Prior to the interrupt trick we finally used, we went through the whole arena
of issues covered here and determined that (then) a software approach of just
sampling the pins was far too slow and limited flexibility - we could not
readily perform other tasks. Anyway all this was solved by the interrupt trick.

In fact I'm dissapointed that a lot of the tricks we did with the 68705 series
cannot be done on the PIC - such  as generating an instruction on a port and
branching into RAM to execute a modified table access/search etc.

Rgds

Mike