Hy, i have bought a ADuC7126 Eval-Board. There is a Switch for IRQ0 on P0.4 and an LED on P4.2 to VDDIO. I've studied the example XirqTest.c and tried to make the LED toggle each time the switch is pressed
#include <aduc7126.h> #define BIT17 0x00020000 int main(void) { unsigned char n; volatile unsigned long int a; POWKEY1 = 0x01; // Configure CPU to active mode, CD=0: Clock for 41.78MHz POWCON0 = 0x00; POWKEY2 = 0xF4; GP4DAT = 0x04000000; // P4.2 (LED D2) is Output IRQCONE = 0x2; // External IRQ0 triggers on rising edge. IRQEN |= BIT17; for(n=9;n;--n) { for(a=1000000;a;--a){} GP4DAT ^= 0x00040000; // Hardwaretest LED P4.2 toggle } while(1){} } //************************************************************** void IRQ_Handler(void) __irq { IRQCLRE = BIT17; GP4DAT ^= 0x00040000; // LED an P4.2 toggeln }
Of course i have tested the pure Hardeware function of this switch before.
while(1){} { if(GP0DAT & 0x00000010) // switch on P0.4 GP4SET = 0x00040000; // LED P4.2 off else GP4CLR = 0x00040000; // LED P4.2 on }
Now i'm a little desperate cause there is no reaction to pressing Switch.
I don't know your chip at all - sorry. How about trying some sample code? There must be tons of it around...?
I just want to tell the problem was not a Compiler or Software problem but it was just Contact bounce of the switch. Every pressing of the switch created two interrupts! The time between the two togglings is to short to see LED-lighting!!! The solution for this is a external RS-Flip-Flop = debouncing circuit. :-)
No need to add external hardware to the problem. This is just standard keyboard debounce, but involving an interrupt.
One solution is to have the interrupt deactivate itself, and then have a timer reactivate the interrupt 50 ms later. The advantage here is that a switch with a huge number of bounces will still only create two interrupts - the first input interrupt, followed by a timer interrupt.
Another solution is to peek at a uptime counter with enough resolution. If you have already seen an interrupt within x ms, you ignore this new interrupt as bounce. Lots of delay functions in a program don't need restarted timers but can make use of a continuousyly running timer function. Let's say the timer counts 100ms between each turn-around. And an interrupt ticks every torn-around, i.e. 10Hz. So you get rough delays in 0.1 resolution from the software counter and can get us or even sub-us precision by also involving the ticking of the hardware timer.
Another variant is if you have a timer that runs reasonably quickly. Say every 10ms. Then you have a global filter variable. If zero, then the input interrupt may accept the event, and sets the variable to 5 (for 50 ms). The 10ms interrupt ticks down the variable once/interrupt. Your input interrupt will then be blocked until you have had 5 timer interrupts and the filter variable have counted down to zero.