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.
I am using an 8051 (C51/BL51) with no off-chip memory. I have two functions with parameters:
void Detect( U8 iLed )
and
static U8 INHSampleHandler( U16 u16Sample )
Now I understand that Keil will allocate a variable (in DATA) for these. The problem seems to be that the locator is using the same memory location for both. I cannot understand why.
Below are excerpts from the scratchpad showing 2 "D:0026H". These are the only places these symbols are declared. Any ideas what I'm doing wrong?
Thanks, Jeff
BL51 BANKED LINKER/LOCATER V5.12 07/14/2011 09:36:23 PAGE 1 BL51 BANKED LINKER/LOCATER V5.12, INVOKED BY: Z:\TOOLS\SOFTWARE\KEIL\BL51.EXE Z:\Software\FB_CPU_Init.obj, >> Z:\Software\Settings.obj, Z:\Software\Glo >> bals.obj, Z:\Software\Devices\Clock.obj, Z:\ >> Software\Devices\Flash.obj, Z:\Software\Devices\HMI.obj >> , Z:\Software\Devices\INH.obj, Z:\ >> Software\Devices\ADC.obj, Z:\Software\Devices\Timer.obj, Z >> :\Software\Builds\TestINH - 06-00039-21-09\Main.obj >> , Z:\Software\Test\Test_Button.obj, Z:\So >> ftware\Builds\TestINH - 06-00039-21-09\Version.obj TO Z:\ >> Software\Builds\TestINH - 06-00039-21-09\06-00039-21-09-xx.wsp >> RS (256) PL (68) PW (78) XDATA (?XD?SETTINGS (0X0)) CODE (?CO?VERSION (0X7 >> FC0)) MEMORY MODEL: SMALL Deleted for brevity ------- PROC _INHSAMPLEHANDLER D:0026H SYMBOL u16Sample C:0BF1H LINE# 150 C:0BF5H LINE# 151 C:0BF5H LINE# 207 C:0BF7H LINE# 208 ------- ENDPROC _INHSAMPLEHANDLER ------- ENDMOD INH Deleted for brevity C:09FEH PUBLIC _Detect C:074EH PUBLIC main ------- PROC _DETECT D:0026H SYMBOL iLed
So how low down the significance scale exactly is no problem? I described how I have written plenty of assembler functions that were inherently re-entrant. the thread is about C
"...but, again, just saying there are "NO" problems is unhelpful." there are, indeed, - you say so yourself - some problems
Actually, that is not totally true. If one were to take the time to read the Keil documentation, they'd learn that it is in fact possible to write inherently re-entrant functions in Keil C51 (and I don't mean by using the reentrant keyword). Of course there are limitations. The functions would generally be small, take few parameters and use few local variables - Just the sort of sensible function that could be included into an ISR.
pray show a function that "don't use the reentrant keyword" and "use few local variables" and is "inherently re-entrant".
Erik
"pray show a function that "don't use the reentrant keyword" and "use few local variables" and is "inherently re-entrant"."
Erik, I really expected better of you.
Anyway - As a starting point, take the simple/obvious example:
void foo(void) { ; }
You'd find it difficult to get fewer local variables. It doesn't need reentrant. It doesn't require any overlaying of data (simply because there isn't any).
In the past I have said to our junior trainees: "Here is the start. You have the manuals. Expand a step at a time and see how far you get".
If you have a few spare minutes, you could give it a go. The manuals really do have all the necessary information.
"the thread is about C"
Yes, it is.
And that is precisely the reason why I dislike reading the statement:
"If at all possible, avoid calling any functios from a '51 ISR, period."
The budding professional might well read that and quite literally take it to assume it includes any scenario.
my post was triggered by it is in fact possible to write inherently re-entrant functions in Keil C51 (and I don't mean by using the reentrant keyword). Of course there are limitations. The functions would generally be small, take few parameters and use few few is not none local variables
thus
void foo(void) { ; } You'd find it difficult to get fewer local variables. It doesn't need reentrant. It doesn't require any overlaying of data (simply because there isn't any).
of course not, with no local variables what I asked you to do was to show it "with a few local variables" as you stated would be no problem
"of course not, with no local variables what I asked you to do was to show it "with a few local variables" as you stated would be no problem"
So I take it that you didn't pursue the finding of a solution yourself.
I did say that my little code snippet was the starting point. Just consider/remember that parameters and variables do not have to be stored in memory - Hint, no mention of registers.
Please remember, I did say in the same paragraph:
"Of course there are limitations."
And note that for this part, at least, I didn't say there would be 'no problem'.
Anyway ... I do not consider this part of the discussion to be particularly important and I'm not going to get dragged any further into it.