Hardware debouncing

[Breezebro]

I plan to use a 4x4 keypad through a hex inverter for debouncing, into a PCF8574 Port Expander, into an UNO.
I want hardware debouncing but I was wondering:
Could the debouncing take place in the port expander to eliminate the need for the hex inverter?

 

[AnalogKid]

"in" the port expander, no (at least not in the ones I'm familiar with). It isn't all that smart.

Often when a processor is involved, the debouncing is done in firmware/software. You are scanning the switch matrix anyway, so polling the returned signals to see when they stabilize is not a large increase in programming.

ak

 

[Breezebro]

"in" the port expander, no (at least not in the ones I'm familiar with). It isn't all that smart.

Often when a processor is involved, the debouncing is done in firmware/software. You are scanning the switch matrix anyway, so polling the returned signals to see when they stabilize is not a large increase in programming.

ak

Thanks for your reply!
I was planning to use interrupts instead of polling and the hardware debounce is needed for other circuitry not involved with the arduino. I was just going to take advantage of it in the arduino since it would be there anyway.
All this is a bit hazy cause I'm in the investigating/pre-planning phase.
So you think the r/c network used at the input of the port expander is a bad idea?
It does seem like a possibility too good to be true, but I would like to cut out the hex inverter if possible.
I have worked with this debounce circuit before but have never worked with a port expander, as such, to know how adversely it would be derailed from it's normal operation.

 

[Bluejets]

Interrupts for a ketpad???

 

[Breezebro]

For buttons anyway. I don't know if there is a disadvantage with multiple buttons.

Interrupts for a ketpad???

If you absolutely can't afford to miss a keypress and you have a lot of code monitoring many events, polling is too slow and processor time consuming.
If all it has to do is watch for key presses then polling is OK.

 

[AnalogKid]

Interrupts for a keypad???

Yeah, how is that going to work? For a matrixed keypad, usually the system drives the rows and reads the columns (or vice versa). I suppose the system could continuously drive the rows while it has the 4 column signals going to 4 interrupt inputs. Or are you doing a software interrupt based on the I2C port?

ak

 

[Breezebro]

Yeah, how is that going to work? For a matrixed keypad, usually the system drives the rows and reads the columns (or vice versa). I suppose the system could continuously drive the rows while it has the 4 column signals going to 4 interrupt inputs. Or are you doing a software interrupt based on the I2C port?

ak

The PCF8574 Port Expander chip has an interrupt pin that you can connect to so you do not have to continually poll to detect keypresses.
I will use the I2C output from the PCF8574.
I don't have this all worked out. As I said, I'm investigating this scenario and that's why I'm asking questions.
From what I've read so far, this seems the best way to go, with many inputs. I may have to cascade Port Expanders to cover all the inputs. I believe polling will never be able to cover them all, fast enough without causing delays in the program.
Anyway, thanks for the input. I guess I'll have to try the debouncing at the Port Expander to find out how it behaves.

 

[(*steve*)]

If you design your code as a state machine (and assuming that your code fits that model) then you should be able to do it without interrupts, simply scanning the keyboard at every transition.

Edit: the important thing in your circuit is not the inverter but the Schmitt trigger input. If your pet expander had Schmitt trigger inputs then this circuit could be used with its inputs.

 

[Alec_t]

There are no Schmitt inputs on that expander.

 

[bpark1000]

Thanks for your reply!
I was planning to use interrupts instead of polling and the hardware debounce is needed for other circuitry not involved with the arduino. I was just going to take advantage of it in the arduino since it would be there anyway.
All this is a bit hazy cause I'm in the investigating/pre-planning phase.
So you think the r/c network used at the input of the port expander is a bad idea?
It does seem like a possibility too good to be true, but I would like to cut out the hex inverter if possible.
I have worked with this debounce circuit before but have never worked with a port expander, as such, to know how adversely it would be derailed from it's normal operation.

Hardware debouncing of this type works poorly. You are forced to make RC time constant so long that it will slow keypad entry. This also generates slow-changing levels that circuit itself can create "bounce". How fast are you planning to hit keys? Software way is best. What I would do is set up a single periodic interrupt and run the WHOLE PROGRAM under this interrupt. One task under this program would be "keyboard update", where the scanning drive and debouncing routine would be (and these results are stored in memory for the other parts of your program to use). You don't say what rest of software is to do, so I can't advise regarding interrupt rate. Advantage of this method is that processor becomes a "state machine", taking inputs, driving outputs, the state being updated on each interrupt. Every task in the routine can function independently (such as blinking an LED at ANY RATE while scanning keyboard.) Only thing you must GUARANTEE is program finishes before next interrupt occurs.