![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
valemike Guest
|
compiler warning: "interrupts disabled" |
Posted: Tue Mar 02, 2004 11:53 am |
|
|
I get a compiler warning that says:
"Line 430(0,1): Interrupts disabled during call to prevent re-entrancy."
However, my source code ends at line 429!
422 void panic()
423 {
424 while (1)
425 {
426 printf("PANIC!! ");
427 }
428 }
429
Why would I get a compiler warning with code that isn't even there? By the way, by merely adding this function in a 429-line program, I get this warning. The previous function didn't generate this warning.
Thanks,
Mike |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Mar 02, 2004 12:53 pm |
|
|
My guess is that you're calling printf from within an interrupt service
routine, somewhere else in your program.
If possible, avoid doing that. Instead, just set a global flag and
poll it in a while(1) loop, in main(). Then if the flag is set, clear it,
and do the printf there. |
|
![](templates/subSilver/images/spacer.gif) |
valemike Guest
|
Re: |
Posted: Tue Mar 02, 2004 1:38 pm |
|
|
I'm not calling printf inside an ISR.
Like I said, the warning only shows up when i append that panic() function in there. Perhaps since it's in an infinite while(1) loop, then CCS proacts with that warning? |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Mar 02, 2004 1:56 pm |
|
|
I can't get the compiler to give me that error.
What compiler, version, and PIC are you using ? |
|
![](templates/subSilver/images/spacer.gif) |
valemike Guest
|
re: |
Posted: Tue Mar 02, 2004 3:57 pm |
|
|
I'm using a PIC16F876, with the latest corresponding CCS compiler, 3.186.
#int_ext
void extint_isr(void)
{
delay_ms(20);
if (!input(PIN_B0) && ready_flag == 1)
{
latch_asserted = 1;
}
}
I commented out that panic() function, and still found the warning, so disregard what i said about the panic() function.
In my ISR, i use a delay_ms(20) to debounce a switch for 20ms, as you see above. If i comment out that delay_ms(20), then CCS doesn't generate that warning. Is there something wrong with using delay_ms() in an ISR?
The strange thing is that the warning line number refers to one line after the end of the .c file. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
valemike Guest
|
re: |
Posted: Tue Mar 02, 2004 4:12 pm |
|
|
Okay, I read other posts concerning the use of delay_ms() in an ISR. Tell me if this conclusion is correct:
The compiling of delay_ms() usually does not lead to a disabling of interrupts. However, if I use delay_ms() in an isr, then it is possible that i was in the middle of a previous delay_ms() upon getting interrupted.
If delay_ms() is then called again in the isr, then it will screw up my previous delay_ms, and that is why CCS will then disable interrupts in EVERY delay_ms() call, once it finds out that delay_ms() is used in an isr. Correct?
Therefore if I do not want delay_ms() to disable interrupts, then I should find a different method of delaying for 20ms while in the ISR. Perhaps use delay_us or something, or use a software delay for-loop.
So as long as i don't use delay_ms in any isr, then i won't get the compiler warning, and i will not lock out a pending interrupt in delay_ms() calls. Correct? |
|
![](templates/subSilver/images/spacer.gif) |
valemike Guest
|
ok thanks |
Posted: Tue Mar 02, 2004 4:56 pm |
|
|
Thanks for that link from Darren. (You posted it while i was typing a new msg, so it looks like i ignored it.)
-Mike |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
Re: ok thanks |
Posted: Wed Mar 03, 2004 3:10 am |
|
|
valemike wrote: | Thanks for that link from Darren. (You posted it while i was typing a new msg, so it looks like i ignored it.)
-Mike |
Seriously consider approaching the requirement a completely different way. If you have _anything_ else using interrupts, you allways want to keep the service routines as short as possible.
This should really be a 'mantra' written in big text at the start of the manual section about interrupts!...
I'd suggest that you use a CCP timer, and in the INT_EXT ISR, you disable INT_EXT, set the counter for the CCP to a value that corresponds to 20mSec for the timeout, and enable the CCP interrupt. Then when the CCP interrupts, you read the pin again, and check it is still active. If it is, you treat this as an 'OK' key response. Once you have finished the handler, you reset INT_EXT, and disable the CCP.
20mSec, is an _age_ in computer terms. It corresponds to 20 characters of data at 9600bps, which is not a 'fast' rate. It is actually a very long 'debounce'.
The alternative is, that if you are using a 'tick' timer for anything else in your system, consider using this to simply 'poll' the input. For instance, my keypads are normally checked on a timer at 1/100th second intervals, and if a key is seen, a flag is set, then if the key is still there at the next tick, it is treated as 'real'. The same interrupt provides simple timing functions, and outputs data from a buffer to an LCD (the nice thing about this rate, is that it is slower than the 'worst case' response time of the normal hitachi LCD controllers for any instruction, hence data can be sent without having to first check if the display is busy).
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|