Hi
The Interrupts are presently configured so that they cause interrupts on every event. This means that a switch can generate multiple edges and so multiple interrupts. They are however suited to interrupt use where the source is a logic device.
I am wondering whether a single shot configuration may also be useful as possible configuration...
You could try a quick solution to debouncing as follows:
1. Disable the interrupt in the handler and start a debounce timer
static void test_irq_1(void)
{
unsigned char ucIRQ_bit = 1;
EPIER0 &= ~(0x01 << ucIRQ_bit); // disable interrupts
uTaskerMonoTimer( OWN_TASK, (DELAY_LIMIT)(0.05 * SEC), E_DEBOUNCE );
fnInterruptMessage(OWN_TASK, IRQ1_EVENT);
}
2. You will need to add the event define
#define E_DEBOUNCE 39
3. Then handle the timer to re-enable the interrupt:
case TIMER_EVENT:
...
else if (E_DEBOUNCE == ucInputMessage[MSG_TIMER_EVENT]) {
unsigned char ucIRQ_bit = 1;
EPFR0 = (0x01 << ucIRQ_bit); // clear pending interrupts
EPIER0 |= (0x01 << ucIRQ_bit); // enable interrupt after debounce time
}
This should then debounce the input for your tests and you can simply adjust the debounce time up to very long values.
In fact, due to the general problem with debouncing switches it is often preferential to poll them (especially in case of a key pad with lots of inputs) since the polling rate also acts as a form of debounce filtering.
regards
Mark
