are there ICs debouncing switches? - Page 1
Forum section: electronics / projects

author: vixo
author_rank: Regular Contributor
timestamp: October 26, 2020, 01:12:39 pm
content: I like the hardware debounce and I was wondering whether there is an IC which will debounce multiples (8, or 16? something like that) of tactile switches? Serial out would be OK but im not so keen on I2C. I saw the mc14490 mentioned but it's very expensiveany ideas?

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 26, 2020, 01:36:09 pm
content: CH551G? As a $0.40 microcontroller, you can use it to debounce 8 or 10 tactile switches, with it reporting presses/releases via UART.CH558L costs $1.25, but has enough pins to debounce 32 or more tactile switches. Open source toolchains exist for programming, and instead of only tactile switches, you can use rotary encoders etc., with the chip reporting only changes via UART or whatever serial protocol you want.Sorry. I know this is really just software debouncing. But perhaps modularizing this way, using more than one simple microcontroller, instead of packing everything into software on one complex microcontroller, gives you ideas?

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 26, 2020, 03:33:09 pm
content: Quote from: blueskull on October 26, 2020, 01:46:19 pmActivation delay? My software debouncing is always the insensitive-period type, which ignores state changes after the initial acted-upon one. I like the response characteristics, but it will be problematic with occasionally randomly blipping switches whose blips would be swallowed by RC filters.Quote from: blueskull on October 26, 2020, 01:46:19 pmNo, definitely not, only horribly badly machine-translated stuff likethis, but it seems enough to do something as simple as this. (Or my recent USB Gamepad, seeing as there is a combined HID example floating around at Github.) See e.g. GithubBlinkinLabs' ch554_sdcc,rgwan's librech551,DeqingSun's ch55xduinorepositories.So nothing one might compare to actual support from a manufacturer, but in my opinion (from a long software experience dealing with devices whose manufacturers used to actively dislike Linux developers and open source software), enough to do something like this. Do you disagree? (I am truly interested, especially since you can read the original datasheets, and might know how much is not available for us 外人.)

author: jpanhalt
author_rank: Super Contributor
timestamp: October 26, 2020, 03:33:18 pm
content: Maxim makes the MAX6816/17/18 devices, which are single, dual, and octal respectively. The Octal is $5.18 at Digikey, which is only $1 less than the MC14490.

author: IDEngineer
author_rank: Super Contributor
timestamp: October 26, 2020, 03:35:53 pm
content: Quote from: blueskull on October 26, 2020, 01:46:19 pmAgreed.And: A 74xxx14 hex Schmitt Trigger could be considered an "IC switch debouncer". Put an RC in front of each section. Speed is not an issue, so select the logic family based on your supply rails. Six switches debounced per 14 pin part. Cheap, easy, readily available worldwide in almost any packaging desired.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: October 26, 2020, 04:40:24 pm
content: I really don't understand all the fuss about hardware debouncing - unless you have something unusually bouncy, for things like normal tactile buttons, all you need to do is sample the switch every 20-40mS or so.If you have something really bouncy, add a holdoff to ignore anything for maybe 50mS after a transition is detected. trivial to do in software

author: IDEngineer
author_rank: Super Contributor
timestamp: October 26, 2020, 05:23:41 pm
content: Quote from: mikeselectricstuff on October 26, 2020, 04:40:24 pmTotally agree and I too prefer to do it in firmware, but I was answering what the OP actually asked:Quote

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 26, 2020, 06:07:05 pm
content: Quote from: blueskull on October 26, 2020, 04:30:49 pmI guessed something along those lines– any chance you might someday help with the datasheet translation? Say, if one prepares you a LibreOffice Writer document with the proper layout and existing text?Quote from: blueskull on October 26, 2020, 04:30:49 pmIt's a pity the datasheets haven't been translated by someone with technical knowledge. I mean, if you look at my$2 CH551 USB Gamepad project(in Public Domain), they're powerful little microcontrollers, much better than 8-bit Arduinos due to their hardware low/full-speed (1/12Mbit/s) native USB interfaces. (But because I don't know the pin boot-up states, or how strong the pullups/pulldowns are, I had to add current-limiting resistors that make things safe even if exactly the wrong ones happen to be high and the others low during bootup.) That $2 gamepad is designed to have a top carrier with a small 4-wire SPI (well, 3-wire, no chip select) display module, for choosing keys generated by the buttons, or notification from own userspace programs (like mail, perhaps).Quote from: blueskull on October 26, 2020, 04:30:49 pmThat's what I tried to find a term for, being outside Shenzhen or China in general, outside the playground with these nifty toys. No racist connotations implied.Quote from: mikeselectricstuff on October 26, 2020, 04:40:24 pmYep, that's what I do. Even 20ms delay is too long for keyboards and gamepads, so RC filter with that kind of a delay is undesirable, but the holdoff/insensitivity period after transition is really simple to implement, and rock solid. On a 8-bit micro, if you have a byte per button, you can even fine-tune it per button, and still keep a kHz scanning rate so that USB HID reports are sent within a millisecond of the transition. If one looks at their own keyboard usage, having a shorter holdoff period for metakeys for example might make a lot of sense.Having a button-interfacing dedicated MCU is not as crazy as it sounds, if you design the data interface (uart, spi, whatever) correctly. From keyboard design we already know that autorepeat is best implemented in the device (button-interfacing MCU). While the number of components increases, the software complexity decreases (per part), and we know software is the main source of bugs nowadays. Also, instead of the UI reporting what the buttons/switches/keys have been set to, it should report the state the device is operating on; so, while one is sorely tempted to merge buttons and display into a single unit, that may introduce logical design gotchas one might not think are problems until it is in production, like having button state immediately affect the display. (It's not fun when your display claims the supply voltage is set to 5.0V, the buttons respond just fine, but the main processor has actually crashed while outputting 18.0V)

author: fourtytwo42
author_rank: Super Contributor
timestamp: October 26, 2020, 06:53:20 pm
content: All you need is an SPCO switch and an RS flip flop. There did indeed used to be a chip in the 74xxxx series but assuming active low inputs two cross coupled nand gates do the job.

author: Benta
author_rank: Super Contributor
timestamp: October 26, 2020, 07:47:52 pm
content: https://www.onsemi.com/products/standard-logic/arithmetic-logic-functions/mc14490But doing it in firmware would be MUCH cheaper.

author: IDEngineer
author_rank: Super Contributor
timestamp: October 26, 2020, 09:02:55 pm
content: Yikes! $3.50+ each! No kidding firmware would be much cheaper.74xxx14's in through-hole package are under 50 cents in single piece quantities... if the OP still wants a purely hardware solution.EDIT: DigiKey has some versions for 11 cents in singles.

author: BrianHG
author_rank: Super Contributor
timestamp: October 26, 2020, 09:09:24 pm
content: Use can use a 3cent-6cent Padauk MCU.12 IOs for the 6cent guy = 8 inputs, serial out depending on your software skill, serial in to serial chain a bunch together to get all your buttons down to a 2 wire serial or an I2C port + a 2 spare for a serial link, or I2C address select.https://lcsc.com/products/PADAUK_11011.htmlOpen source programmer:https://www.eevblog.com/forum/blog/eevblog-1306-(1-of-5)-3-cent-padauk-micro-open-source-programmer/msg3066218/#msg3066218You wont beat 6 cents for 12 IOs with built in clock oscillator, software programmable.https://lcsc.com/product-detail/Others_PADAUK-Tech-PMS152-S14_C317589.html6 cent 14 IOs:https://lcsc.com/product-detail/Others_PADAUK-Tech-PMS152-S16_C317590.html

author: schmitt trigger
author_rank: Super Contributor
timestamp: October 27, 2020, 12:28:53 am
content: I never understood the price rationale for the MC14490.Yes, it is a nifty device, but it always has been expensive. I have seen cost as the reason given to not use it, at least in three different occasions.But it is still being produced, so someone must be using it.

author: emece67
author_rank: Frequent Contributor
timestamp: October 27, 2020, 12:40:12 am
content: .

author: amyk
author_rank: Super Contributor
timestamp: October 27, 2020, 01:51:05 am
content: Those dedicated ICs are still better than the times when debouncing took a circuit several times bigger than the switch itself and consumed a few dozen watts:http://www.righto.com/2018/01/ibm-mainframe-tube-module-part-ii.html

author: ajb
author_rank: Super Contributor
timestamp: October 27, 2020, 02:32:50 am
content: I can't believe anyone would do hardware denounce when firmware is an option. Like if it's triggering hardware, sure, but software is simpler cheaper and more flexible. I wrote it once and with two files I have multi-length events and configurable repeats, just add the update functions to a timed task and write the handlers

author: BrianHG
author_rank: Super Contributor
timestamp: October 27, 2020, 05:45:02 am
content: Quote from: ajb on October 27, 2020, 02:32:50 amNot everyone has the skills, time to learn them, or willingness to know how to code such things where it will take no more than 1 or 2 extra bytes of ram + 1 or 2 single cpu clock cycles to simultaneously debounce all 8 switches on an 8 bit MCU, or all 16 switches on a 16bit MCU.For them, it is much easier to look for an external solution.Scanning a keypad does add a little complexity.The external IO expander, or the cheap 6 cent Padauk MCU offers a 1 wire interface at a distance with 13 button inputs, or another 12 buttons with the addition of each 6 cent MCU feeding his MCU with a single 1 wire remote interface. This makes a cheap keypad interface. In this case, having the debounce in the Padauk is a bonus, plus, you can make that 1 wire serial bidirectional and have each 6cent Paudauk handle individual LEDs, or even drive an LCD character module remotely.We cannot predict the OP's true intent as to why he wants the features he requested, but I can guarantee he will never get anywhere close to 6cents for a 14 IO expander with debounce and panel LED driver the way he wants it to work with only a 1 or 2 wire interface using the UART on his existing MCU. He can even program that Padauk to scan 4x8 key-padd for 32 debounced buttons + setable 32 status leds, all in single 6cent IC.Think of him as if he was asking for a smart keyboard to RS232 IC which did all the legwork, however, he did not properly articulate to us his intentions of how or why it would be used the way he wanted.

author: vixo
author_rank: Regular Contributor
timestamp: October 27, 2020, 12:11:14 pm
content: Quote from: BrianHG on October 27, 2020, 05:45:02 amyeah pretty much, im being lazyi could do a firmware debounce if I really had to, but using a serial interface to read the switches would be optimal and thought there might be a package aside the MC14490 that does thisalthough, a regular serial interface for interfacing switches would also be good

author: Berni
author_rank: Super Contributor
timestamp: October 27, 2020, 12:17:21 pm
content: Just simply put a capacitor across the terminals of the switch. The pullup that you need anyway(be it external or in a MCU) provides the resistance for the time constant and there is no delay since the switch discharges the capacitor instantly.And don't worry the capacitor is so tiny it doesn't have enough energy to weld switch contacts. if anything for most switches it actually improves reliability since the capacitor discharge peak provides a good wetting current to clean oxidation off the contacts.

author: IDEngineer
author_rank: Super Contributor
timestamp: October 27, 2020, 12:21:24 pm
content: Dealing with a serial data stream is likely to be more complex than implementing firmware debounce.

author: indeterminatus
author_rank: Contributor
timestamp: October 27, 2020, 12:31:36 pm
content: Quote from: ajb on October 27, 2020, 02:32:50 amMy personal reason is the learning experience. I've been doing debouncing in software countless times, but never got around to actually attempting something like this in hardware. I'm well aware of the fact that it's neither cost-effective nor does it scale as nicely as a software solution. As such, I'm grateful for the question, and grateful for all the answers.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 27, 2020, 01:02:41 pm
content: Quote from: ajb on October 27, 2020, 02:32:50 amRobustness. Increasing complexity increases long-term maintenance costs proportionally more. That's why I suggested a separate microcontroller for button handling.The Padauk approach seems optimal to me: low price, one-time-programmable, enough resources to handle the buttons and encoders you have pins for. However, it is nontrivial to write the software needed, as there is no hardware UART or SPI, and there is very little ROM or RAM; you don't always have access to capable enough programmers. So, for a small run of devices, RC debouncing could result in better end result, given the resources available.Thinking about this from a programmer point of view, I'd use a SPI daisy chain, with SCK, DI, DO, and a latch pulse, so a MCU could handle any number of buttons and encoders using just four pins. Each byte would contain either the state of four buttons, or a rotary encoder (with a switch). The button states would be 00=Open, 01=Pressed, 10=Released, 11=Autorepeat, and the rotary encoders would be 6-bit two's complement, with the switch state in the low two bits. This way, the MCU would not need to scan them very often, as they would report the change since the last scan, and the MCU side would be as simple and robust as possible.