Hi, I have a simple application such as a microcontroller having internal ROM, an ext. RAM placed from 0x8000-0xEFFF, and an EPROM placed from 0x0000 - 0x1FFF. The EPROM is purposed to hold only display messages defined in the c code such as char const xdata Message[] ="Hello"; I don't want to have any other code in that EPROM. I want besides the genarated program code to have a separate HEX file for these messages ready for the EPROM. For example in format HEX-80. How am I to configure the settings using uVison? I have read the artıcles and the thread: http://www.keil.com/forum/docs/thread2074.asp Also, all related threads or similar. However, I haven't understood: am I able to use XCONST type constants in an external memory and genarate a HEX file only containing them without having a code Banking? So far some of my setings are as follow: Checked boxes: OPTIONS-Device-Use Extended Linker(LX51) instead of BL51 OPTIONS-Target-Use On Chip ROM(0x0-0xFFFF) OPTIONS-Target-Off-chip Xdata Memory 0x8000 size 0x7000 OPTIONS-C51-Misc Controls: XCROM OPTIONS-LX51 Locate-Use Memory Layout from Target Dialog checked User Classes: XCONST (X:0x0000-X:0x3FFF) Thanks in advance for your concern! BR Oktay
If you don't want to turn on Code Banking, I don't think there's any way you can get the IDE to directly create more than one HEX file from a single project. So you'd have to write a small batch script to do the gymnastics to split the single object file delivered by the project into two hex files, involving two invocations of OHx51. Once you have that script, you may want to add it to the "programs to run after build" of the project (Options->Output).
char const xdata Message[] ="Hello";
Hi Hans-Bernhard, Thanks for your quick reply and concern! Obviously it is better to have the code Banking rather than having a risky batch process. :) I just could't understand how to have a code Banking and place the constants defined as const xdata in a Bank. I don't want the processor to access to them with MOVC command. I want to have them accessed by MOVX. Also, do I need to include all the required LIB files such as XBANKING etc.? Basicaly, I didn't find a clarifying example on a simple application like this for C51. Could you help/guid me on this? Thanks in advance! Best regards Oktay
Hi A.W.Neil, Thanks for advise! I have multiple C files and only 1 linker output file. The definitions takes place in one of the C files. I have already tried to have the CONST data HEX file by adding a command in 'After Make' such as OHX51 lcd.obj HEXFILE (lcd.hex) H386 RANGE(0x0000-0x1FFF) OFFSET(0) but this gave an error, as it would be expected, as lcd.obj is not an absolute object file. So, probably I would need another 'After Make' command to have only this C file compiled and linked as absolute object file. Am I wrong or could you advise me on how to set this up? Thanks in advance! BR Oktay
and an EPROM placed from 0x0000 - 0x1FFF. The EPROM is purposed to hold only display messages defined in the c code such as char const xdata Message[] ="Hello"; As I read it This indicates that your EPROM is located in the DATA space, you aare trying to make tools designed to store in CODE space put data there. Erik
My EPROM is located in External Memory Space NOT DATA Space. I use the XCROM directive to have the const xdata set as defined message in XDATA space but as a ROM and not requiring pre-initialisation. Isn't it the purpose of the XCROM directive? I think this is OK! Nothing to be surprised here.
and an EPROM placed from 0x0000 - 0x1FFF. The EPROM is purposed to hold only display messages defined in the c code such as My EPROM is located in External Memory Space NOT DATA Space. where, then are your start and interrupt vectors? Erik
OHX51 lcd.obj HEXFILE (lcd.hex) H386 RANGE(0x0000-0x1FFF) OFFSET(0) but this gave an error, as it would be expected, as lcd.obj is not an absolute object file. Yes. Instead of lcd.obj, you need to specify the Linker's absolute output file. By default, uVision gives this the same name as the Project file, but with no extension.
"This indicates that your EPROM is located in the DATA space" Actually, in XDATA space. "you aare trying to make tools designed to store in CODE space put data there." No. This whole XCONST thing is specifically designed to put constants (which are, of course, just read-only data) into XDATA space - thus freeing-up CODE space for executable code. This is quite distinct from Code Banking.
"My EPROM is located in External Memory Space NOT DATA Space." Both of you are being either slack with your terminology, or just careless with your typing! The non-volatile storage for XCONST data needs to be located in XDATA space - that's what the 'X' means in XCONST!!
"I just could't understand how to have a code Banking and place the constants defined as const xdata in a Bank." 1. As previously mentioned, remove he 'xdata' - just put 'const' 2. Forget about Code banking; that is something completely different, and not relevant here. "do I need to include all the required LIB files such as XBANKING etc.?" No, you don't.
This whole XCONST thing is specifically designed to put constants (which are, of course, just read-only data) into XDATA space - thus freeing-up CODE space for executable code. If, indeed, that is so, then I presume it will be required to "burn" the XCONST EPROM separately. If it was to be stored from the code, it would occupy the same size in code. Erik
"If, indeed, that is so" 'Course it is - would I lie to you...? ;-) "I presume it will be required to 'burn' the XCONST EPROM separately" Logically, yes. That's why he needs an additional OHX51 operation to strip-out the XCONST stuff into a separate Hex file; thus he should end up with a <code>.hex file created by the OH51 as part of the standard uVision build, and a <const>.hex file from the additional OHX51. Physically, you might actually just put the XCONST stuff into a different part of the same physical PROM chip as the CODE. That requires, of course, that your address decoding correctly maps the Code part of the PROM chip into the 8051's CODE space, and the Const part of the PROM chip into XDATA space...
That's why he needs an additional AH, TWO burns, now it is clear. Statements like My EPROM is located in External Memory Space NOT DATA Space. does not exactly make the picture very clear. "External Memory Space" is not a synanym for XDATA, most often it is used to separate internal and external code. Erik
Andrew, Thank you for your comments! I see that you have understood my intention. There are 2 points I am not very clear with: 1. What is the difference if I use char const xdata instead of char const? Shall I keep the XCROM directive? I did this as it was advised in the Example of the user guide under section XCROM. Also, I have tried it and seems that there is no any difference in the map file. 2. Yes. Instead of lcd.obj, you need to specify the Linker's absolute output file. By default, uVision gives this the same name as the Project file, but with no extension. As I mentioned before, my project consists of several files and all are linked thus there exists one file containing project name as required by the OHX51. However, after running the command, this results in having the same HEX file as in the end of the general compilation. I guess this means that I am to create a new project only for this file and compile it separately. I don't know if there is a way to give a directive to give to the OHX51 to 'extract' only the const variables in a separate file. Am I wrong? What would you advise? Best regards, Oktay