Matrix user forums

Posted: **Thu Jun 28, 2012 2:49 pm**

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.

Posted: **Thu Jun 28, 2012 3:44 pm**

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?

Posted: **Fri Jun 29, 2012 10:18 am**

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?

Posted: **Fri Jun 29, 2012 11:38 am**

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.

Posted: **Fri Jun 29, 2012 11:54 am**

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

Posted: **Fri Jun 29, 2012 11:56 am**

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?

Posted: **Fri Jun 29, 2012 1:08 pm**

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.

Posted: **Fri Jun 29, 2012 4:04 pm**

Hello,

Yes 1000ms is the same as 1s, at least it should be.

Posted: **Mon Jul 02, 2012 10:19 am**

moved to v5 forum

Posted: **Wed Jul 04, 2012 12:33 pm**

Hi frank,

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.

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.

I mean, there is no difference between 1000ms and 1s inside interrupt service routine in simulation.

Thanks,

Enamul

Posted: **Thu Jul 05, 2012 11:08 pm**

Ben, did you take a look at the generated ASM code ?
Maybe there's something going on when generating a 1 sec delay.

Nicolas

Posted: **Fri Jul 06, 2012 9:54 am**

Hi
No, there are no problems in simulation, it is only when it comes to the hardware.

Frank

Posted: **Fri Jul 06, 2012 5:13 pm**

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

Posted: **Fri Jul 06, 2012 5:58 pm**

Hi,

I think you case is same as the initial posts of this link...

http://www.matrixmultimedia.com/mmforum ... ode#p35557

Enamul

Posted: **Mon Jul 09, 2012 1:04 pm**

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

Posted: **Mon Jul 09, 2012 2:32 pm**

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.

Code: Select all

    DelayCmdS="delay_s(%o);\n"
    DelayCmdMs="delay_ms(%o);\n"
    DelayCmdUs="delay_us(%o);\n"

Posted: **Mon Jul 09, 2012 2:46 pm**

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

Posted: **Mon Jul 09, 2012 3:28 pm**

Hi Ben,
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"

i think clearing the flag and disabling the interrupt in the handing code could produce more reliability in dealing with interrupt...

Code: Select all

cr_bit(intcon, INTF);
cr_bit(intcon,INTE);
FCM_%n();
st_bit(intcon,INTE);

Posted: **Mon Jul 09, 2012 4:14 pm**

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.

Code: Select all

cr_bit(intcon, INTF);
********potential unwanted interrupt********
cr_bit(intcon,INTE);
FCM_%n();
st_bit(intcon,INTE);

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.

Posted: **Mon Jul 09, 2012 4:26 pm**

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

Posted: **Mon Jul 09, 2012 4:37 pm**

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.

Posted: **Mon Jul 09, 2012 4:40 pm**

Thanks sir

Posted: **Mon Jul 09, 2012 6:21 pm**

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

Posted: **Tue Jul 10, 2012 12:18 pm**

Hi Ben/Frank,
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

But in ISR..

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

so after ISR, when returns to main delay_s_00000_arg_del reg is already zero..but

Code: Select all

DECFSZ delay_s_00000_arg_del, F

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

Matrix user forums

Interrupt RB0/INT0 Delay

Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay

Re: Interrupt RB0/INT0 Delay