The problem in that approach is that the microcontroller that I am using at present doesn't have a QEI module in it. For that reason, need to handle it in software itself. Regards, Manu On Mon, Jun 10, 2013 at 2:30 PM, Ariel Rocholl wrote: > The best way is to let the QEI module do it for you. It is very robust an= d > predictable, does all the debouncing, and there is no need for interrupt. > > If you have the freedom to select the PIC you need for the task, then > select one with QEI, it will keep a counter updated with no CPU cycles > consumed. > > Ariel Rocholl > http://www.rf-explorer.com > > > On Mon, Jun 10, 2013 at 7:36 AM, Manu Abraham wro= te: > >> Sometime back, about a year back: Played with the rotary encoder with a >> TMR0 >> 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 worklo= ad. >> Things began to look different, when the workload increased, the decoded >> output >> 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 >> situation. >> >> 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 >> meanwhile >> it needs to be accurate too.. >> >> I guess the third method looks thus: >> http://hifiduino.wordpress.com/2010/10/20/rotaryencoder-hw-sw-no-debounc= e/ >> >> 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 so= me >> additional logic for generating IRQ's >> >> In your second case as well, it looks like both the Encoder ports need t= o >> be 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 go= ne >> 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 >> wrote: >> > "Best" is a matter of opinion and what you're trying to achieve. Easie= st >> is >> > usually to only use one of the interrupts and either increment or >> decrement >> > based on the state of the non-interrupt pin. (interrupt when A channel >> goes >> > 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 enco= der >> > and interrupting on both rising and falling edges of both A and B >> channels. >> > 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 >> value >> > 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 >> wrote: >> > >> >> 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 >> -- >> 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 .