There's a few different ways to handle encoders and (as usual) "best" is dependent on what you're trying to do with it. For servo motor drives and measurement of real world stuff, you generally want to do a full 4x decode and get as much resolution as possible. For less demanding applications (human interface is a good example) you can usually get by with the simpler implementation. The "best" 4x decode I've worked with uses 2 interrupt on change pins on the A and B lines. On each interrupt you exclusive-OR the _previous_ A value with the current B value, increment if it's a one, decrement otherwise. Then capture the _current_ A value for the next comparison. Very low overhead, tolerant of real world noise, etc. The problem is running multiples in one PIC. You have to get very creative to keep track of which encoder generated the interrupt and even more creative to make sure you don't miss a change on one encoder while you're servicing another. With a bit of creativity it may be possible to "bend" the input capture interrupt(s) to achieve the same end. If you can deal with the inherent latency, it may be a good choice to use a small (perhaps a 10F) PIC that only monitors one encoder and behaves as a slave node. Plenty of low-overhead simple serial protocols that would be suitable here. Interrupt driven, even a relatively slow processor can handle surprisingly fast encoder data. I can see that working such that you could reliably handle 40kHz+ encoder rates if you can live with 50Hz or less data update rate. There are trade-offs you could play with to get that higher, but in practical terms, it's hard to get any serial slave node to update more than a few kHz. (and even if you did, what would you do with that much data?) Others have mentioned a faster processor and polling for the data. I've tried this before and been very disappointed. Even with low-resolution hand turned encoders, I was able to generate skips and misses. For front-panel human interface things, that may be acceptable. For physical feedback systems, no. Most of my recent work has been done with the more capable dsPIC33 family of parts. Some of them have two QEI interfaces (hardware encoder module), with that, multiple CN pins and the IC, you could probably manage it, but it'd be messy. -Denny On Mon, Dec 23, 2013 at 3:02 AM, CDB wrote: > I've been asked if I can conjure up a device that will allow 6 increment= al > rotary encoders and 10 ADC inputs. I suspect this is for some sort of > gaming doodad. > --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .