Looking for a keypad management IC

[AppCrash]

Hello,

the project I'm currently working on needs a 4 digit LED display, and some inputs.
At this time, for prototyping, the driver is the TM1637.
It has up to 16 debounced inputs.
5V supply

Fine, BUT :

This IC does not support combined key pressing : this makes it unsuitable for my project !

There's also a well known IC : the TCA8418 ; unfortunately, I will be unable to solder a WQFN package. Also, I'm not sure the internal FIFO could be disabled (I stopped reading the datasheet because of the QFN package)

I want 8 logical inputs. (I don't want an "analog matrix keyboard", and anyway I'm pretty sure it couldn't work with combined key pressing).

With no specialized IC, this means 2x hex Schmitt triggers and a bunch of discrete components. I don't want any software debouncing.

Do you know of an IC that could fit my needs : at least 8 debounced inputs, with combined key pressing, no FIFO, good immunty to EMI, supply : 5V prefered, package : flat with leads or through hole (EDIT : maximum 16 or 18 pin if through hole !).

[SteveMann]

AppCrash:
I want 8 logical inputs. (I don't want an "analog matrix keyboard", and anyway I'm pretty sure it couldn't work with combined key pressing).

So, you want 4X4 keypad with double button capability? Why wouldn't an analog matrix work?

[AppCrash]

A matrix topology is not required. No matrix (or 1x8 matrix) would make wiring much easier and less prone to errors (discrete 22mm industrial buttons, switches and contacts from industrial contactors).

The TCA8418 can be used without matrix for 8 inputs (in fact as a 1x8 matrix using ROW0-ROW7 and COL0 or any COLn). If there were a TCA8418 with leads, I wouldn't have even opened this thread. Even worse : the equivalent circuits I found are BGAs : no way !

The TCA8418 communicate using I2C. But something allowing just 8 inputs and 8 debounced outputs would just be fine : I have 8 free IOs on the MC (AtMega 328 at this time, but could be a STM32 in the end).

If such an integrated circuit does not exist (with leads), I know that some PCB manufacturers (JLCPCB and others) offer a service for assembling, but costs are not the same !

A classic schematic (with 74HC14) works fine (used on breadboards for prototyping and coding), but I want the finished project to be as small as possible.

Analog matrix :

• I doubt it would accept combined key pressing
• the circuits have to run in a harsh environment. Using analog inputs, with the needed resolution is really a bad idea. It's about motor control and variable frequency drives. I would never trust "analog buttons" over 3.3V or 5V.

[AppCrash]

Finally, I found such circuits after adding one keyword : industrial.

for example : MAX31913

unfortunately, they are not cheap.

[dougp]

Just saw this posted here the other day - https://www.aliexpress.com/item/4000103335387.html?aff_platform=portals-tool&sk=_dTX1mf3&aff_trace_key=018cddeb7a3f4bbaab4eceee9373d5a9-1597717269437-03482-_dTX1mf3&terminal_id=917cd46e5e90477faee9fef9315e7d93&tmLog=new_Detail&aff_request_id=018cddeb7a3f4bbaab4eceee9373d5a9-1597717269437-03482-_dTX1mf3

[Paul_B]

AppCrash:
I don't want an "analog matrix keyboard", and anyway I'm pretty sure it couldn't work with combined key pressing)

I agree, you do not want the "analog matrix" trick though you arguably could use it to allow multiple pressing of up to about five buttons.

AppCrash:
With no specialized IC, this means 2x hex Schmitt triggers and a bunch of discrete components. I don't want any software debouncing.

Then you are a poor engineer. Software de-bouncing is easy and the most effective.

AppCrash:
A matrix topology is not required. No matrix (or 1x8 matrix) would make wiring much easier and less prone to errors (discrete 22mm industrial buttons, switches and contacts from industrial contactors).

Really, the whole point of matrices is to simplify the wiring.

AppCrash:
A classic schematic (with 74HC14) works fine (used on breadboards for prototyping and coding), but I want the finished project to be as small as possible.

Then you persist in shooting yourself in the foot.

Anyway, you have been offered a board (corrected link) that looks like it will do the job.

[AppCrash]

Hi Paul___B,

I do not want software debouncing for this specific application.

But I just found something that does something very similar, is hardware based, and is far easier to use : the MC14490

No software, just a shift register. It has pullups, and needs only one capacitor for the integration time on the 6 inputs.

mc14490-d.pdf

I really fear we are in a X Y problem...

I explain a bit what I am doing (and that works in the lab !) : I remotely control a VFD using MODBUS over RS485. The slaves (for mùachine tools button boxes) run on a 328p (Pro Mini's at the moment), manage the buttons, and one contactor per machine. For many reasons, I have to take into account 2 buttons or more being pressed together. And it is coded. Imagine pressing "stop" and "run" with the "rev" contact active simultaneously. What will happen ? EMI is also a problem.

The master communicates with the VFD on another MODBUS/RS485 line. (I use DIL8 MAX485's)

This way, I can share one VFD among multiple machine tools : being the only user, with not much room, 15 years ago I made a first system, based on a star topology, but limited to 3 machines ; relay logic only : one cabinet (300mm x 400mm) one VFD, many relays, contactors, a safety module, and a lot of expensive 12 conductors cables... It's been in use for the last 15 years.

But more machines came in the workshop. I made a prototype based on a bus architecture with and industrial PLC. Never installed it, lab only. Still too much copper.

Now, I'm on the 3rd version : bus topology, up to 15 motors, but with MODBUS communications over one cheap Ethernet bus. The advantage is that the VFD being driven by the MODBUS master, the master uploads the optimized setup to the VFD for each and every machine (setups are saved/read to/from an SD card).

You will inderstand that software debouncing is something I want to avoid : the less software, the better it will be : no bugs. Everything has to be as real time and fool proof as possible. Everything that can be done with hardware will be done by hardware. The inputs deboucing is the last thing I have to design before I route and send the GERBER's to the manufacturer. Software is written, debugged, and tested.

Some pictures, as my bad english probably makes things unclear...

pic 1 : version 1, star architecture ; see here (in french...) : Alimentation triphasée pour machines
pic 2 : version 2 (in use for 10+ years), star architecture, the same but much cleaner ! more explanations (in french) here : Alimentation triphasée pour machines - version 2
pic 3 : version 3, never used, bus architecture, PLC based ; explanation (french...) : Alimentation triphasée pour machines - version 3
pic 4 : version 4, in the lab : 2 slaves (machine tools) on the right, 1 master (driving the VFD and the slave) on the left. Master and slaves have to be seen as state machines (poor man's PLCs), and as real time as possible. No useless code for what can be done with hardware.
pic 5 & 6 : a first prototype of the master
pic 7 : a typical command (here on my milling machine) ; uses industrial buttons and switches only

I will never use matrices in such an environment. On the milling machine, you can see two switches. One is for motor reverse, the other one sends a quick stop to the VFD and activates the motor braking system (the pneumatic cylinder you can see on the head). Motor can be reversed, the brake on simultaneously. Or RUN + REVERSE. and so on... Analog keyboard is not an option.

I hope you will understand that a matrix is a NO-NO. Even a digital matrix (except 1x6 or 1x8 obviously). One common for all buttons, and an input for everyone. This is my specifications. MC14490 is my new best friend !

[EDIT] "Then you are a poor engineer. Software de-bouncing is easy and the most effective" : Thank you ! You are probably wright. But you are missing some information about what I was needing. I found it by myself. And if you knox of any serious PLC or FSM that uses software debouncing, please tell me. I will avoid these brands !

Bye...

[AppCrash]

For some reason, the pics didn't upload...

[Paul_B]

Interesting project, but you have not explained any reason why you would not want to use the more reliable software debouncing!

Ah well ...

---

[AppCrash]

First of all, inputs have to be filtered with an integrator + some components (diodes, resistors capacitor), at least for EMI. This makes debouncing routines useless : just add a Schmitt trigger, and inputs are debounced ! So, why bother with software ?
My PLC and three of the VFD's I opened up have such input circuits (filter + trigger). One or two of the VFDs also have optocouplers (not 100% sure for one of them). I know that many Ladder examples can be found about debouncing logic, but I never had to do this when playing with my PLC and industrial buttons/switches.
Debouncing routines are pointless in my application : the slave loop reads inputs + write MODBUS registers, and read registers + write outputs. 4x 16 bits. Needless to say that there's a lot more code in the bounce2 library (for example) than in my loop. All the work is done by the MODBUS Master (Blue Pill).
I'd also want to experiment with inputs updating the registers with interrupts (reason why I will replace the Nano's with Blue Pill's (10 good enough fake Blue Pill's on the shelves). Better dio it with clean signals.
Bonus : the debouncer IC does most of the work if not all, and makes the PCB design A LOT easier, and more compact : inputs facing outputs : the IC can be dropped parallel to the 5v tolerant IO's of a BluePill.

Many reasons for not using software debouncing...

IC's were ordered from HK, so I'll have to wait for a few weeks until I know how such circuits and µC behave near to a VFD driven motor and its 4KHz PWM 3 phase sines on unshielded cables... Must pass, or the MODBUS project will be replaced with a much simpler idea I already successfully experimented with (the DIN box that can be seen above, MODBUS with VFD only).

Meanwhile, first routing with KiCad can begin... (after years with Eagle). Tired with these breadboards : bad contacts, wires all other the place, intempestive resets and displays blinking as soon as I touch something !

[johnerrington]

Software debouncing of multiple push-buttons is a nonsense, just adding unnecessary complexity to your code.

A simple experiment shows you can effectively debounce a push button or switch by adding a capacitor and resistor as shown on my site here

skillbank: Experiments and projects with an Arduino microcontroller

If you need the capability to check for multiple simultaneous key presses then you can not reduce the number of connections - so just read them directly with the arduino.

with 8 buttons you have 2^8 = 256 possibilities.

If you dont have enough pins, you could use 1 arduino to read the buttons, and another to control outputs.

[AppCrash]

@johnerrington

Thanks. Y knew your page.

I've also been using this schematics : https://my.eng.utah.edu/~cs5780/debouncing.pdf : page 15 ; it also solves the capacitor discharge problem. (not really a problem for industrial contacts, but I don't like shorting capacitors)

In fact, the title and the OP are a bit misleading because of my limited vocabulary. I was talking about keyborads because I knew such IC's do exist for a while in PC keyboards and other keypads, and they obviously deal with debouncing and simultaneous keystrokes (a switch or a NC contact are nothing else than very long keypresses !). Then I discovered highly sophisticated IC's for industrial use (PLC's input circuits by Maxim and TI). A bit overkill for 6 to 8 inputs. A couple days ago, I discovered the MC14490 that should do exactly what's needed for this application. I want to reduce the number of components on the PCBs. The MC14490 does something similar to software debouncing, using shift registers and a clock, and has 6 inputs (why not 8 ?). But it is hardware and combinatory logic. Unfornunately, I found no real world application note. All PLC schematics I found use RC + Schmitt triggers (for example OpenPLC).

Inputs :

Mandatory inputs : "RUN", "STOP", "QUICK STOP", "FWD/REV".

Classical contacts will be used : NO for run, NC for stop and quick stop (because industrial buttons I have came with), and NC or NO for the switch.

Another input is needed for an auxiliary thermal overload relay ; but if no input is available, it could be the NC contact in series with the stop button (the classic way...). In case the VFD is too powerfull for the motor ; one machine has a tiny 1/4HP motor, and the VFD protection cannot be set for small motors (Ith range in the setup).

Also, having a contactor feedback (using an auxiliary contact) would give a confirmation to the master that the machine is energized or not : double check for safety.

6 inputs should do it. 8 would be better, for further enhancements, but I can live without...

I'm not very keen about adding another MC. The STM32F103C has more inputs than the 328 and I have a lot of them.

All this is a very long term project : I had the idea 7 years ago, after I got one more machine tool, and started lab experimentions with VFD control through MODBUS 2 years ago. It could need one or two years more before such a system will be installed in the workshop ! (If experimentations are a success, and the most important : if the whole thing is 100% safe).