 |
 |
| View previous topic :: View next topic |
| Author |
Message |
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
| Long Delays... |
 Posted: Sat Jan 17, 2015 11:45 pm |
 |
|
Do long delays in the main loop affect the interrupts ?
Ex:
| Code: |
void main()
{
setup_timer_1(T1_INTERNAL|T1_DIV_BY_8);
ext_int_edge(L_TO_H);
clear_interrupt(INT_EXT);
enable_interrupts(INT_EXT);
enable_interrupts(INT_TIMER1);
enable_interrupts(GLOBAL);
while(1)
{
delay_ms(65535); // exagerated delay for this thread question and bad practice
putc('a');
}
}
|
If not will the main loop delays be affected by the uC time spent in the interrupt?
Thanks!
EDIT:
CCS Manual answered my second question...
| Quote: | | The delay time may be longer than requested if an interrupt is serviced during the delay. The time spent in the ISR does not count toward the delay time. |
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Sun Jan 18, 2015 12:17 am |
|
|
and realistically, if you have a timer ticking, then use this.
Just have a countdown timer that decrements in the timer.
Then load this with a value for the time you want, and instead of waiting for a delay, wait for the counter to get to zero. |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Sun Jan 18, 2015 12:19 am |
|
|
| Ttelmah wrote: | and realistically, if you have a timer ticking, then use this.
Just have a countdown timer that decrements in the timer.
Then load this with a value for the time you want, and instead of waiting for a delay, wait for the counter to get to zero. |
I'm already using a timer to count (best way)...
I was just worried that some required small delays in the main loop influence my critical timer counting.
That's why I've posted a bad example to know if it affect in anyway my timer or whatever interrupts!
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
40inD
Joined: 30 Jul 2007
Posts: 112
Location: Moscow, Russia
|
|
| Posted: Sun Jan 18, 2015 2:28 am |
|
|
measure the time spended in ISR then correct timer counter
(get timer in the beginning of ISR and in the end of ISR) |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Sun Jan 18, 2015 4:59 am |
|
|
The length of the delay has no effect at all.
What _will_ have an effect, is if you use _any_ delays inside the ISR.
The PIC inherently does not have a 'data stack' (except when you get up to the DsPIC's). As such a routine cannot call itself (recursion). So recursion is not allowed in CCS. If then, you have a delay inside an interrupt, and then use a delay in the main code, since the same subroutine is used by the CCS delays, this would result in recursion, and you will get a compiler 'warning' message that interrupts have been disabled. If you get this, then a delay would have an effect. There are ways round this (you can create a second delay routine for use in the interrupt), but generally the rule is to avoid delays inside interrupts, to avoid this happening. |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Mon Jan 19, 2015 5:59 am |
|
|
| Ttelmah wrote: |
What _will_ have an effect, is if you use _any_ delays inside the ISR.
|
Yes... and no. Its unfortunately a bit more complicated. If there are ISRs then there are arguably three scenarios:
1) There are delays in the main code but none in ISRs (this should be the way the majority code is written; it is a "good thing"). In this case the delays will be lengthened by any time the processor spends processing interrupts.
2) There are short delay routines in both main code and ISRs - this is generally a "bad thing", but can be liveable with. Even though they look like routine calls, the compiler implements delay_cycles and shorter delay_us, by in-line code which makes no calls. Very short delays are done with non-looping code, longer by tight loops. This is in a sense the same as the first case, but of course the time the processor spends processing interrupts is longer.
3) There are longer delays in both main code and ISRs. Definitely a "very bad thing". The compiler delay_ms() and sometimes longer delay_us()s by calling routine that delays for one millisecond, delay_ms1, and one us, delay_us1, more than once if required. delay_ms delays by integer multiples of 1ms, though it will quite happily accept a float as its parameter. It's those 1ms and 1us routines that cause the trouble if they are called in both main and ISR code. If so, interrupts will be disabled in main code while it executes, delaying interrupts until it finishes. The time required to run any ISRs may also be added to the main code delay. In my experimentation, the compiler seemed to be unpredictable as to when it did us delays by calls, and when by loops. It depends on clock rate, with calls being more likely with faster processor clocks. For example in my test at 64MHz on a 18F46K80, it decided to do 10us by loops, and 100us by calls, resulting in interrupt disabling, but both by loops, and hence no interrupt disabling, at 16MHz. It also did delay_us(900) by loops at 16MHz if it only occurred in main code, but by calls if it was in both main and ISR code (its probably trying to reduce code size...)
If you really need to get more precise and consistent delays, and most of the time its is not required, either don't have interrupts, or use the hardware timers, but be aware of and if necessary take account of interrupt latency. |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Tue Jan 20, 2015 3:25 pm |
|
|
| RF_Developer wrote: | | Ttelmah wrote: |
What _will_ have an effect, is if you use _any_ delays inside the ISR.
|
Yes... and no. Its unfortunately a bit more complicated. If there are ISRs then there are arguably three scenarios:
1) There are delays in the main code but none in ISRs (this should be the way the majority code is written; it is a "good thing"). In this case the delays will be lengthened by any time the processor spends processing interrupts.
2) There are short delay routines in both main code and ISRs - this is generally a "bad thing", but can be liveable with. Even though they look like routine calls, the compiler implements delay_cycles and shorter delay_us, by in-line code which makes no calls. Very short delays are done with non-looping code, longer by tight loops. This is in a sense the same as the first case, but of course the time the processor spends processing interrupts is longer.
3) There are longer delays in both main code and ISRs. Definitely a "very bad thing". The compiler delay_ms() and sometimes longer delay_us()s by calling routine that delays for one millisecond, delay_ms1, and one us, delay_us1, more than once if required. delay_ms delays by integer multiples of 1ms, though it will quite happily accept a float as its parameter. It's those 1ms and 1us routines that cause the trouble if they are called in both main and ISR code. If so, interrupts will be disabled in main code while it executes, delaying interrupts until it finishes. The time required to run any ISRs may also be added to the main code delay. In my experimentation, the compiler seemed to be unpredictable as to when it did us delays by calls, and when by loops. It depends on clock rate, with calls being more likely with faster processor clocks. For example in my test at 64MHz on a 18F46K80, it decided to do 10us by loops, and 100us by calls, resulting in interrupt disabling, but both by loops, and hence no interrupt disabling, at 16MHz. It also did delay_us(900) by loops at 16MHz if it only occurred in main code, but by calls if it was in both main and ISR code (its probably trying to reduce code size...)
If you really need to get more precise and consistent delays, and most of the time its is not required, either don't have interrupts, or use the hardware timers, but be aware of and if necessary take account of interrupt latency. |
Thanks for the detailed explanation RF_Developer!
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
