Use of DATA GROUP

There are a lot of people already doing this kind of stuff. To do this, you must be very careful and thoughtfully design your interfaces (ROM-EEPROM).

I've come up with the following list of tips and suggestions. Note that I would create 2 separate programs: one for the ROM portion and one for the EEPROM portion. Here are my assumptions:

1. ROM goes from 0x0000-0x7FFF.

2. EEPROM goes from 0x8000-0xFFFF.

3. A call-table will be generated in the EEPROM to provide addresses for functions in EEPROM called from ROM.

4. ROM functions can call EEPROM functions but not vice-versa.


The ROM Program...

1. The ROM program will be fixed. It will not change and so the EEPROM must work around it.

2. Note the last used DATA address for the ROM area.

3. Locate the stack pointer at 0x80. The space between the last data address (noted in step 2) and 0x7F may be used by the EEPROM program.

4. Do not include the EEPROM code in the ROM project. Instead, create a call table (that will be located in the EEPROM) using the function names (for the functions in EEPROM). For example:

cseg at 0x8000
func_1_redirect: ljmp func_1
func_2_redirect: ljmp func_2
.
.
.

Whenever your ROM program calls func_2, it will actually call func_2_redirect. This will jump to address 0x8003 which will jump to the REAL address of func_2 in the EEPROM.

5. Compile and get the ROM program to link with no errors.


The EEPROM Program...

1. Create functions in the EEPROM that are called from the ROM such that ALL arguments are passed in registers. This means that you must carefully specify the arguments. This also means that callers pass arguments in registers and do not have to know about the data address for each function.

2. Prototype these functions for the ROM program. Remember to add the _redirect at the end of each function name.

3. For this project, make sure that you specify that the data area starts at the address specified above. Avoid using BIT variables or you will have to do special stuff for them as well!

4. Local variables (automatics) in each function will be the biggest problem because the compiler will not be able to overlay these with the ROM portion (since the ROM cannot change). You may need to A) Use NOOVERLAY and/or B)Put local variables in XDATA.

5. Create a call table (in assembly) that corresponds to the table specified for the ROM program. In reality, this could be the same assembly program. Whenever you change the EEPROM program, the functions may move, however, the call table (at the fixed address of 0x8000 in this example) will remain stable--only the target addresses for each function will change.

6. Create a main C function that does nothing. It's only there to get everything to link.

7. You may want to look into using the reentrant stack and simply making all EEPROM functions reentrant. That way, all arguments and locals are placed on the reentrant stack. This is REALLY inefficient, but if you have a fast 8051, this may be acceptable.

These are just a few ideas. Hopefully, they will help.

Jon

There are a lot of people already doing this kind of stuff. To do this, you must be very careful and thoughtfully design your interfaces (ROM-EEPROM).

I've come up with the following list of tips and suggestions. Note that I would create 2 separate programs: one for the ROM portion and one for the EEPROM portion. Here are my assumptions:

1. ROM goes from 0x0000-0x7FFF.

2. EEPROM goes from 0x8000-0xFFFF.

3. A call-table will be generated in the EEPROM to provide addresses for functions in EEPROM called from ROM.

4. ROM functions can call EEPROM functions but not vice-versa.


The ROM Program...

1. The ROM program will be fixed. It will not change and so the EEPROM must work around it.

2. Note the last used DATA address for the ROM area.

3. Locate the stack pointer at 0x80. The space between the last data address (noted in step 2) and 0x7F may be used by the EEPROM program.

4. Do not include the EEPROM code in the ROM project. Instead, create a call table (that will be located in the EEPROM) using the function names (for the functions in EEPROM). For example:

cseg at 0x8000
func_1_redirect: ljmp func_1
func_2_redirect: ljmp func_2
.
.
.

Whenever your ROM program calls func_2, it will actually call func_2_redirect. This will jump to address 0x8003 which will jump to the REAL address of func_2 in the EEPROM.

5. Compile and get the ROM program to link with no errors.


The EEPROM Program...

1. Create functions in the EEPROM that are called from the ROM such that ALL arguments are passed in registers. This means that you must carefully specify the arguments. This also means that callers pass arguments in registers and do not have to know about the data address for each function.

2. Prototype these functions for the ROM program. Remember to add the _redirect at the end of each function name.

3. For this project, make sure that you specify that the data area starts at the address specified above. Avoid using BIT variables or you will have to do special stuff for them as well!

4. Local variables (automatics) in each function will be the biggest problem because the compiler will not be able to overlay these with the ROM portion (since the ROM cannot change). You may need to A) Use NOOVERLAY and/or B)Put local variables in XDATA.

5. Create a call table (in assembly) that corresponds to the table specified for the ROM program. In reality, this could be the same assembly program. Whenever you change the EEPROM program, the functions may move, however, the call table (at the fixed address of 0x8000 in this example) will remain stable--only the target addresses for each function will change.

6. Create a main C function that does nothing. It's only there to get everything to link.

7. You may want to look into using the reentrant stack and simply making all EEPROM functions reentrant. That way, all arguments and locals are placed on the reentrant stack. This is REALLY inefficient, but if you have a fast 8051, this may be acceptable.

These are just a few ideas. Hopefully, they will help.

Jon