The issue of an encoder sitting at a transition should not be a problem. The way to handle this is to require that counting always occurs on alternating channels. So if the last count was (say) up on channel A, then a transition back on channel A is ignored. If the encoder continues moving in that direction, the next count will be down, but it will be caused by the transition on channel B. This means that there is built in hysteresis of one transition (on a 500 line encoder, this is one 2000th of a revolution).

On an AVR (the ATmega16 is my current processor of choice because I already use them), it is a simple matter of disabling the interrupt on the last channel that it occurred on. So on an A interrupt, disable A and enable B. On a B interrupt, disable B and enable A.


I've written some prototype code and it appears that it will less than 4 usec to handle each interrupt on an ATmega16 running at 20 MHz. It's 53 words of code for each interrupt. Not all of it will need to execute. When I have some time, I'll try to get a better figure.

An encoder with 2000 transitions per revolution will take around 8msec per revolution. At 3600 rpm (60 revs per second), it will use about half of the processor cycles when running at full speed. -- But note, that other code had better not disable interrupts for more that around 4 usec.

Ken