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.
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 !