Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] PIC18F4550 push button Interupt triggering more than once per button pressed

Status
Not open for further replies.

overklog

Newbie level 2
Joined
Jul 11, 2012
Messages
2
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,295
Hey guys

My interupt looks like it is working fine, when I press the button LED RD2 gets switched off till I let the button go then it switches back on again. However when I add a counter to check how many times the interupt get triggered it increaments with more than once for evey time I press the button. Here is the 2 segements high priority and main routine of my code. I left out the rest of the code since I have procedures interfacing via usb to the computer and also using 2 other timers on high priority aswell which iis about 1000 lines of code.

Code:
//These are your actual interrupt handling routines.
#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode()
{

/////////////////////////////////////////////////////////////////////////////////////////////////
/////////////// Pin Interupt
/////////////////////////////////////////////////////////////////////////////////////////////////

   if ( INTCONbits.INT0IF)
   {

        WS1 = WS1 + 1; // WS = Wheel sensor
	INTCONbits.INT0IF = 0;
   }
}


int main(void)
#endif
{   
    InitializeSystem();

    #if defined(USB_INTERRUPT)
        USBDeviceAttach();
    #endif
    while(1)
    {
   
        #if defined(USB_POLLING)
		// Check bus status and service USB interrupts.
        USBDeviceTasks(); // Interrupt or polling method.  If using polling, must call
        				  // this function periodically.  This function will take care
        				  // of processing and responding to SETUP transactions 
        				  // (such as during the enumeration process when you first
        				  // plug in).  USB hosts require that USB devices should accept
        				  // and process SETUP packets in a timely fashion.  Therefore,
        				  // when using polling, this function should be called 
        				  // frequently (such as once about every 100 microseconds) at any
        				  // time that a SETUP packet might reasonably be expected to
        				  // be sent by the host to your device.  In most cases, the
        				  // USBDeviceTasks() function does not take very long to
        				  // execute (~50 instruction cycles) before it returns.
        #endif
    				  

	// Application-specific tasks.
	// Application related code may be added here, or in the ProcessIO() function.
        ProcessIO(); 
        if (PORTBbits.RB0 == 1) // button pushed
        {
			
            LATD = 0x00;
			//INTCONbits.INT0IF = 0;
        } 
        if (PORTBbits.RB0 == 0) 
        {
	    LATD =0x02;
        }     
    }//end while
}//end main

Thanks guys
 

That's a common problem, caused by switch bounce. When you close a switch, the contacts bounce a few times before staying on. We don't normally notice this e.g. with a light switch because it happens so fast.

If you google "switch debounce", you'll find a lot of info on the problem and how to fix it.

The hardware solution typically involves adding a resistor and capacitor to the switch to get rid of the glitches before they reach the input to your PIC (or whatever).

You can also fix the problem in your software, for example by ignoring any further changes to the switch input for a certain time (e.g. 100ms) after it changes state.
 

That's a common problem, caused by switch bounce. When you close a switch, the contacts bounce a few times before staying on. We don't normally notice this e.g. with a light switch because it happens so fast.

If you google "switch debounce", you'll find a lot of info on the problem and how to fix it.

The hardware solution typically involves adding a resistor and capacitor to the switch to get rid of the glitches before they reach the input to your PIC (or whatever).

You can also fix the problem in your software, for example by ignoring any further changes to the switch input for a certain time (e.g. 100ms) after it changes state.

Thank you. This you where spot on here is a link to a site if anyone else has the same problem how to solve it.**broken link removed**
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top