| View previous topic :: View next topic |
| Author |
Message |
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
| Does CCS really mask interrupts before function calls? |
 Posted: Wed Aug 21, 2019 9:30 am |
 |
|
Please tell me I am mis-reading this:
https://www.ccsinfo.com/faq.php?page=functions_in_interrupts
It says:
| Quote: | | ...the compiler will "protect" the function call to A() from main() by disabling all interrupts before the call to A() and restoring the interrupt state after A() returns. In doing so, the compiler can allow complete sharing of functions between the main program and the interrupt functions. |
If I am running code like this:
...it is really masking IRQs before the call to A() and then unmasking when done? Thus, long functions can impact interrupt response? They specifically say this:
| Quote: | | In the above example, interrupts will be disabled for the entire execution of A(). This will increase the interrupt latency depending on the execution time of A(). |
If I am not mis-reading it, and it is what it says, can this be turned off and let us control it?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
 |
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Wed Aug 21, 2019 9:47 am |
|
|
| It only does this if A() is also called from an ISR. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Aug 21, 2019 9:55 am |
|
|
| newguy wrote: | | It only does this if A() is also called from an ISR. |
That would make much more sense. There is also a note saying that the built-in functions have IRQs disabled for them.
Maybe this other FAQ entry is unnecessary:
http://www.ccsinfo.com/faq.php?page=interrupts_disabled
This shows making two version of the function, one to be called from the ISR, and the other to be called from outside the ISR.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19505
|
|
| Posted: Wed Aug 21, 2019 10:38 am |
|
|
No, not unecessary. This shows how to make a second copy, so the
disable is not needed. Advantage is quicker interrupt responses when
it occurs inside the routine which would otherwise have interrupts disabled.
By default the compiler will tell you whenever it does do the disabled.
In the status section of the IDE, you should get a line:
Interrupts disabled to prevent re-entrancy.
Whenever this happens. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Wed Aug 21, 2019 11:12 am |
|
|
| The workaround is definitely necessary. I once got the "interrupts disabled to prevent reentrancy" because I was multiplying inside the ISR. I had to wrap that inside my own function, my_mult(), to get rid of the problem. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19505
|
|
| Posted: Thu Aug 22, 2019 1:40 am |
|
|
It's just worth understanding that the original quote, was 'taken out of
context'. It explains exactly what the compiler does actually do, but only
when read with the two paragraphs of text before it. It is discussing
how the compiler avoids regression. The protection is only applied when
regression would otherwise occur.The way to avoid it, is to avoid
regression. As Newguy says, there are circumstances where this forces
you to create effectively duplicate code to prevent the protection being
needed. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
|
| Posted: Thu Aug 22, 2019 7:17 am |
|
|
| Ttelmah wrote: | It's just worth understanding that the original quote, was 'taken out of
context'. It explains exactly what the compiler does actually do, but only
when read with the two paragraphs of text before it. It is discussing
how the compiler avoids regression. The protection is only applied when
regression would otherwise occur.The way to avoid it, is to avoid
regression. As Newguy says, there are circumstances where this forces
you to create effectively duplicate code to prevent the protection being
needed. |
Three of us here must not have gotten that context when we were researching this. We ended up calling CCS to get some clarification.
I hooked up a scope yesterday, toggling I/O pins in an ISR, and dug in a bit to this to verify, which has led us down another rabbit hole ;-) Always fun to learn new things, even when they are unexpected.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1346
|
|
| Posted: Thu Aug 22, 2019 4:46 pm |
|
|
| allenhuffman wrote: |
Three of us here must not have gotten that context when we were researching this. We ended up calling CCS to get some clarification.
|
That's definitely possible. Different people can read things very differently. That's why it is always good to have information in different formats and presented different ways so that different people are covered. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19505
|
|
| Posted: Fri Aug 23, 2019 1:27 am |
|
|
The point is that the whole document is discussing how CCS avoids recursion.
It gives an example that will cause recursion, then says that it'll disable
interrupts around the call to 'A()' in main to prevent this.
A simple one line test for yourself will show what is happening. A minimum
dummy function, and call it both in an interrupt and in main. The compiler
will give you the message 'Interrupts disabled to prevent recursion', and
a disable interrupt instruction will appear in the listing before the function
is called in main. Remove the recursion, no disable interrupt instruction. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
