I just migrated a project from Keil 3 to Keil 5 (C51 = V9.56.0.0 & LX51 4.66.66.0
I get the following (new) warnings:
*** WARNING L48: IGNORED RECURSIVE CALL CALLED: _SMBUS_SET_PACKET_DATA/SMBUS CALLER: SMBUS *** WARNING L48: IGNORED RECURSIVE CALL CALLED: SMBUS CALLER: _SMBUS_SET_PACKET_DATA/SMBUS
puzzle is that while there is a routine called smbus_set_packet_data there is no routine called smbus. In fact the routine is reproduced below:
static void smbus_set_packet_data(uint8_t pos, uint8_t val,uint8_t info) { smbus_packet[pos] = val; smbus_packet_info[pos] = info; }
What does the above warning indicate?
What exactly did the linker ignore? (Any calling sequence not included in the final binary?
thanks for the clarifications.
So you do have a function (or functions) called from both "mainline" and interrupt code?
That, then, is probably what the warning referred to as a "recursive" call.
That is a Bad Thing for C51 - because of the way the Overlaying works.
Your approach of "inlining" the code - instead of calling it - is a safe solution.
You can also look at tur oningverlay linker opt. Ion of fon th elin ker.
unfortunately it is common for those that insist on 'thinking PC' not to bother with learning what 'embedded' means
... not to bother with learning what 'embedded' means
But the problem here has nothing specifically to do with "embedded" as such.
Nor even "small microcontrollers" in general.
The problem here is very specific to Keil's particular proprietary implementation in C51 - which, itself, is severely constrained by the limitations of the underlying 8051 hardware architecture.
In general, there is nothing specifically wrong with calling a function "recursively" from both mainline & interrupt code; provided due care is taken. It's only the C51 implementation that makes it a Really Bad Thing.
I don't know if any other implementations have any better solution to this problem.
And we just end up seeing the same people repeating the same comments given many times in the past :(
with our earlier setup dating back 10 years (Microvision 3.3), we did not have the issue. the code itself had been running without issues.
OK, Mr language person :) ... not to bother with learning the embedded toolsset they use
with our earlier setup dating back 10 years (Microvision 3.3), we did not have the issue. the code itself had been running without issues. typically caused by timing changes due to (hopefully) the new version compiler being more efficient
You present that as if it were necessarily a bad thing. Well, it's not, if only because every year brings a new batch of newbies who need those comments to keep them from developing bad habits or incorrect beliefs, and who evidently cannot be bothered to research enough to find these comments on their own, so they have to get them delivered individually.
typically caused by timing changes due to (hopefully) the new version compiler being more efficient
Given that the primary issue under discussion was a linker warning, I would consider that rather unlikely. It's far more probable that the OP lost some critical build set-up details (like OVERLAY options) in the move from an uV3 to an uV4 project configuration.
... and who evidently cannot be bothered to research enough to find these comments on their own ...
And that one extract illustrates my point perfectly.