Sometime back, about a year back: Played with the rotary encoder with a TMR= 0 interrupt polling the encoder states. This method was eating away a lot of = the CPU timeshare. The CPU overhead was acceptable, when there was no workload. Things began to look different, when the workload increased, the decoded ou= tput was missing events and or producing incorrect states. This lead me to identifying that it was not the right method to be adapted in a higher workload situati= on. I have a few I2C peripherals in this situation. CPU workload is a bit high, since it has to do quite some amount of work handling the display itself, then comes= the real work itself. So, the definition of the best in this situation, I would think of lowest CPU usage (I am having CCP1 and CCP2 idle, hence thought about using them for this scenario) I am indeed not looking at the easiest way out here, In the meanw= hile it needs to be accurate too.. I guess the third method looks thus: http://hifiduino.wordpress.com/2010/10/20/rotaryencoder-hw-sw-no-debounce/ The issue out there is that I currently have the Encoder A and B pins on 2 different ports. I could move both of them to the same port, but then I would get an interrupt for either one of them. Or otherwise I would need to add some additional logic for generating IRQ's In your second case as well, it looks like both the Encoder ports need to b= e on one port (XOR) Wondering what would be the right thing to do .. Thanks for the various thoughts from you guys. My brain seems to have gone in an indefinite loop trying to identify the right thing to do. :-) Regards, Manu On Mon, Jun 10, 2013 at 6:38 AM, Denny Esterline wro= te: > "Best" is a matter of opinion and what you're trying to achieve. Easiest = is > usually to only use one of the interrupts and either increment or decreme= nt > based on the state of the non-interrupt pin. (interrupt when A channel go= es > high and increment if B is high, decrement if B is low) > Personally I'm fond of a different technique which results in higher > resolution. But it does require storing the previous state of the encoder > and interrupting on both rising and falling edges of both A and B channel= s. > After an interrupt, XOR previous B value with the current A value. > Increment or decrement based on the result. Don't forget to save the valu= e > for the next interrupt. > > A third technique is to concatenate the encoder bits and use it as the > index into a lookup table. Where the results of the lookup are +1, -1 or = 0 > that are then added to your counter variable. > > Good luck, > > -Denny > > > On Sun, Jun 9, 2013 at 3:43 PM, Manu Abraham wro= te: > >> Hi, >> >> What's the best way to decode a rotary encoder (gray code) output, >> when the outputs of the encoder are connected to edge detectors >> both of which result in an IRQ each ? >> (in a microcontroller, of course) >> >> (I have connected the decoder pins A&B to CCP1&2 of a PIC which >> result in 2 IRQ's (ie; CCP1 and CCP2) on each state change) >> >> >> Thanks, >> >> Manu >> -- >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=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 .