Dear all, I have one question about DATA memory usage.
Original situation:(quoted from .m51 file)
... fno = 0x00;iflag=arg2; // C-code and below is machine code C:0x0E38 78A1 MOV R0,#fno(0xA1) C:0x0E3A F6 MOV @R0,A C:0x0E3B 78AF MOV R0,#arg2(0xAF) C:0x0E3D E6 MOV A,@R0 C:0x0E3E F534 MOV iflag(0x34),A
From above we can see: value in arg2(idata) is copied to DATA memory offset 0x34...
BUT after code merge I got the followings:(quoted from .m51 file)
... fno = 0x00;iflag=arg2; // C-code and below is machine code C:0x0E38 78A1 MOV R0,#fno(0xA1) C:0x0E3A F6 MOV @R0,A C:0x0E3B 78AF MOV R0,#arg2(0xAF) C:0x0E3D E6 MOV A,@R0 C:0x0E3E F53E MOV 0x3E,A
The difference is: value in arg2(idata) is copied to DATA memory 0x3F ! (unfortunately I was asked to not to change this after code-merge...)
Can anyone give comments/breakthrough-point about this ? How can I got the same result as original case after code merge ?
This should be expected behaviour!
There is absolutely no reason whatsoever to believe that a source-level variable will be fixed at any specific memory address - especially after you have changed the source code!!
This is the whole point of writing in a High-Level Language (HLL)!
If it really mattters to you, then you should be writing in assembler - not 'C'.
Dear Andy Neil, Thanks for your information.
The reason why I have to do this is: the firmware is composed of 2 parts(one in ROM and the other in SRAM)
The ROM part can NOT be modified and thus I have to do all my best to make ROM part is the same as before after code-merge...
*What I had tried was replacing some local variables with xdata variables and the best case now is: using DATA memory 0x3A...(BUT still not-enough !)
Can m51 file help to solve this kind of problem ? Does anyone have such kind of experience ?
Thanks in advance...
... then you must explicitly set the addresses of those variables!
Keil C51 provides a specific language extension to do this, or you can use Linker directives to do it - full details are in the manuals.
"Can m51 file help to solve this kind of problem?"
The M51 file shows you what the Linker has done - so, yes, it can help by letting you confirm that the Linker has done what you required!
the firmware is composed of 2 parts(one in ROM and the other in SRAM)
And it didn't occur to you that people might need to know this right from the start, rather than 5 postings into the thread?
The problem is that you're going about this "code merge" in entirely the wrong way. You can't merge at the source or object file level here. You need to link your ROM part on its own, then link the other part independently, but make the ROM image part of that second link. You'll want the "symbolsonly" directive with that.
"...And it didn't occur to you that people might need to know this right from the start, rather than 5 postings into the thread?"
I see...I will roughly describe the whole story when posting question.
"...You can't merge at the source or object file level here. You need to link your ROM part on its own, then link the other part independently..."
I will try the way you said later... *Before we compile/link the whole code together and then adjust for DATA MEMORY(xdata/idata/bdata) and CODE MEMORY to make ROM part the same as before. Honestly speaking it is really tough...
Embedded development is not a walk in the park!
Using fixed and updateable code at the same time is hard. Especially if the first release was built in the wrong way, and later updates then have to be based on strange work-arounds.
The fixed part should have been built stand-alone as a separate project.
On the other hand, the fixed part should have been given a fixed amount of RAM, and all functions and variables that the other part needs to access should have had a pre-defined mechanism how to figure out the addresses. Having a table of pointers would have allowed the fixed part to be recompiled without affecting the common interface.