matmanj:
Some good points thank you guys.
Here's a much simpler demonstration of the concept:
/* unbounce 03
* fast polling an SPDT switch using INT flags
* ** not using interrupts, just the flags
* for arduino micro (atmega32U4)
*
* switch connections:
* NO -> Arduino pin 2 (PD1 - INT1)
* GND--
* NC -> Arduino pin 3 (PD0 - INT0)
*/
void setup() {
pinMode(2, INPUT_PULLUP);
pinMode(3, INPUT_PULLUP);
EICRA |= 0x0A;
}
void loop() {
if (EIFR & 0x03) {
byte switchStatus = EIFR & 0x02;
EICRA = EICRA & 0xF0 | 0x02 << switchStatus;
// do stuff that happens in response to the switch
}
// do loop stuff here regardless of switch state
}
I think a similar setup could be applied to an SPST switch with debouncing done lockout style using a similar routine with a timer interrupt.
The main advantages I'm looking at here are less loop overheads and no delays caused if the contact happens to be bouncing when it's polled.
Thanks, that is a lot easier to understand. If I do understand correctly, you are leveraging the fact that a low on one of the inputs is latched (i.e. remembered). If the input goes high again, the flag will remain low until cleared (read). Thus you believe that you have stabilized the switch bounce pulse train. It is true, you have.
But it is useless information that you have captured. Because, with the RS configuration, the detection of a low at any time on either input is ipso facto evidence not that switch bounce is terminated, but that it can be ignored.
It is important to consider the application context in which this is used. In a truly event driven software architecture, polling would be a bad thing because you would have to construct a periodic poll. In that case, a solution like I posted in reply #11 would be awkward. But you make reference above both to a loop and polling. That is actually how the vast majority of Arduino software operates. In such a case, polling (asking for information from a device only when you need it) is normal, acceptable and wise.
Thus, although your system works, it has no useful advantage. It has the disadvantage of using hardware features that might be required for other purposes. It is not simple. The theory that it is based on, attempts to solve a problem that really doesn't exist. I also doubt that it can be faster than applying a direct read of the R and S pin using port manipulation, to the solution that I posted. Probably slower.
A fair comparison of techniques would require an agreement to implement a real world wrapper function, restricted to a single switch, like at least:
bool switchState();
that returns the current state of the key, and possibly:
bool keyOn();
bool keyOff();
although it seems to me that those are trivial add-ons that can be derived from the first.
It's possible that your idea might have some useful application in situations where the switch events happen faster than the program can poll them. The classic case is tachometer sensor pulses. But that is a different problem, with a different application interface.
