| ??? 01/04/01 16:49 Read: times |
#7756 - RE: Keypad interfacing revisited... |
Lance Robinson wrote:
------------------------------- There is still a problem related to debounce. If you get an interrupt on the leading edge of a bounce, you still may read the signal at the wrong time and miss the key for that interrupt. - - - - - - - - - - - - - - - - I recommend you use the external interrupt only as a trigger to focus attention on the keypad. When the external interrupt fires, my routine would disable that interrupt and proceed to setup a keypad interrupt routine triggered repeatedly by an internal timer. The keypad routine can be associated with a reserved timer or can be a threaded task if you are using a bockground tasker (for the advanced). You needn't even read the keypad on that external interrupt. Think of it as an attention getter only. As you load the keypad routine interrupt timer, you can initially set it to trigger quickly if you're worried about missing data (not necessary considering bounce). You also preload a few counters and variables for the keypad routine. Lets say you shut down the external interrupt and load the keypad reserved timer for 10ms. You have a reserved interrupt vector pointing to the keypad routine. 10ms later the timer triggers an interrupt and you start keypad routine. At the end of this routine you'll look at counters and decide whether you setup for another 10ms timer interrupt, whether you have finish successfully or not inwhich case you will pass on results and enable the external keypad interrupt once more instead of the keypad timer. Within the keypad routine you have several choices for debounce. I prefer the resettable press detect count method. Herein you read the keypad, if you see nothing you reset the counter for how many times you've seen the key held and maybe bump the seen-nothing counter to trigger a limit exit if you want. If you read a keystroke, compare it to the last keystroke read and iff the same, increment the keypress counter... if not the same, initialize that counter and update the key. Next test whether the keypress counter has counted long enough (counting down to zero is more efficient) or whether the nothing-seen count has likewise terminated. Make your exit decisions upon those. If you've seen the same keypress 60ms, then its time to declare that a valid keypress and load it into a foreground RAM interface, ie load key byte and set keypad read flag for foreground. If nothing has been seen, don't report a keystroke to foreground. If either of these intervals complete, avoid to reinitial the 10ms counter and instead enable the external keypad interrupt. If neither counter has completed, than reinitialize the 10ms counter for another interrupt and RETI. aka j |
| Topic | Author | Date |
| Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
| RE: Keypad interfacing revisited... | 01/01/70 00:00 | |
RE: Keypad intrfaced with 8052 software | 01/01/70 00:00 |



