On 8 October 2014 12:30, Dwayne Reid wrote: > Good day to all. > > I'm revisiting an old project that runs in a 12F508 12-bit core > PIC. There is one particular code segment that I use in many > projects that I'd like suggestions on. A quick skim - it's been 'a while' since I wrote PIC code so I may have this wrong BUT this seems to reflect a decision which may be philosophical but not what I have done in such cases. If I understand correctly (and I'll soon be told if I don't :-)), You are apparently debouncing from the first transient with no key action being declared until X equal keystates have been seen. This works, but produces a delay in key response which can be user perceptible. "Bounce" occurs at leading and trailing key action. IF the signal line is noisy it may be necessary to reject occasional short duration pulses but in most situations the bounce is caused by the switch as it is actuated/deactuated. When this is the case the debounce mechanism can declare any eg 0-1 transition as a 1 and then the delay maintains the 1 state for some period while the swith may or may not bounce. Similarly, once the delay is completed a subsequent 0 state immediately is registered as a 0 and a down-delay count starts. The above has the undesirable effect of seeing any short pulse as a valid switch action (as above) but the very positive effect of crisping up key input so the user gets instant response nd keys do not "feel" sluggish if some system response depends on the input. For extra points and more overhead you can have a two stage attack where X counts of eg solid 1 are required for a 1 (to reject spurious pulses) followed by Y counts for which a 1 is decalered regardless of key action to overcome genuine debounce. Russell --=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 .