| ??? 06/24/08 05:31 Read: times |
#156141 - I Agree Responding to: ???'s previous message |
I agree. Depending on the hardware, if the encoder stops at just the right spot, one of the inputs can "fizz" back and forth much faster than the firmware can possibly deal with it. I've handled this problem in the past by setting things up so that once a state change has been detected on either input, the firmware simply ignores that input until the other one changes state.
Here's what I'm talking about in flowchart form, assuming that you're polling the encoder periodically, maybe from within a timer interrupt routine.  Similar logic works if the encoder itself generates interrupts when it changes state. The exact implementation would depend on whether there was a single interrupt for all state changes, or separate interrupts for changes on the two input lines, or ... -- Russ |
| Topic | Author | Date |
| Help interfacing a home made rotary encoder | 01/01/70 00:00 | |
| use wheele mouse parts | 01/01/70 00:00 | |
| use a timer interrupt... | 01/01/70 00:00 | |
| Add hysteresis | 01/01/70 00:00 | |
| comparitor | 01/01/70 00:00 | |
| Why I'm not a novelist | 01/01/70 00:00 | |
| Noob! | 01/01/70 00:00 | |
| Start like this | 01/01/70 00:00 | |
| I think I can barely understand... | 01/01/70 00:00 | |
| PCB | 01/01/70 00:00 | |
| Results | 01/01/70 00:00 | |
| ABOUT THE ROTARY INCODER | 01/01/70 00:00 | |
| Stop shouting, will you? | 01/01/70 00:00 | |
| Software comment | 01/01/70 00:00 | |
| I Agree | 01/01/70 00:00 | |
| Thanks | 01/01/70 00:00 | |
| Yes, it does | 01/01/70 00:00 | |
| incorrect | 01/01/70 00:00 | |
| Incorrect | 01/01/70 00:00 | |
| Clarifying | 01/01/70 00:00 | |
| Time between polls | 01/01/70 00:00 | |
| here we go again | 01/01/70 00:00 | |
| Mmmh... | 01/01/70 00:00 | |
| I give up | 01/01/70 00:00 | |
| Previosly commented | 01/01/70 00:00 | |
| and contradicted | 01/01/70 00:00 | |
Picture | 01/01/70 00:00 |