Fortunately, I only have to feed a toggle switch in to a PIC pin, so my 50ms debounce code sounds like it should work. Not a bad guess, I'm pleased with that! Maybe I am learning something! I get the impression that a 0.1uF capacitor from PIC to gnd can't hurt? Is the capacitor ok on its own, or should it have a resistor in series too to make some kind of RC constant (wouldn't know what I should choose here)? Regards, Mark > -----Original Message----- > From: piclist-bounces@mit.edu > [mailto:piclist-bounces@mit.edu]On Behalf > Of Jinx > Sent: 23 November 2004 22:30 > To: Microcontroller discussion list - Public. > Subject: Re: [PIC] I/O Pin cct design help please > > > > > Pushbuttons can get very noisy > > > and a simple RC filter + s/w debouncing is essential, > > > However, even in these situations I don't see a need for external > > RC filtering. Proper software debouncing should be able to take > > care of it. I find 50mS is usually a good debounce time. > It is much > > longer than real switches bounce, but fast enough to feel > instantaneous > > to a human user > > I agree about the 50ms, if you're expecting ordinary pushbutton > scratchiness, which even clean contacts will generate, and that works > well on toggle switches. But a PB that's not been used for some time > or got some dust in will be noisy for much longer than that, > IME, which > RC will alleviate. If possible the s/w should be written to > account for a > bad PB, depends on the pros and cons for application > > For example there's nothing more frustrating than trying set a display > and the digits appear to jump around because of a very bouncy PB > > > > _______________________________________________ > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== _______________________________________________ http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist