Hi all, The Overlay mechanism implemented by Keil is ingenious. Moreover if we want add some functionnality in Eeprom without change ROM code is to my mind impossible because DATA GROUP area will be modified with new local variables used in our new functions in Eeprom. What do you think about this? Thanks a lot, Daniel
By careful use of linker controls you should be able to avoid problems. Or, if you don't need to overlay, you could just disable it altogether.
Thank you Andrew, but what do you mean about linkers control? Is it the following makefile modification in linker part: "DATA(_DATA_GROUP_(<fixed_address>)"?
By "Linker Controls" I mean the command-line options for the linker. There are very many Linker Controls for controlling all aspects of the Link & Locate process. See the Linker manual for details.
On the command line, add NOOL to the linker options. This disables overlaying of variables. Be aware that the use of RAM will most likely increase.
Are the following guesses correct? You currently have a system that has both rom and eeprom in it. The interrupt jmp table in eeprom. You currently have code the resides in both the rom and eeprom. You want to modify the eeprom part and leave the rom part alone.
I already generated ROM code and i would to use Eeprom memory to add some fucntionality but without any change of ROM code since it is already loaded. But when i add more than 1 local variable in my function the ROM code changed and cause problemes after link. Thank you
Hi Daniel, Split your Project into two. One for your ROM and one for EEPROM. After generating ROM-Project look the used resources in DATA, XDATA etc. These had to be excluded from EEPROM-Project. And for using functions in EEPROM use adresstabel with entrypoints. Chris
I am very confused. How can you extend the fuctionality of rom code without changing the rom?
One of the disgusting facts about the Keil software is that if you change the name of a variable (or add one) the whole DATA segment layout changes. Not using overlay is usually not an option. I sometimes work with software written by someone or another who uses variable names that are meaningless and in reforming such code I like to change the names and then compare the hex files to ensure that the namechange was the only change (I do make mistakes). This works fine for functions, but try it with a variable and booooooom, the whole hex file changes. As testing only guarantees the absence of KNOWN bugs, it takes an inordinate amount of time to verify what could be verified with a simple hex compare if the sequence of the variables were not shuffled. It would make sense to order the variables by occurence rather than some random? order. Happy hollidays, Erik
Hi Jon, Daniel wrote that he had ROM and EEPROM. And he want to add some functionnality in Eeprom: So i understand he will change the content of EEPROM. Physical by exchange or by in circuit programming. By writing/generating code with uvision he need to split his project. One for target ROM and one for target EEPROM. And when he calls function in EEPROM the ROMcode need the locations of EEPROM function. And this can be done tables with function entry points. This is what i have done in an project with Bootloader and reprogrammable Applikation. Chris
If you want no sorted variables use NOSO (no sort) as directive for the Linker. This is not documented but comes as info directly from Keil. Chris *<|:-), merry xmas
The NOSO (short for NOSORTSIZE) is documented on p316 in the current Linker manual (07.2000) But this relates to the ordering of Segments - not variables.
If I understand what he originally posted: Some code in ROM, some in flash. Adding a variable using ONLY in flash changes the location of variables used in ROM AND flash. Happy hollidays Erik
NOSORTSIZE has been available for a long time (since Version 5.50). We continually add new features to the Keil tools. This means that features are added each week or month--not just once every year or two so we can sell upgrades. With this continual development comes New Features. Unfortunately, we cannot reprint manuals each month or two. We also cannot send new printed manuals to customers who download updates. So, we added a file of Release Notes to each installation. The NOSORTSIZE linker directive has been documented in the release notes since it was introduced. Refer to the following knowledgebase article for the C51 V6.00 release notes. http://www.keil.com/support/docs/1258.htm Jon
It would make sense to order the variables by occurence rather than some random? order. The variables are not ordered randomly. They are ordered according to their placement in the symbol table manager (in the compiler). It is the job of the symbol table manager to maintain symbols in a "database" that the compiler can search. Symbols must be maintained by name and by scope level and the strategy must be such that the compiler can locate a symbol very quickly (or else compiler speed suffers). If you were to take a look at different strategies for symbol table management algorithms you will find that this is a sufficiently complex thing to do and on the 8051 this is further complicated by the lack of stack frames. Jon