Issues initializing variable at a fixed address

 Issues initializing variable at a fixed address

Hi,

I am using the uVision2 v2.06

C51 - 6.02
A51 - 6.02
BL51 - 4.02
LIB51 - 4.12
OH51 - 2.5
S8051.DLL - 2.02
DP51.DLL - 2.02

Targeting an 8051.

When I follow the instructions here:
http://www.keil.com/support/docs/130.htm

The segment is located at the correct position in memory, but when I initialise the data as in the example, it also increases my program memory size. I'm moving the data to this segment specifically to avoid the loss of code space! Should this work or is this a feature that appears in a later version of the tools?

Thanks,
Brett

 RE: Issues initializing variable at a fixed address

So it looks like doing it this way moves the data into C_INITSEG, which is presumably copied over during startup. Is there a better way to do this to avoid chewing through code space?

 RE: Issues initializing variable at a fixed address

So...I did discover the "XCROM" directive:

http://www.keil.com/support/man/docs/c51/c51_xcrom.htm

So my code is:

#pragma XCROM
const STRING_STRUCT xdata Strings = {stuff};

However, the compiler is reporting "unknown #pragma"!!

 RE: Issues initializing variable at a fixed address

You have basically four options for global variables.

Don't initialize them at all (requires extra work).

Just don't assign a value. Then the startup code will zero-assign them.

Give them a specific value. Then the compiler _must_ store a copy of the data in the code space to allow copying the value from code space into your variable.

Create a const variable in the code segment. Then you get an initialized variable that don't consume space in both code and ram. But you can't change the value.

The link you have found seem to specify how you can use special mappings in some processor variants so that you can have the data in the flash (code segment) but be visible as xdata.

With a standard processor, that doesn't have this "magic mapping" support, you will have to declare the const variable as code instead for xdata. This will affect all pointers to your variable since it will not be fully transparent to the rest of the application.

 RE: the compiler is reporting "unknown #pragma"!!

You are using quite an old version - are you sure it supports this feature?

 THINK!

The segment is located at the correct position in memory, but when I initialise the data as in the example, it also increases my program memory size. I'm moving the data to this segment specifically to avoid the loss of code space! Should this work or is this a feature that appears in a later version of the tools?
.. where would the code get the values to initialize your variables from if not (the only permanent storage) code memory?

Erik

 RE: THINK!

Actually, I just checked the latest version with an eval and its still behaving the same way.

Erik, I understand what you are saying, but some processors use a loader to initialise this data. ie. when the EEPROM loads the program code, it should also load the xdata in memory too. I guess \it's just not possible with this processor (TAS1020).

 it is

use a loader to initialise this data. ie. when the EEPROM loads the program code, it should also load the xdata in memory too. I guess \it's just not possible with this processor (TAS1020).
it is, just do it manually from whatever EEprom you have.
write a quickie to load the values into the EEPROM

Erik