Quote:
Originally Posted by Phalanx
If you use "Kevin Watson's" encoder code, the caveat is (as I understand it) that if the encoder is spinning at a high enough rate of speed it is possible for his routines to incorrectly interpret the direction and thereby mis count.
|
Actually, this has little to do with my code. The problems really are interrupt latency and line capacitance. The latency is due to having to manually save a lot of contextual informaton before the actual ISR gets to execute (this much less of a problem with the 3.1 compiler). Capacitance is a problem because encoders generally have fairly weak drive capabilities, which makes it hard for them to drive the capacitance of the cabling and that 0.01uF capacitor IFI hangs off of the upper twelve digital inputs. This has the effect delaying the arrival of the phase b logic state to the PIC. I haven't done the calculation, but I imagine if you spin an encoder fast enough, the phase b signal will never settle to a valid logic voltage level because it spends all of its time transitioning between the two! I'm not sure which is the dominant effect, but I do know that the flip-flop solution mentioned in the FAQ goes a long way to negating these effects because it captures the state of phase b before it can transition to the other state and it provides much more drive current to drive the line capacitance. I should point out that the flip-flop should only be used with interrupts 1 and 2 of my code as it will cause ploblems with ISRs that use a state machine to track the encoder state, like the upper four inputs of my code or Dan's code that you mentioned. In these cases, a good alternative to the flip-flop is a 74xxx244 line driver, where xxx can be ACT, LS, etc.
-"Kevin"