Interrupt RB0/INT0 Delay
Moderator: Benj
-
- Posts: 24
- Joined: Wed Feb 17, 2010 12:27 pm
- Location: Danmark Fyn
- Been thanked: 1 time
- Contact:
Interrupt RB0/INT0 Delay
I have a problem.
I use the flow code v5 but have no access to the v5 forum, but the problem is also in v4, so I write in v4 forum.
when I use a delay in an interrupt routine, it works fine if I set delay in milliseconds but not if I specify in seconds.
the same problem occurs when I call a macro from the interrupt routine, which includes a delay given in seconds.
When I set delay in seconds, it stops the interrupt routine for a long time, perhaps 50 times the time delayet is before it exits the interrupt routine again.
??????
I use a ECIO40 and Flow Code V5 and Interrupt on RB0/INT0.
I use the flow code v5 but have no access to the v5 forum, but the problem is also in v4, so I write in v4 forum.
when I use a delay in an interrupt routine, it works fine if I set delay in milliseconds but not if I specify in seconds.
the same problem occurs when I call a macro from the interrupt routine, which includes a delay given in seconds.
When I set delay in seconds, it stops the interrupt routine for a long time, perhaps 50 times the time delayet is before it exits the interrupt routine again.
??????
I use a ECIO40 and Flow Code V5 and Interrupt on RB0/INT0.
- Attachments
-
- test1.fcf
- V5
- (15 KiB) Downloaded 272 times
- 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 RB0/INT0 Delay
Hello,
Long delays in interrupt macros are not recommended and can cause problems if not done correctly.
I would advise that you have a variable that is set to 0 at the start of your program.
The interrupt macro sets the variable to 1 and then ends.
Somewhere in your main loop you have a check on the variable to see if it is equal to 1. If it is then you execute your original interrupt code including the delay and at the end you set the variable back to 0.
Does this help at all?
Long delays in interrupt macros are not recommended and can cause problems if not done correctly.
I would advise that you have a variable that is set to 0 at the start of your program.
The interrupt macro sets the variable to 1 and then ends.
Somewhere in your main loop you have a check on the variable to see if it is equal to 1. If it is then you execute your original interrupt code including the delay and at the end you set the variable back to 0.
Does this help at all?
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
-
- Posts: 24
- Joined: Wed Feb 17, 2010 12:27 pm
- Location: Danmark Fyn
- Been thanked: 1 time
- Contact:
Re: Interrupt RB0/INT0 Delay
No it is not an option, since the processor must control my grass robot, and the interrupt function is used to stop it when it run into something,
therefore, must interrupt performed immediately, and I can not wait for it reaches back to the main program.
The problem is not long delay times, because when I put the time to 1000 milliseconds, there are no problems but when I set it to 1 second it does not work, and 1000 milliseconds = 1 second.
so there must be a bug in Flow Code, in the code that control the delay when you choose the second unit and not millisecond?
therefore, must interrupt performed immediately, and I can not wait for it reaches back to the main program.
The problem is not long delay times, because when I put the time to 1000 milliseconds, there are no problems but when I set it to 1 second it does not work, and 1000 milliseconds = 1 second.
so there must be a bug in Flow Code, in the code that control the delay when you choose the second unit and not millisecond?
- 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 RB0/INT0 Delay
Ok that's strange, I wonder what is causing that.
Obviously we have tested second delays in v5 and they seem to be working fine whenever I have tested them so there must be something specific causing problems for you.
I will do some testing on an ECIO here and see if I can replicate the problem.
Obviously we have tested second delays in v5 and they seem to be working fine whenever I have tested them so there must be something specific causing problems for you.
I will do some testing on an ECIO here and see if I can replicate the problem.
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
-
- Posts: 24
- Joined: Wed Feb 17, 2010 12:27 pm
- Location: Danmark Fyn
- Been thanked: 1 time
- Contact:
Re: Interrupt RB0/INT0 Delay
Yes, strange, and the problem is only related to interrupt, delay in seconds works fine in all other routines.
try to find the problem.
I solve my problem by specifying any delay in milliseconds in my interrupt routines.
thank you
try to find the problem.
I solve my problem by specifying any delay in milliseconds in my interrupt routines.
thank you
- 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 RB0/INT0 Delay
Ok I have replicated the issue and am still no closer to understanding the cause of the issue.
The interrupt does seem to be returning with 1s delays instead of 1000ms delays as you can trigger the interrupt again and it prints out the "in test" string to the LCD again.
I will have a think on it over lunch to see if I can think of anything. Anyone else have an opinion?
The interrupt does seem to be returning with 1s delays instead of 1000ms delays as you can trigger the interrupt again and it prints out the "in test" string to the LCD again.
I will have a think on it over lunch to see if I can think of anything. Anyone else have an opinion?
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
-
- Posts: 24
- Joined: Wed Feb 17, 2010 12:27 pm
- Location: Danmark Fyn
- Been thanked: 1 time
- Contact:
Re: Interrupt RB0/INT0 Delay
I am from Denmark, and my English is not 100%.
So maybe I do not understand it exactly right.
But just so we agree on, 1 second is the same as 1000 millisecond.
So maybe I do not understand it exactly right.
But just so we agree on, 1 second is the same as 1000 millisecond.
- 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 RB0/INT0 Delay
Hello,
Yes 1000ms is the same as 1s, at least it should be.
Yes 1000ms is the same as 1s, at least it should be.
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
-
- Posts: 1314
- Joined: Sun Jan 15, 2012 3:15 pm
- Has thanked: 474 times
- Been thanked: 458 times
- Contact:
Re: Interrupt RB0/INT0 Delay
moved to v5 forum
To sign up to the V5 forum follow this link http://www.matrixmultimedia.com/forum_upgrades.php
- Enamul
- Posts: 1772
- Joined: Mon Mar 05, 2012 11:34 pm
- Location: Nottingham, UK
- Has thanked: 271 times
- Been thanked: 814 times
- Contact:
Re: Interrupt RB0/INT0 Delay
Hi frank,
I mean, there is no difference between 1000ms and 1s inside interrupt service routine in simulation.
Thanks,
Enamul
Have you seen similar problem in simulation? Or it just available in hardware? Because I have tried it in simulation and it works fine in simulation.frankmortensen wrote: when I use a delay in an interrupt routine, it works fine if I set delay in milliseconds but not if I specify in seconds.
the same problem occurs when I call a macro from the interrupt routine, which includes a delay given in seconds.
When I set delay in seconds, it stops the interrupt routine for a long time, perhaps 50 times the time delayet is before it exits the interrupt routine again.
I mean, there is no difference between 1000ms and 1s inside interrupt service routine in simulation.
Thanks,
Enamul
-
- Posts: 594
- Joined: Thu Sep 17, 2009 7:52 am
- Location: Belgium
- Has thanked: 63 times
- Been thanked: 102 times
- Contact:
Re: Interrupt RB0/INT0 Delay
Ben, did you take a look at the generated ASM code ?
Maybe there's something going on when generating a 1 sec delay.
Nicolas
Maybe there's something going on when generating a 1 sec delay.
Nicolas
-
- Posts: 24
- Joined: Wed Feb 17, 2010 12:27 pm
- Location: Danmark Fyn
- Been thanked: 1 time
- Contact:
Re: Interrupt RB0/INT0 Delay
Hi
No, there are no problems in simulation, it is only when it comes to the hardware.
Frank
No, there are no problems in simulation, it is only when it comes to the hardware.
Frank
- Enamul
- Posts: 1772
- Joined: Mon Mar 05, 2012 11:34 pm
- Location: Nottingham, UK
- Has thanked: 271 times
- Been thanked: 814 times
- Contact:
Re: Interrupt RB0/INT0 Delay
Hi frank,
I have checked your code in hardware and strange matter is that your claim is unexpectedly true.. I am now looking around the Delay_s code there must be some issue with this while interrupt is invoked.
I can remember while I was using assembly for dealing with interrupt and using long delay in program like seconds and also in ISR causing problem because of the intermediate registers used for delay subroutine. This effect was certain if I use same delay routine in main pg and ISR..similar thing is happening in your case.
So..i think before going to ISR if I can save the counter register for delay_s in a variable after returning from ISR if you re-load that one can solve the problem..
I am now playing on that...inform you I can get a clue.
Enamul
I have checked your code in hardware and strange matter is that your claim is unexpectedly true.. I am now looking around the Delay_s code there must be some issue with this while interrupt is invoked.
I can remember while I was using assembly for dealing with interrupt and using long delay in program like seconds and also in ISR causing problem because of the intermediate registers used for delay subroutine. This effect was certain if I use same delay routine in main pg and ISR..similar thing is happening in your case.
So..i think before going to ISR if I can save the counter register for delay_s in a variable after returning from ISR if you re-load that one can solve the problem..
I am now playing on that...inform you I can get a clue.
Enamul
- Enamul
- Posts: 1772
- Joined: Mon Mar 05, 2012 11:34 pm
- Location: Nottingham, UK
- Has thanked: 271 times
- Been thanked: 814 times
- Contact:
Re: Interrupt RB0/INT0 Delay
Hi,
I think you case is same as the initial posts of this link...
http://www.matrixmultimedia.com/mmforum ... ode#p35557
Enamul
I think you case is same as the initial posts of this link...
http://www.matrixmultimedia.com/mmforum ... ode#p35557
Enamul
- Enamul
- Posts: 1772
- Joined: Mon Mar 05, 2012 11:34 pm
- Location: Nottingham, UK
- Has thanked: 271 times
- Been thanked: 814 times
- Contact:
Re: Interrupt RB0/INT0 Delay
Hi Martin/Ben,
If I want to modify delay_s where I can get that in V5 directory?
I thought it is in the following directory...
C:\Program Files\Flowcode\v5\CAL\PIC\
and the
PIC_CAL_Delay.c
file...but in that file first portion is for hi_tech_c and last bit...
Wdt_Delay and FCI_DELAYINT
seems no impact in normal delay component..I have disabled there but still compiles..
so please let me know about for example...
delay_ms(250);
delay_s(1);
where is the c code for those...
Waiting for your response..
Enamul
If I want to modify delay_s where I can get that in V5 directory?
I thought it is in the following directory...
C:\Program Files\Flowcode\v5\CAL\PIC\
and the
PIC_CAL_Delay.c
file...but in that file first portion is for hi_tech_c and last bit...
Wdt_Delay and FCI_DELAYINT
seems no impact in normal delay component..I have disabled there but still compiles..
so please let me know about for example...
delay_ms(250);
delay_s(1);
where is the c code for those...
Waiting for your response..
Enamul
- 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 RB0/INT0 Delay
Hello Enamul,
Using the default BoostC compiler the delay functions are built in to the compiler so I don't think there is a way to edit the code behind the function. I may be wrong about this. You could provide your own C functions inside the supplementary code window and then edit the FCD file so as to point to your new delay functions.
FCD file delay pointers.
Using the default BoostC compiler the delay functions are built in to the compiler so I don't think there is a way to edit the code behind the function. I may be wrong about this. You could provide your own C functions inside the supplementary code window and then edit the FCD file so as to point to your new delay functions.
FCD file delay pointers.
Code: Select all
DelayCmdS="delay_s(%o);\n"
DelayCmdMs="delay_ms(%o);\n"
DelayCmdUs="delay_us(%o);\n"
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
- Enamul
- Posts: 1772
- Joined: Mon Mar 05, 2012 11:34 pm
- Location: Nottingham, UK
- Has thanked: 271 times
- Been thanked: 814 times
- Contact:
Re: Interrupt RB0/INT0 Delay
Hi,
Thanks boss
I will have a try...I think it that case there is some problem in delay_s in boostc when handing with interrupt..
I will make a then customized delay_s to use..
Enamul
Thanks boss
I will have a try...I think it that case there is some problem in delay_s in boostc when handing with interrupt..
I will make a then customized delay_s to use..
Enamul
- Enamul
- Posts: 1772
- Joined: Mon Mar 05, 2012 11:34 pm
- Location: Nottingham, UK
- Has thanked: 271 times
- Been thanked: 814 times
- Contact:
Re: Interrupt RB0/INT0 Delay
Hi Ben,
In all the interrupts in FCD file you have used call macro first then clear the flag which could generate false interrupt...
i think clearing the flag and disabling the interrupt in the handing code could produce more reliability in dealing with interrupt...
In all the interrupts in FCD file you have used call macro first then clear the flag which could generate false interrupt...
Code: Select all
HandlerCode="
#ifndef MX_INTHANDLER_intcon_INTF\n
#define MX_INTHANDLER_intcon_INTF\n
if (ts_bit(intcon, INTF) && ts_bit(intcon, INTE))\n
{\n
\t#ifdef USE_FLOWCODE_ICD\n
\t\textern char ICD_Interrupt_Enable = 1;\n
\t#endif\t\n\tFCM_%n();\n
\tcr_bit(intcon, INTF);\n
\t#ifdef USE_FLOWCODE_ICD\n
\t\textern char ICD_Interrupt_Enable = 0;\n
\t#endif\t\n}\n
#else\n#
warning "This interrupt has previously been enabled, so the macro <%n> may never get called."\n#endif\n"
Code: Select all
cr_bit(intcon, INTF);
cr_bit(intcon,INTE);
FCM_%n();
st_bit(intcon,INTE);
- 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 RB0/INT0 Delay
Hello Enamul,
We have taken the approach of call user macro before clearing interrupt flag as this holds the interrupt from firing again until the interrupt flag has been cleared, thereby ensuring against any false interrupts. The code you have suggested is essentially doing the same thing but there actually is the chance of an interrupt sneaking in, also for all you code optimisers this approach will use slightly more program memory to facilitate the extra instructions to disable and re-enable the interrupt.
The interrupt is only called on the flag's transition from 0 to 1 so leaving the flag as 1 means no further interrupts of that type can be called until the flag is cleared.
We have taken the approach of call user macro before clearing interrupt flag as this holds the interrupt from firing again until the interrupt flag has been cleared, thereby ensuring against any false interrupts. The code you have suggested is essentially doing the same thing but there actually is the chance of an interrupt sneaking in, also for all you code optimisers this approach will use slightly more program memory to facilitate the extra instructions to disable and re-enable the interrupt.
Code: Select all
cr_bit(intcon, INTF);
********potential unwanted interrupt********
cr_bit(intcon,INTE);
FCM_%n();
st_bit(intcon,INTE);
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
- Enamul
- Posts: 1772
- Joined: Mon Mar 05, 2012 11:34 pm
- Location: Nottingham, UK
- Has thanked: 271 times
- Been thanked: 814 times
- Contact:
Re: Interrupt RB0/INT0 Delay
Hi,
Thanks for the clarification....Are you sure that interrupt occurs only at Flag PGT..I was remembering my early work in assembly while keeping flag SET causes to re-generate INT...
Enamul
Thanks for the clarification....Are you sure that interrupt occurs only at Flag PGT..I was remembering my early work in assembly while keeping flag SET causes to re-generate INT...
Enamul
- 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 RB0/INT0 Delay
Hi Enamul,
Yep I'm fairly confident with this one. The Flowcode code for interrupts hasn't changed in years and I've had no reports of interrupts being triggered multiple times that I can recall.
Yep I'm fairly confident with this one. The Flowcode code for interrupts hasn't changed in years and I've had no reports of interrupts being triggered multiple times that I can recall.
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
- Enamul
- Posts: 1772
- Joined: Mon Mar 05, 2012 11:34 pm
- Location: Nottingham, UK
- Has thanked: 271 times
- Been thanked: 814 times
- Contact:
Re: Interrupt RB0/INT0 Delay
Hi Frank,
I have been looking through the BoostC forum about delay_s issue...I have seen similar kind of problem faced by other people in C..which has no link with FC...It's a bug in delay_s built-in function when used with interrupt..
I understand why the problem is occurring but can't get access to built-in delay_s function yet....ISR can't return to main function due to stack overwrite..
so..for the time being one solution is to use 1s delay using 1000ms delay in main function and the delay_ms in Boostc is highly reliable(at-least I haven't seen any complain against it) and you can use 1s in INT macro....if there is no chance that any other interrupt can be evoked during delay..or..best if you use ms delay everywhere....
Enamul
I have been looking through the BoostC forum about delay_s issue...I have seen similar kind of problem faced by other people in C..which has no link with FC...It's a bug in delay_s built-in function when used with interrupt..
I understand why the problem is occurring but can't get access to built-in delay_s function yet....ISR can't return to main function due to stack overwrite..
so..for the time being one solution is to use 1s delay using 1000ms delay in main function and the delay_ms in Boostc is highly reliable(at-least I haven't seen any complain against it) and you can use 1s in INT macro....if there is no chance that any other interrupt can be evoked during delay..or..best if you use ms delay everywhere....
Enamul
- Enamul
- Posts: 1772
- Joined: Mon Mar 05, 2012 11:34 pm
- Location: Nottingham, UK
- Has thanked: 271 times
- Been thanked: 814 times
- Contact:
Re: Interrupt RB0/INT0 Delay
Hi Ben/Frank,
In assembly code regarding delay in interrupt...
But in ISR..
so after ISR, when returns to main delay_s_00000_arg_del reg is already zero..but
above line tells to decrease it one which causes to 255 load in the reg..so the delay becomes 255 s
That's why it seems that PIC hangs for long time..The only solution to this is to have access to this register from C or FC..but this is not possible in built-in delay_s..delay_ms functions..
delay_ms has the same problem as this last for only 255 ms that's why we can't notice that.
Enamul
In assembly code regarding delay in interrupt...
Code: Select all
delay_s_00000
; { delay_s ; function begin
label3
MOVLW 0xFA
MOVWF delay_ms_00000_arg_del
CALL delay_ms_00000
MOVLW 0xFA
MOVWF delay_ms_00000_arg_del
CALL delay_ms_00000
MOVLW 0xFA
MOVWF delay_ms_00000_arg_del
CALL delay_ms_00000
MOVLW 0xFA
MOVWF delay_ms_00000_arg_del
CALL delay_ms_00000
DECFSZ delay_s_00000_arg_del, F //This is the register which carries number of second..
GOTO label3
RETURN
; } delay_s function end
Code: Select all
FCM_interr_00051
; { FCM_interrupt ; function begin
BCF STATUS, RP0
BCF STATUS, RP1
CLRF gbl_FCV_TAELLER
MOVLW 0xFE
BSF STATUS, RP0
ANDWF gbl_trise, W
MOVWF gbl_trise
MOVLW 0xFE
BCF STATUS, RP0
ANDWF gbl_porte, W
MOVWF CompTempVar2188
MOVLW 0x01
IORWF CompTempVar2188, W
MOVWF gbl_porte
MOVLW 0x01
MOVWF delay_s_00000_arg_del //In ISR, this register is reloaded with new value..which overwrites earlier
CALL delay_s_00000 //here delay_s_00000_arg_del reg becomes zero..
MOVLW 0xFE
BSF STATUS, RP0
ANDWF gbl_trise, W
MOVWF gbl_trise
MOVLW 0xFE
BCF STATUS, RP0
ANDWF gbl_porte, W
MOVWF gbl_porte
RETURN
; } FCM_interrupt function end
Code: Select all
DECFSZ delay_s_00000_arg_del, F
That's why it seems that PIC hangs for long time..The only solution to this is to have access to this register from C or FC..but this is not possible in built-in delay_s..delay_ms functions..
delay_ms has the same problem as this last for only 255 ms that's why we can't notice that.
Enamul