Ray wrote:
> that means you need to do interrupt on edge (plus & minus) of both
> channels.

No, you don't.  That's merely one way to let the firmware notice input line
changes.  The problem with this method is that you can sometimes get lots of
bounces between adjacent states.  If decoded properly, these don't really
cause a problem, but can monopolize the CPU if using edge interrupts.

Usually a periodic interrupt is better, depending on the max speed you need
to track the encoder motion over, and what the encoder is rated for.  Let's
say for example you're decoding some sort of user input knob with 32 detents
per turn.  Turning this thing makes some value go relative up and down that
the human observes and adjusts the knob accordingly.  If the user is turning
the knob at 1 sec per revolution, he's obviously not counting detents and
just wants the value to change quickly.  If you miss a few, no big deal.
The user won't be able to notice whether it went up 30 or 32, just that it
went up "a lot", and he'll turn it more slowly when he gets closer to where
he really wants the value.

1 turn/second --> 32 detents --> 128 quadrature states --> 8ms per state.
So a simple 1ms periodic interrupt will catch every state just fine much
faster than any reasonable user turning speed.  There is no need for the
firmware to see all the bounces between adjacent states as long as it sees
all real state transitions.  For most PICs at reasonable speeds, sampling
the quadrature lines in a 1ms periodic interrupt and doing the 4x decoding
will take a small fraction of the CPU time, regardless of how fast the knob
is moved or how much it bounces between states.


********************************************************************
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