| View previous topic :: View next topic |
| Author |
Message |
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
| Interrupts during delays |
 Posted: Mon Mar 07, 2016 8:57 pm |
 |
|
I am somehow confused regarding interrupts during delays.
I was thinking that interrupts are not served during delays but what I read in the CCS help is:
delay_cycles()
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.
delay_ms() & delay_us()
If interrupts are enabled the time spent in an interrupt routine is not counted toward the time.
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.
My question is:
Interrupts are served or not during delays?
Any answer will be appreciated
Joe |
|
 |
alan
Joined: 12 Nov 2012
Posts: 357
Location: South Africa
|
|
| Posted: Tue Mar 08, 2016 12:44 am |
|
|
Yes interrupts are served when delay is executing, unless you get a warning from compiler telling you interrupts are disabled during delay (Should only happen if you use delay inside the ISR).
Consider the following
for (i=0;i<100;i++);
This will more or less execute 200 instructions before carrying on with the next line of code.
However if an interrupt occurs during the execution of this line the number of instructions to get to interrupt and whatever instructions you have in your ISR will then be added to the 200 mentioned.
As you can see the delay will now be longer.
Regards |
|
|
drolleman
Joined: 03 Feb 2011
Posts: 116
|
|
| Posted: Tue Mar 08, 2016 1:19 am |
|
|
| if you need precise time use timers. delays are general purpose only. |
|
|
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
|
| Posted: Tue Mar 08, 2016 3:04 am |
|
|
Thank you for the prompt answers.
drolleman
Regarding timers, don't have any spare and the times I am counting with them are too long for short delays.
alan
So I was wrong regarding delays. Never used them before, but I need delay now.
The example you posted working fine, I am using it.
Best wishes
Joe |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19518
|
|
| Posted: Tue Mar 08, 2016 3:32 am |
|
|
| The point is though that he was showing you what effectively 'delay_cycles' codes 'as'. delay_cycles(200); basically generates this code. So will be affected by interrupts. He was not suggesting _using_ this |
|
|
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
|
| Posted: Tue Mar 08, 2016 3:58 am |
|
|
Hi Ttelmah
I am not using alan example as is. Adapted it to my needs.
More clear for me what the program is doing than delay_cycles()
Best wishes
Joe |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Mar 08, 2016 4:42 am |
|
|
| gjs_rsdi wrote: |
More clear for me what the program is doing than delay_cycles()
|
Really?
There are a number of possible problems to consider:
1) delay_cycles will ensure the correct number of cycles are added. Do-it-yourself delays, such as loops can be a bit "off" due to the programmer not taking account of exactly what the processor does. Also, different families of processors, PIC24/33s vs. 18s and 16s will behave differently, Delay_cycles sorts that out for you and is portable across all PICs. The compiler may use a loop, or it may just use NOPs.
Consider this code:
| Code: |
output_high(PIN_A1);
delay_cycles(10)
output_low(PIN_A1);
|
This gives a high pulse eleven cycles long on A1, not ten as might be expected. Even with no delay it would be one cycle long. Programmers often forget that all instructions take time.
2) The standard way of adding a NOP (no operation - an instruction that doesn't do anything other than waste time - i.e. a delay), in CCS C is to use delay_cycles(1). Sometimes this is used to get round some processor errata issues.
3) Optimisation can cause problems. Compilers like to optimise away code that doesn't appear to do anything. Loops with no code don't "do anything". Your delays might not be there at all! The delay routines won't optimise away.
4) The compiler will calculate and code the correct delays for you, or at least the nearest equivalent, for delay_us and delay_ms: they are portable in CCS C. They will be the same time, give or take a cycle, on all processors and all clock speeds.
5) Using delays, other than a few cycles, in ISRs is generally a bad thing. Using delay_ms and sometimes delay_us in both main and interrupt code may result in interrupts being disabled while some delays run in main code. The point here is that delay_ms and longer delay_us are implemented by subroutines, if the routine is called in both main and ISR code then the compiler will automatically disable interrupts when calling from main code. The compiler will give a warning when it does this, but won't tell you which delays will be affected. Basically, don't use delays in ISRs. |
|
|
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
|
| Posted: Tue Mar 08, 2016 12:11 pm |
|
|
Thank you for the detailed answer RF_Developer.
Best wishes
Joe |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Tue Mar 08, 2016 2:20 pm |
|
|
if the SUM of anticipated delay due to ISR service is less than the delay you want -this will be of real help to you.
http://www.ccsinfo.com/forum/viewtopic.php?t=54898
but ONLY in your main or a called function - NEVER in an ISR |
|
|
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
|
| Posted: Wed Mar 09, 2016 6:25 pm |
|
|
Thank you for the reply asmboy.
Saved your code so I can use later.
Best wishes
Joe |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
