I have a pulse of about 1-2 msec with 50Hz (period time 20 msec), see picture 1.
1) The high level of 3 Volt of the pulse is within the TTL definition of "high" 2.2-5V
2) Interrupt on INT pin (B0) gives correct period times with INT interrupt instead of interrupt-on-change
Kind regards
Jan Lichtenbelt
To measure the period time I use the interrupt-on-change (on port B3 of 16F1939). The interrupt is set only to rising edge. The timer used is Timer2 set on 19200 Hz (52 usec). If I use the pulse as given in picture 2 I measure a period time of about 288, which is 288 x 52 = 15 msec (correct see picture 1).
However if I change the pulse to the form as given in picture 3, I measure about 22-40, which is equal to 1-2 msec. And indeed the value change with the pulse length (repeating period stays unchanged). That means pulses like figure 3, not only the rising edge is detected, but also the falling edge. How is that possible????
Remarks:Interrupt On Change
Moderator: Benj
- Jan Lichtenbelt
- Posts: 797
- Joined: Tue Feb 17, 2009 8:35 pm
- Location: Haren GN, the Netherlands
- Has thanked: 128 times
- Been thanked: 264 times
- Contact:
- Enamul
- Posts: 1772
- Joined: Mon Mar 05, 2012 11:34 pm
- Location: Nottingham, UK
- Has thanked: 271 times
- Been thanked: 814 times
Re: Interrupt On Change
Hi
I think the problem is bcz of the handler code orientation...
it should be...
In ISR, it should clear IF flag first then should do rest of the things...
Enamul
I think the problem is bcz of the handler code orientation...
Code: Select all
//Handler code for [PORTB]
#ifndef MX_INTHANDLER_intcon_IOCIF
#define MX_INTHANDLER_intcon_IOCIF
char mxtmp;
if (ts_bit(intcon, IOCIF) && ts_bit(intcon, IOCIE))
{
#ifdef USE_FLOWCODE_ICD
extern char ICD_Interrupt_Enable = 1;
#endif
FCM_Get_Time();
mxtmp=portb;
cr_bit(intcon, IOCIF);
iocbf=0;
#ifdef USE_FLOWCODE_ICD
extern char ICD_Interrupt_Enable = 0;
#endif
}
Code: Select all
//Handler code for [PORTB]
#ifndef MX_INTHANDLER_intcon_IOCIF
#define MX_INTHANDLER_intcon_IOCIF
char mxtmp;
if (ts_bit(intcon, IOCIF) && ts_bit(intcon, IOCIE) && ts_bit(iocbf, IOCBF3))
{
#ifdef USE_FLOWCODE_ICD
extern char ICD_Interrupt_Enable = 1;
#endif
cr_bit(intcon, IOCIF);
cr_bit(iocbf, IOCBF3);
FCM_Get_Time();
mxtmp=portb;
#ifdef USE_FLOWCODE_ICD
extern char ICD_Interrupt_Enable = 0;
#endif
}
Enamul
- Jan Lichtenbelt
- Posts: 797
- Joined: Tue Feb 17, 2009 8:35 pm
- Location: Haren GN, the Netherlands
- Has thanked: 128 times
- Been thanked: 264 times
- Contact:
Re: Interrupt On Change
Dear Enamul
Thanks a lot for helping me. It took me a while to get your interrupt handler in my program. But I have to disappoint you, the results did not change. That means still interrupts on the falling edges, while only on the rising edges is wanted.
Kind regards
Jan Lichtenbelt
Thanks a lot for helping me. It took me a while to get your interrupt handler in my program. But I have to disappoint you, the results did not change. That means still interrupts on the falling edges, while only on the rising edges is wanted.
Kind regards
Jan Lichtenbelt
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: Interrupt On Change
Hi Jan,
I wonder if there is noise or something on the signal that is causing the IOC to trigger on a falling edge. i.e. a positive going spike during the falling edge. Your scope trace looks quite clean so I am surprised. Any chance you can add a cap or something to slow the signal voltage transition speed down a bit?
The original interrupt handler is recommended as this shouldn't have anything wrong with it. Enamul's interrupt handler has the possibility of an unwanted interrupt but this possibility is very remote.
I wonder if there is noise or something on the signal that is causing the IOC to trigger on a falling edge. i.e. a positive going spike during the falling edge. Your scope trace looks quite clean so I am surprised. Any chance you can add a cap or something to slow the signal voltage transition speed down a bit?
The original interrupt handler is recommended as this shouldn't have anything wrong with it. Enamul's interrupt handler has the possibility of an unwanted interrupt but this possibility is very remote.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: Interrupt On Change
The C code to enable the interrupt looks to be correct.
I wonder if there is another setting I am missing to force the rising / falling edge masks to be used. I'm guessing that no other external I/O is causing the interrupt to trigger so at least one of the masks must be working.
Code: Select all
st_bit(intcon,GIE);
iocbp=0x8;
iocbn=0x0;
st_bit(intcon, IOCIE);
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
- Jan Lichtenbelt
- Posts: 797
- Joined: Tue Feb 17, 2009 8:35 pm
- Location: Haren GN, the Netherlands
- Has thanked: 128 times
- Been thanked: 264 times
- Contact:
Re: Interrupt On Change
Hi Ben,
Only one pin is used as input pin for these measurements. I tried an other source for producing the pulses. But even with pulses like figure one, I get different readings, and sometimes the correct one (Vtop is 5 Volt in this case). It seems to me unstable. But what?
Jan
Only one pin is used as input pin for these measurements. I tried an other source for producing the pulses. But even with pulses like figure one, I get different readings, and sometimes the correct one (Vtop is 5 Volt in this case). It seems to me unstable. But what?
Jan
- Jan Lichtenbelt
- Posts: 797
- Joined: Tue Feb 17, 2009 8:35 pm
- Location: Haren GN, the Netherlands
- Has thanked: 128 times
- Been thanked: 264 times
- Contact:
Re: Interrupt On Change
Hi All,
That was a mistake made by myself. In the flowcode reseting the counter after the LCD actions was wrong. After removing this line the program works correct.
Kind regards
Jan Lichtenbelt
That was a mistake made by myself. In the flowcode reseting the counter after the LCD actions was wrong. After removing this line the program works correct.
Kind regards
Jan Lichtenbelt