Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
OnChangePin1 interrupt
30-09-2014, 05:33 AM,
#1
Question  OnChangePin1 interrupt
Hi forum!

I've been testing some code related to interrupts, for a project. The idea of the code is utilize INT0 to increment a counter, later there is a timer that print the current counter value every second to CDC. I touch the pin0 (pin #21 of 18F2550) with a GND wire.

I see how the counter increment, but not increment 1 by 1. In some cases, if counter is 14, after "the touch" is 133. ¿?

Is there any problem with the code? Or there is another eletricity issue ?

Here is the code:

Code:
/*-----------------------------------------------------
Author: Victor Villarreal <mefhigoseth@gmail.com>
Date: Mon Sep 29 23:13:47 2014
Description:
OnChange interrupt test program.
-----------------------------------------------------*/
// Interrupt on change at pin 0.
int volatile counter0=0;
// pin aux variable.
int pin=1;

// Function called when INT0 occurs.
void int0() {
   counter0++;
}

// Function to print the counter status periodically
void isr_print() {    CDC.printf("counter0=%d\r\n",counter0); }

void setup() {
   // All pins at PORTA are inputs.
   for(pin=1;pin<=8;pin++) {
       pinMode(pin,INPUT);
   }

    // Call isr_print() funtion every 1sec.
   OnTimer0(isr_print, INT_MILLISEC, 1000);

   // OnChangePin0 interrupt callback.
   OnChangePin0(int0,INT_FALLING_EDGE);

   // Turn off USERLED.
   digitalWrite(USERLED,HIGH);
}

void loop() {
   // Intentionally left blank...
   }

Thanks in advanced!

P.D.: I've test OnChangePin1() and OnChangePin2() with similar results.
- -
Victor Villarreal
GnuPG Key ID: 0x39BCA9D8
https://github.com/MefhigosetH/
Reply
01-10-2014, 08:54 PM,
#2
RE: OnChangePin1 interrupt
Hi Victor,
Can you try without any call to CDC.printf or OnTimer0 ?
You might just try to toggle a led at each OnChangePin0 interrupt to see if this one work ...
It is easier to complain than it is to do, but it is better to do than it is to complain.
Reply
01-10-2014, 09:41 PM,
#3
RE: OnChangePin1 interrupt
(01-10-2014, 08:54 PM)regis Wrote: Hi Victor,
Can you try without any call to CDC.printf or OnTimer0 ?
You might just try to toggle a led at each OnChangePin0 interrupt to see if this one work ...

Hi Regis, thanks for your reply.

I'll try your suggestion.

P.D.: Congratulations for the new theme. It's nice.
- -
Victor Villarreal
GnuPG Key ID: 0x39BCA9D8
https://github.com/MefhigosetH/
Reply
02-10-2014, 10:17 AM,
#4
RE: OnChangePin1 interrupt
(30-09-2014, 05:33 AM)MefhigosetH Wrote: Hi.
There is a possibility that you experience "contact bounce" or sparks. in "the real world" contacts dont close "binary", you may have to create a debounce algorithm mainly consisting in sampling for a while (1 ms? 5 ms?) and then return the majority result (i.e. most ups or most downs).
(Also CDC printing (or serial port reading) interrupted by data sampling seems problematic.)
Thats "my 2 cents".
Windows, Icons, Mice and Pointers
Reply
02-10-2014, 02:29 PM, (This post was last modified: 02-10-2014, 02:35 PM by MefhigosetH. Edit Reason: Added related article link about topic. )
#5
RE: OnChangePin1 interrupt
(02-10-2014, 10:17 AM)wimp#1 Wrote:
(30-09-2014, 05:33 AM)MefhigosetH Wrote: Hi.
There is a possibility that you experience "contact bounce" or sparks. in "the real world" contacts dont close "binary", you may have to create a debounce algorithm mainly consisting in sampling for a while (1 ms? 5 ms?) and then return the majority result (i.e. most ups or most downs).
(Also CDC printing (or serial port reading) interrupted by data sampling seems problematic.)
Thats "my 2 cents".

Hi @wimp!

I was thinking about this before your post, and sounds logic. Maybe this topic is more complex that I think...

I've been read on the net about this, and can see in many circuits, a capacitor near the pushbutton to avoid the behaviour you describe.

Edit: Related article -> https://www.newbiehack.com/Understanding...ncing.aspx
- -
Victor Villarreal
GnuPG Key ID: 0x39BCA9D8
https://github.com/MefhigosetH/
Reply
02-10-2014, 03:56 PM,
#6
RE: OnChangePin1 interrupt
MefhigosetH,

The answers are already given by others and I wish to add my experience as well.

1) Hardware debouncing by adding a capacitor alone will not work well. It is basically creating a low pass RC filter and you will have problem of deciding the RC values besides it may not be suitable in every situation. If you are designing to capture a slow triggering input such as weather station for rainfall or water level, it would be good. But counting a rapid pulse such as tachometer can be affected by the capacitor recovery time.

If you need real clean hardware debouncing, the best way is using a schmidt-trigger gate to provide some hysteresis on the input. This is also suitable for the short pulse of signal rather than long pressing of a button.

2) Software debouncing algorithm to increment or decrease will work best on polling method at a fixed time interval and not very suitable on the interrupt mode. Since you already use a timer interrupt, you can attach the denouncing routine to it though it is against the original intention and spirit of using the interrupt on the pin change.

3) If you still want to use interrupt on pin change, the simplest way is to add a short delay at the interrupt so that no further interrupt can occur during the delay. I don't like the idea of disabling the interrupt but it works well on a simple design.

Another way to try is to record the current time (msec) on the interrupt, then compare the elapsed time on next interrupt. If the elapsed time is shorter than the preset debouncing time, ignore the interrupt. I use this way on my design.

4) Calling a CDC function within an interrupt handler is a bad idea. Just increment the interrupt counter variable in the interrupt handler. Watch this variable in loop() and call CDC function when the change is detected. This is said by others already.

Best luck.

DJ
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)