STM32: Macros vs functions in interrupts.

[newbrain]

It was the function call. Copy and pasted the contents of the function into the interrupt and the time-sink went away.

Strange.
Have you investigated the reason?
Are you passing large amount of data by value?
Using floating point in both the ISR and the function (but 800 cycles...)?

Still, code diagnostics without seeing any code: it's always a shot in the dark.

[cv007]

Copy and pasted the contents of the function into the interrupt and the time-sink went away

We can't see what your code is, what the optimization settings are being used etc., but its not that hard to believe that when 'calling' the function its doing a lot more- the function has no idea 'who' may be calling it and has to do 'everything' because it does not know what parameters are passed (if any). Taking the same function and 'inlining' it (manually, or better just use the inline attribute for the function, whatever that may be for your compiler) , now the compiler can optimize it because it knows what the parameters are and can eliminate everything that's not relevant. 12 lines sounds like very little, but who knows (we don't) what is hiding (defines/macros/other function calls) in those 12 lines. Its also not hard to believe 12 lines can expand into a truckload of code behind the scenes.

The function call may take long, but its not the call that takes the time, its the function not knowing ahead of time who is calling it and what is has passed to it.

Not sure what compiler is being used, but there will be a way to keep 'intermediate' files (like .i , .s), generate a combined c/asm listing (.lst), etc. - then you can see exactly whats going on by reading these files (.lst file is handy).  I'm not great at this stuff, but after a while of checking what the compiler is up to, you get a pretty good idea whats going on under the hood.

[westfw]

I did. It was the function call. Copy and pasted the contents of the function into the interrupt and the time-sink went away.

That's really hard to believe, unless you did something like pass a 200word structure by value...

[Pack34]

I did. It was the function call. Copy and pasted the contents of the function into the interrupt and the time-sink went away.

That's really hard to believe, unless you did something like pass a 200word structure by value...

Nope. Just an unsigned int and a char. Then the function was called a second time.


The purpose of this thread was a sanity check on how the compiler handles macros. The observed and measurable behavior with the HAL libraries was a significant performance hit when calling a function from an interrupt and was alleviated when the code was directly used inside the interrupt instead of a function call. Both the cause and solution for this has been found.

[Kalvin]

The purpose of this thread was a sanity check on how the compiler handles macros. The observed and measurable behavior with the HAL libraries was a significant performance hit when calling a function from an interrupt and was alleviated when the code was directly used inside the interrupt instead of a function call. Both the cause and solution for this has been found.

For me it is still quite unclear what kind of code the compiler generated in both cases (inlined in the interrupt routine vs. calling a function from the interrupt routine). For example, what HAL function did you actually call? Can you enable the C compiler switches so that the compiler will also generate the assembly code so you can see where the 800 cycles of the overhead are coming from?

[newbrain]

Both the cause and solution for this has been found.

TBH, I don't agree.
Maybe the solution, but we have no evidence of what was happening.

The HAL, albeit not a light weight beast, does not add overhead to the function calls themselves.

We haven't seen any code, not even a hint of what IRQ  was being used, and if the HAL was called by the function or the HAL provided ISR used.

[John Coloccia]

Both the cause and solution for this has been found.

TBH, I don't agree.
Maybe the solution, but we have no evidence of what was happening.

The HAL, albeit not a light weight beast, does not add overhead to the function calls themselves.

We haven't seen any code, not even a hint of what IRQ  was being used, and if the HAL was called by the function or the HAL provided ISR used.

It's hard to help some people.

[donotdespisethesnake]

There is no way a function call by itselftakes 800 cycles, so you definitely didn't get to the root cause.

But, there may be some other strange effect simply from locating code in different places. When you get to the large Cortex MCUs, there are accelerators and caches etc that have an impact on performance, as well as other things.

Btw, macros are evil 

[Bruce Abbott]

The purpose of this thread was a sanity check on how the compiler handles macros. The observed and measurable behavior with the HAL libraries was a significant performance hit when calling a function from an interrupt and was alleviated when the code was directly used inside the interrupt instead of a function call. Both the cause and solution for this has been found.

In this one particular case. Doesn't mean it will be the same for other code.

Show us the code that proves your theory, or admit that you have not determined how the compiler handles macros vs function calls.

[rob42]

why not simply generate ASM listings and compare it for both cases ?