We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi
I am trying to save some code sapce I used the STRING (XDATA) direcitve to move my constant string to xdata ,I also set my XCONST segment to 0x8000-0x8ffff. I notice that my code size is smaller but I coul find image that describe the data RAM (including the strings).
Does the LX51 linker produce XDATA image file ?
Here is part of my map file , you can see hat I have to XCONST segments buf I couldnt find the segments in my hex file
any ideas ???
* * * * * * * * * * * X D A T A M E M O R Y * * * * * * * * * * * * * 008000H 008034H 000035H BYTE UNIT XCONST ?XC?MAIN_DEMO 008035H 00805EH 00002AH BYTE UNIT XCONST ?XC?DEBUG 00805FH 008FFFH 000FA1H --- --- **GAP** 009000H 00AF49H 001F4AH BYTE UNIT XDATA ?XD?PRINT 00AF4AH 00AF75H 00002CH BYTE UNIT XDATA _XDATA_GROUP_ 00AF76H 00AF8BH 000016H BYTE UNIT XDATA ?XD?MAIN_DEMO
Does the ARM compiler support generics? I can't see it in the configuration help.
What is "generics"?
its Cx51 compiler for 8051 proccesor
The ARM compiler obviously do not support the 8051 processor, so so then the answer for the question "Does the ARM compiler support generics? I can't see it in the configuration help." should be "no!"
Could you expand on that?
How & where did you look for them?
Yossi Leybovich Does the LX51 linker produce XDATA image file ?
I don't believe so, since it uses ROM (IE that which you are trying to save) to load the string from.
Stephen
That's missing the point.
The object of the exercise is to save CODE space - not ROM.
It does this by having (some of) the XDATA space mapped to ROM - so the constants consume XDATA Space (mapped to ROM) instead of CODE space.
This is where it becomes vitally important to understand that "CODE Space" is not synonymous with "ROM" - and neither is "XDATA Space" synonymous with "RAM"...
let me expand
In my system I have 2 32K RAMS which I load at boot time.
32K code RAM is loaded with the hex file generated by the Cx51
I have the ability to load the data RAM as well ,so my plan is to move all constant strings to xdata and load it at boot time.
I set STRING (XDATA) and create XCONST segment for it. as you can see from the map file the linker does create the segment and locate it correctly.
I looked for the string file in lst directory and bin directory but could not find it
What makes you think there should be a separate "string file"?
As far as I remember, it all gets put into a single Hex file - so your loader would need to load the "code" address range into your Code RAM, and the "data" address range into your Data RAM. Or you'd have to make your own arrangements to generate separate Code & Data Hex files...
(when I was doing it, it was all going into a single PROM device - with part of that device mapped into the 8051's Code space, and part into the 8051's Xdata space. But it was a long time ago...)
The Hex file the linker generate does not include the address range of the XCONST ...
for example : in my map file BASE START END USED MEMORY CLASS ========================================================== X:000000H X:009000H X:00FFFFH 001F82H XDATA X:000000H X:009000H X:00FFFFH HDATA X:000000H X:008000H X:008FFFH 000072H XCONST C:000000H C:000000H C:00FFFFH 00068AH CODE I:000000H I:000000H I:0000FFH 000001H IDATA I:000000H I:000000H I:00007FH 00000DH DATA I:000020H.0 I:000020H.0 I:00002FH.7 000001H.1 BIT
you can see XCONST start at 0x8000 and CODE start at 0x0 in the hex file I can see only the code address range (i.e from 0 to 68A) I can see memory of 0x8000
Note that the Linker does not generate the Hex file at all.
The Hex file is created by BIN2HEX - which converts the Linker's output.
IIRC, you need to ensure that BIN2HEX is using one of the "extended" formats - to cope with the separate Code and Const address ranges...
the hex convertor ohx51, by default does not generate 2 hex files ...
I found thread that describe how to create another hex file from exe .... it does not simple ...I am working on it
will update when I will have the answer
Nobody said it would be simple!
;-)
"I found thread that describe how to create another hex file from exe..."
Please post the link for the benefit of other readers.
This one seems to sum it up: http://www.keil.com/forum/docs/thread6231.asp
Search keywords: XCONST and OHX51
exactly, I manage to create 2 hex file using the following command
OHX51 sample HEXFILE (sample_mem.hex) H386 RANGE(x:0x8000-0x8FFF) OFFSET(0)
now I am testing it on my HW