CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Does CCS really mask interrupts before function calls?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
allenhuffman



Joined: 17 Jun 2019
Posts: 540
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

Does CCS really mask interrupts before function calls?
PostPosted: Wed Aug 21, 2019 9:30 am     Reply with quote

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:
Code:

main()
{
   A();
}


...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

View user's profile Send private message

PostPosted: Wed Aug 21, 2019 9:47 am     Reply with quote

It only does this if A() is also called from an ISR.
allenhuffman



Joined: 17 Jun 2019
Posts: 540
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Wed Aug 21, 2019 9:55 am     Reply with quote

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: 19477

View user's profile Send private message

PostPosted: Wed Aug 21, 2019 10:38 am     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Aug 21, 2019 11:12 am     Reply with quote

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: 19477

View user's profile Send private message

PostPosted: Thu Aug 22, 2019 1:40 am     Reply with quote

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: 540
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Thu Aug 22, 2019 7:17 am     Reply with quote

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: 1342

View user's profile Send private message

PostPosted: Thu Aug 22, 2019 4:46 pm     Reply with quote

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: 19477

View user's profile Send private message

PostPosted: Fri Aug 23, 2019 1:27 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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