We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi to all. I have some functions that are called from different ISR and are NOT declared as reentrant. Both functions return BOOL which is typedef as follows:
typedef unsigned char BOOL;
(the code compiled and linked without warnings) Trying to optimize the code, I decided to change this declaration, to see if less code is generated:
typedef bit BOOL;
And I gain some bytes of code. But now, the linker gives L15 Warning:
*** WARNING L15: MULTIPLE CALL TO SEGMENT SEGMENT: ?PR?_DPM_RELEASEBLOCK?DPM_ACCESS_FUNCTIONS CALLER1: ?PR?EXTINT_IRQ_HANDLER?MAIN CALLER2: ?PR?TIMER2_IRQ_HANDLER?MAIN
Why this warning was not issued before? The compiler did not inline those calls (they are in different modules) and I checked the assembler code. How is related the bit declaration in the return type with the linker warning?
Thanks a lot.
Take a look at http://www.keil.com/support/docs/805.htm and at the description in the manual of the call tree and how it works at http://www.keil.com/support/man/docs/bl51/bl51_ol_calltree.htm.
Jon
Thanks for the info. I did know that the compiler warning was due to the reentrancy of the functions. This problem does not bother me, because I can (and I think it's a better idea) move the code that calls to the functions to the main loop, and set a volatile flag in each ISR. Then the reentrancy disappears.
I am only curious about the fact that the linker did only complaint when I changed the return type, from unsigned char to bit.
Is there a good reason to do that? I already know that functions with bit parameters nor return types cannot be declared reentrant, and that makes sense. But the fact is that they weren't!
Thanks anyway.