Hi, What happened with good old analog debouncer? (You just need a simple RC low-pass there for each switch) My idea comes from "lets save every possible bit of memory" kind of ... Meaning, why wasting memory on debouncer code if you can just debounce it with 2-3 extra components/switch? Sincerely, Alex. 2009/6/18 Vitaliy : > Josh Koffman wrote: >> Hi all. I'm got a project where I'm using 4 normally open, momentary >> switches. The port pins are normally held high via pullups, and the >> switch pulls the pin to ground. Thus the normal value for the pin is >> high. >> >> What I ultimately want is to detect a key down event and trigger an >> event in my code. I don't want the event to reoccur until the switch >> has been released and then pressed a second time. >> >> I'm using some excellent code to debounce the switches (found here: >> http://www.dattalo.com/technical/software/pic/debounce.html , thanks >> Scott!). It's called from a interrupt routine triggered by a timer >> rolling over. What's great about this code is that I end up with a >> register that holds the debounced state of my switches, and a register >> that shows which switches have changed state. >> >> Rather than do a bunch of bit testing to see which bit has changed, >> then which direction it's changed (ie key up or key down), I've come >> up with the following flow: >> >> We start with two registers, the debounced state and the changes register: >> 11111101 - debounced output - showing one switch pressed >> 00000010 - changes - showing the switch has just been pressed >> First we invert the debounced output: >> 00000010 - inverted debounced output >> 00000010 - changes - not touched >> Then we AND them together and we end up with: >> 00000010 - which should represent the debounced output filtered for a >> key down operation only. >> >> So...does this sound like it might work? I feel like I've run through >> the possibilities but few second opinions might not be a bad idea. >> >> Also it appears that in the process of writing this email I've thought >> of another potential difficulty. The way I understand things, every >> time the debounce routine runs, it updates the "changes" output. So, >> once a keypress makes it through the debounce the corresponding >> changes bit is only set until the next time through the routine. What >> if instead of overwriting the changes register each time I IOR it. If >> I'm right, I'll end up with a status register that I can then clear >> when I process the event. How's that sound? > > Sounds like it might work. :) > > For anyone interested in the theory of debouncing, I recommend Ganssle's "A > Guide to Debouncing": > > http://www.ganssle.com/debouncing.pdf > > I used some of the ideas from the guide to create a generic module for the > PIC24/33F which is configurable (you can specify press and release debounce > times) and clock speed independent. > > Vitaliy > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist