Hi,
I am using a RCM 3700 with 512K SRAM and 512K Flash on DC 8.3.
1. My code declares "#memmap xmem" right on top of the C file.
2. I have 221KB of #ximport files. (includes html, jar & jpg files)
3. *.bin file comes to 435KB.
When I have disabled "seperate I & D space " and compile to a bin
file I get the following error.
"Out of variable data space", which produces the below *.map info.
//Segment Origin Size
Root Code 00:0000 0041cd
Root Data b1:5fb4 ffff9c3b
Xmem Code f9:e1c4 04c48c
When I enable "seperate I & D space" and compile to a bin file I
get
the following error.
"Out of xmem code space, use a larger ROM/RAM", which produces the
*.map info below
//Segment Origin Size
Root Code 00:0000 0033c0
Root Data 00:6030 ffff9ab7
Xmem Code 00:e204 066df9
I have quite few struct types and many instances of them on battery
backed SRAM. When I read the memory architecture I understood that
the variables have about 44K space. How can I increase this can get
it to compile?
What are the tricks to use space efficiently to allocate variables?
Does XMEM help me to place struct types there, and save me the root
memory space?. In other words, should I be placing these struct
types in XMEM? I want the contents to be on battery backed SRAM, so
if I place them on XMEM would that still count?
Your comments and tips are highly appreciated.
Regards
Nil-
Out of variable data space & Out of xmem code space, use a larger ROM/RAM
Started by ●June 17, 2004
Reply by ●June 17, 20042004-06-17
At 07:42 PM 6/17/2004, you wrote:
>Hi,
>I am using a RCM 3700 with 512K SRAM and 512K Flash on DC 8.3.
>
>1. My code declares "#memmap xmem" right on top of the C file.
>2. I have 221KB of #ximport files. (includes html, jar & jpg files)
>3. *.bin file comes to 435KB.
>
>When I have disabled "seperate I & D space " and compile to a bin
>file I get the following error.
>"Out of variable data space", which produces the below *.map info.
>//Segment Origin Size
>Root Code 00:0000 0041cd
>Root Data b1:5fb4 ffff9c3b
>Xmem Code f9:e1c4 04c48c >
>
>When I enable "seperate I & D space" and compile to a bin file I get
>the following error.
>"Out of xmem code space, use a larger ROM/RAM", which produces the
>*.map info below
>//Segment Origin Size
>Root Code 00:0000 0033c0
>Root Data 00:6030 ffff9ab7
>Xmem Code 00:e204 066df9
Both situations are caused by DATAORG.
In the first, DATAORG is set to 0x6000. As you can see in the map file,
RootData grew down below xx:6000 (root data drows down from 0x:d000.)
If you add DATAORG=0x5000 to your compiler defines and recompile the bios
and the project, it should work.
DATAORG is defined in rabbitbios.c. You can edit the file, but that would
effect all projects. It is better to add it to the defines in the compiler
settings.
The second example, the DATAORG is not a problem. However separate I&D
fragments RAM/FLASH, so you run out of xmem.
>Hi,
>I am using a RCM 3700 with 512K SRAM and 512K Flash on DC 8.3.
>
>1. My code declares "#memmap xmem" right on top of the C file.
>2. I have 221KB of #ximport files. (includes html, jar & jpg files)
>3. *.bin file comes to 435KB.
>
>When I have disabled "seperate I & D space " and compile to a bin
>file I get the following error.
>"Out of variable data space", which produces the below *.map info.
>//Segment Origin Size
>Root Code 00:0000 0041cd
>Root Data b1:5fb4 ffff9c3b
>Xmem Code f9:e1c4 04c48c >
>
>When I enable "seperate I & D space" and compile to a bin file I get
>the following error.
>"Out of xmem code space, use a larger ROM/RAM", which produces the
>*.map info below
>//Segment Origin Size
>Root Code 00:0000 0033c0
>Root Data 00:6030 ffff9ab7
>Xmem Code 00:e204 066df9
Both situations are caused by DATAORG.
In the first, DATAORG is set to 0x6000. As you can see in the map file,
RootData grew down below xx:6000 (root data drows down from 0x:d000.)
If you add DATAORG=0x5000 to your compiler defines and recompile the bios
and the project, it should work.
DATAORG is defined in rabbitbios.c. You can edit the file, but that would
effect all projects. It is better to add it to the defines in the compiler
settings.
The second example, the DATAORG is not a problem. However separate I&D
fragments RAM/FLASH, so you run out of xmem.
Reply by ●June 17, 20042004-06-17
--- In rabbit-semi@rabb..., Scott Henion <shenion@s...>
wrote:
> At 07:42 PM 6/17/2004, you wrote:
> >Hi,
> >I am using a RCM 3700 with 512K SRAM and 512K Flash on DC 8.3.
> >
> >1. My code declares "#memmap xmem" right on top of the C file.
> >2. I have 221KB of #ximport files. (includes html, jar & jpg
files)
> >3. *.bin file comes to 435KB.
> >
> >When I have disabled "seperate I & D space " and compile to a bin
> >file I get the following error.
> >"Out of variable data space", which produces the below *.map info.
> >//Segment Origin Size
> >Root Code 00:0000 0041cd
> >Root Data b1:5fb4 ffff9c3b
> >Xmem Code f9:e1c4 04c48c
> >
> >
> >
> >
> >When I enable "seperate I & D space" and compile to a bin file I
get
> >the following error.
> >"Out of xmem code space, use a larger ROM/RAM", which produces the
> >*.map info below
> >//Segment Origin Size
> >Root Code 00:0000 0033c0
> >Root Data 00:6030 ffff9ab7
> >Xmem Code 00:e204 066df9
>
> Both situations are caused by DATAORG.
>
> In the first, DATAORG is set to 0x6000. As you can see in the map
file,
> RootData grew down below xx:6000 (root data drows down from
0x:d000.)
>
> If you add DATAORG=0x5000 to your compiler defines and recompile
the bios
> and the project, it should work.
>
> DATAORG is defined in rabbitbios.c. You can edit the file, but
that would
> effect all projects. It is better to add it to the defines in the
compiler
> settings.
>
> The second example, the DATAORG is not a problem. However separate
I&D
> fragments RAM/FLASH, so you run out of xmem.
Hi scott,
As stated above with with Seperate I & D disabled,
with error "Out of variable data space"
// Compilers view of MMU. Note these values are determined by the
origin statements in the BIOS.
//Segment Origin Size
Root Code 00:0000 003f65
Root Data b1:5d17 ffff999e
Xmem Code f9:e1c4 0491be Now I set the DATAORG=0x5000 in the project definitions, then got
the following error (I & D disabled
"Out of root code space, try moving code to XMEM."
with map info
//Segment Origin Size
Root Code 00:0000 00519a
Root Data b1:57a4 ffff942b
Xmem Code f8:e1c4 06101e
I went to DATAORG=0x4000,and with the same error as above it produced
//Segment Origin Size
Root Code 00:0000 004315
Root Data b1:57f0 ffff9477
Xmem Code f7:e1c4 04d579 Any thoughts?.....
How do I move code to XMEM?, I thought defining #memmap xmem handled
it already?
Regards & Thanks for the reply.
Nil
wrote:
> At 07:42 PM 6/17/2004, you wrote:
> >Hi,
> >I am using a RCM 3700 with 512K SRAM and 512K Flash on DC 8.3.
> >
> >1. My code declares "#memmap xmem" right on top of the C file.
> >2. I have 221KB of #ximport files. (includes html, jar & jpg
files)
> >3. *.bin file comes to 435KB.
> >
> >When I have disabled "seperate I & D space " and compile to a bin
> >file I get the following error.
> >"Out of variable data space", which produces the below *.map info.
> >//Segment Origin Size
> >Root Code 00:0000 0041cd
> >Root Data b1:5fb4 ffff9c3b
> >Xmem Code f9:e1c4 04c48c
> >
> >
> >
> >
> >When I enable "seperate I & D space" and compile to a bin file I
get
> >the following error.
> >"Out of xmem code space, use a larger ROM/RAM", which produces the
> >*.map info below
> >//Segment Origin Size
> >Root Code 00:0000 0033c0
> >Root Data 00:6030 ffff9ab7
> >Xmem Code 00:e204 066df9
>
> Both situations are caused by DATAORG.
>
> In the first, DATAORG is set to 0x6000. As you can see in the map
file,
> RootData grew down below xx:6000 (root data drows down from
0x:d000.)
>
> If you add DATAORG=0x5000 to your compiler defines and recompile
the bios
> and the project, it should work.
>
> DATAORG is defined in rabbitbios.c. You can edit the file, but
that would
> effect all projects. It is better to add it to the defines in the
compiler
> settings.
>
> The second example, the DATAORG is not a problem. However separate
I&D
> fragments RAM/FLASH, so you run out of xmem.
Hi scott,
As stated above with with Seperate I & D disabled,
with error "Out of variable data space"
// Compilers view of MMU. Note these values are determined by the
origin statements in the BIOS.
//Segment Origin Size
Root Code 00:0000 003f65
Root Data b1:5d17 ffff999e
Xmem Code f9:e1c4 0491be Now I set the DATAORG=0x5000 in the project definitions, then got
the following error (I & D disabled
"Out of root code space, try moving code to XMEM."
with map info
//Segment Origin Size
Root Code 00:0000 00519a
Root Data b1:57a4 ffff942b
Xmem Code f8:e1c4 06101e
I went to DATAORG=0x4000,and with the same error as above it produced
//Segment Origin Size
Root Code 00:0000 004315
Root Data b1:57f0 ffff9477
Xmem Code f7:e1c4 04d579 Any thoughts?.....
How do I move code to XMEM?, I thought defining #memmap xmem handled
it already?
Regards & Thanks for the reply.
Nil
Reply by ●June 17, 20042004-06-17
At 08:59 PM 6/17/2004, you wrote:
>Hi scott,
>As stated above with with Seperate I & D disabled,
>with error "Out of variable data space"
>// Compilers view of MMU. Note these values are determined by the
>origin statements in the BIOS.
>//Segment Origin Size
>Root Code 00:0000 003f65
>Root Data b1:5d17 ffff999e
>Xmem Code f9:e1c4 0491be >Now I set the DATAORG=0x5000 in the project definitions, then got
>the following error (I & D disabled
>"Out of root code space, try moving code to XMEM."
>with map info
>//Segment Origin Size
>Root Code 00:0000 00519a
>Root Data b1:57a4 ffff942b
>Xmem Code f8:e1c4 06101e
>
>I went to DATAORG=0x4000,and with the same error as above it produced
>//Segment Origin Size
>Root Code 00:0000 004315
>Root Data b1:57f0 ffff9477
>Xmem Code f7:e1c4 04d579 >Any thoughts?.....
>How do I move code to XMEM?, I thought defining #memmap xmem handled
>it already?
Make sure #memmap xmem is before any #use statements. It is usually the
first line in my program. Try that first.
That is a lot of root code (20k). You'll probably need DATAORG=0x6000 to
fit that much root code.
Now you will have to trim some root data.
You can save root data space by also adding #class auto. But in 8.x, that
is the default.
You will have to trim down some of your global data. If you have a large
array you will have to move it to xmem. That will be slower as you will
need to use xmem2root() and root2xmem() to work with small pieces at a time.
Large serial buffers can also take up root space. Also, increasing MAX_MTU
and ETH_MAXBUFS will take up more root data space. You can leave MAX_MTU at
600 and reduce ETH_MAXBUFS to 4 to reduce root data.
Somewhere you must have a big array. Either try to make it smaller, or move
it to xmem.
In my last DC project, I have a large buffer to store processed data to be
sent out. I made a small array to store data quickly. If things back up I
added a large xmem array via xalloc(). Was messy, but it worked.
Using xmem for data is a pain in DC. Softools allows far pointers and you
can access large arrays directly. I find the ST compiler the only way to go
if you need large data arrays.
>Hi scott,
>As stated above with with Seperate I & D disabled,
>with error "Out of variable data space"
>// Compilers view of MMU. Note these values are determined by the
>origin statements in the BIOS.
>//Segment Origin Size
>Root Code 00:0000 003f65
>Root Data b1:5d17 ffff999e
>Xmem Code f9:e1c4 0491be >Now I set the DATAORG=0x5000 in the project definitions, then got
>the following error (I & D disabled
>"Out of root code space, try moving code to XMEM."
>with map info
>//Segment Origin Size
>Root Code 00:0000 00519a
>Root Data b1:57a4 ffff942b
>Xmem Code f8:e1c4 06101e
>
>I went to DATAORG=0x4000,and with the same error as above it produced
>//Segment Origin Size
>Root Code 00:0000 004315
>Root Data b1:57f0 ffff9477
>Xmem Code f7:e1c4 04d579 >Any thoughts?.....
>How do I move code to XMEM?, I thought defining #memmap xmem handled
>it already?
Make sure #memmap xmem is before any #use statements. It is usually the
first line in my program. Try that first.
That is a lot of root code (20k). You'll probably need DATAORG=0x6000 to
fit that much root code.
Now you will have to trim some root data.
You can save root data space by also adding #class auto. But in 8.x, that
is the default.
You will have to trim down some of your global data. If you have a large
array you will have to move it to xmem. That will be slower as you will
need to use xmem2root() and root2xmem() to work with small pieces at a time.
Large serial buffers can also take up root space. Also, increasing MAX_MTU
and ETH_MAXBUFS will take up more root data space. You can leave MAX_MTU at
600 and reduce ETH_MAXBUFS to 4 to reduce root data.
Somewhere you must have a big array. Either try to make it smaller, or move
it to xmem.
In my last DC project, I have a large buffer to store processed data to be
sent out. I made a small array to store data quickly. If things back up I
added a large xmem array via xalloc(). Was messy, but it worked.
Using xmem for data is a pain in DC. Softools allows far pointers and you
can access large arrays directly. I find the ST compiler the only way to go
if you need large data arrays.
Reply by ●June 17, 20042004-06-17
See Tech Note 238.
Also, since you have a unit with a serial flash on it, you could load
your jpg files to the serial flash. 8.51 has improved integration of
serial flash, including support for a FAT file system (sold
separately for $149).
http://www.rabbitsemiconductor.com/support/techNotes_whitePapers.shtml --- In rabbit-semi@rabb..., "aintnoprobs" <nilkamal@h...>
wrote:
> Hi,
> I am using a RCM 3700 with 512K SRAM and 512K Flash on DC 8.3.
>
> 1. My code declares "#memmap xmem" right on top of the C file.
> 2. I have 221KB of #ximport files. (includes html, jar & jpg files)
> 3. *.bin file comes to 435KB.
>
> When I have disabled "seperate I & D space " and compile to a bin
> file I get the following error.
> "Out of variable data space", which produces the below *.map info.
> //Segment Origin Size
> Root Code 00:0000 0041cd
> Root Data b1:5fb4 ffff9c3b
> Xmem Code f9:e1c4 04c48c >
>
> When I enable "seperate I & D space" and compile to a bin file I
get
> the following error.
> "Out of xmem code space, use a larger ROM/RAM", which produces the
> *.map info below
> //Segment Origin Size
> Root Code 00:0000 0033c0
> Root Data 00:6030 ffff9ab7
> Xmem Code 00:e204 066df9 >
> I have quite few struct types and many instances of them on battery
> backed SRAM. When I read the memory architecture I understood that
> the variables have about 44K space. How can I increase this can get
> it to compile?
> What are the tricks to use space efficiently to allocate variables?
>
> Does XMEM help me to place struct types there, and save me the root
> memory space?. In other words, should I be placing these struct
> types in XMEM? I want the contents to be on battery backed SRAM, so
> if I place them on XMEM would that still count?
>
> Your comments and tips are highly appreciated.
> Regards
> Nil-
Also, since you have a unit with a serial flash on it, you could load
your jpg files to the serial flash. 8.51 has improved integration of
serial flash, including support for a FAT file system (sold
separately for $149).
http://www.rabbitsemiconductor.com/support/techNotes_whitePapers.shtml --- In rabbit-semi@rabb..., "aintnoprobs" <nilkamal@h...>
wrote:
> Hi,
> I am using a RCM 3700 with 512K SRAM and 512K Flash on DC 8.3.
>
> 1. My code declares "#memmap xmem" right on top of the C file.
> 2. I have 221KB of #ximport files. (includes html, jar & jpg files)
> 3. *.bin file comes to 435KB.
>
> When I have disabled "seperate I & D space " and compile to a bin
> file I get the following error.
> "Out of variable data space", which produces the below *.map info.
> //Segment Origin Size
> Root Code 00:0000 0041cd
> Root Data b1:5fb4 ffff9c3b
> Xmem Code f9:e1c4 04c48c >
>
> When I enable "seperate I & D space" and compile to a bin file I
get
> the following error.
> "Out of xmem code space, use a larger ROM/RAM", which produces the
> *.map info below
> //Segment Origin Size
> Root Code 00:0000 0033c0
> Root Data 00:6030 ffff9ab7
> Xmem Code 00:e204 066df9 >
> I have quite few struct types and many instances of them on battery
> backed SRAM. When I read the memory architecture I understood that
> the variables have about 44K space. How can I increase this can get
> it to compile?
> What are the tricks to use space efficiently to allocate variables?
>
> Does XMEM help me to place struct types there, and save me the root
> memory space?. In other words, should I be placing these struct
> types in XMEM? I want the contents to be on battery backed SRAM, so
> if I place them on XMEM would that still count?
>
> Your comments and tips are highly appreciated.
> Regards
> Nil-
Reply by ●June 17, 20042004-06-17
Keep in mind that with separate I&D enabled, if you don't use root
code
space, you lose it. Still keep #memmap xmem, but go about forcing
functions here and there into root. You have 52K of root code space, of
which you are only using 13K according to your post showing a size of 33C0.
The size of 66df9 has 52K added to it for root code, 16K root constants
(it appears DATAORG=0x4000, although by default it is 0x3000), and 32K for
the user block, and that does indeed put you right at the 512K limit.
You mention a lot of #ximport's. I don't know if ZWorld allows an
ximported file to cross from one flash into another. I don't see why not,
but there is a sacred boundary between the two blocks of memory for no
apparent reason. I suspect that you may be hurt by a large #ximport that
doesn't quite fit on the first flash, so it gets placed on the second flash
and leaves a large hole in the xmem space. You could try adjusting the
placement of your #ximport statements--maybe at the end of your code,
although that has a few problems of trying to access things that aren't
defined yet, although it can be worked around.
Be sure to use up that 52K root space when using separate I&D--xmem
functions will not be placed in that block, so don't let it go to waste.
You could also try #memmap anymem NNNN. This is actually the default
compile method, with NNNN 00. This will cause the root space to get
filled up until within 2000 bytes of running out; then it places everything
in xmem unless specifically requested to be in root. Make this number as
small as possible without running out of root code space.
space, you lose it. Still keep #memmap xmem, but go about forcing
functions here and there into root. You have 52K of root code space, of
which you are only using 13K according to your post showing a size of 33C0.
The size of 66df9 has 52K added to it for root code, 16K root constants
(it appears DATAORG=0x4000, although by default it is 0x3000), and 32K for
the user block, and that does indeed put you right at the 512K limit.
You mention a lot of #ximport's. I don't know if ZWorld allows an
ximported file to cross from one flash into another. I don't see why not,
but there is a sacred boundary between the two blocks of memory for no
apparent reason. I suspect that you may be hurt by a large #ximport that
doesn't quite fit on the first flash, so it gets placed on the second flash
and leaves a large hole in the xmem space. You could try adjusting the
placement of your #ximport statements--maybe at the end of your code,
although that has a few problems of trying to access things that aren't
defined yet, although it can be worked around.
Be sure to use up that 52K root space when using separate I&D--xmem
functions will not be placed in that block, so don't let it go to waste.
You could also try #memmap anymem NNNN. This is actually the default
compile method, with NNNN 00. This will cause the root space to get
filled up until within 2000 bytes of running out; then it places everything
in xmem unless specifically requested to be in root. Make this number as
small as possible without running out of root code space.
Reply by ●June 18, 20042004-06-18
Hi,
Thanks for all with prompt replies.
This is the latest situation.
I have a struct of size 128 and have 15 of them declared. I actually
need 30 of them to fulfill my task.
In all instances I am compiling with seperate I&D space DISABLED With 15 of the struct types metioned about the code compiles. As
below.
//Segment Origin Size
Root Code 00:0000 005722
Root Data b1:cbff 006bc3
Xmem Code f8:e000 066598 With 16 of the struct types the compilation fails with out of
variable data space error.
Root Code 00:0000 004757
Root Data b1:5ffe ffff9b0a
Xmem Code f8:eae8 05db22
Can you see what I am doing wrong and where?.
Richard, how do I interpret the above table? the origin column says
xx:xxxx what is the first parameter?
HOw can I manipulate the DATAORG value according the the above data?
CUrrently it is set at 0x6000
I reduced this by intervals of 0x1000 up to 0x3000 and them I get "
Out of root code space, try moving code to XMEM"
Increased it similarily up to 0xB000, then I still get "Out of
variable space"
So I guess its pointless using the DATAORG at this level? I am still confused on how this root, xmem works and where the
variables are go. Currently I have only about four functions that
have "root" in front. The rest I assume is in xmem as #memmap xmem
is defined.
Also, Some of my variable names are fairly long eg:
AnalogueSensorData[40]; Now does it make a diff if I had it as
An_S_Dat[40]; would this allow me more space on Root data/ root code?
I took advice and have done the following to get this far.
* Got rid of unneccessary printf commands
* shorted the needed printf lines
* read Read technical note 238 at
http://www.rabbitsemiconductor.com/documentation/docs/refs/TN238/TN23
8.htm
* Hoping to reduce the size of ximports. (currently at 221KB)
Any other thoughts?.
Would really like to thank every one replied and read this thread.
Regards
Nil --- In rabbit-semi@rabb..., "Robert Richter" <robertr@h...>
wrote:
> Keep in mind that with separate I&D enabled, if you don't use root
code
> space, you lose it. Still keep #memmap xmem, but go about forcing
> functions here and there into root. You have 52K of root code
space, of
> which you are only using 13K according to your post showing a size
of 33C0.
>
> The size of 66df9 has 52K added to it for root code, 16K root
constants
> (it appears DATAORG=0x4000, although by default it is 0x3000), and
32K for
> the user block, and that does indeed put you right at the 512K
limit.
>
> You mention a lot of #ximport's. I don't know if ZWorld allows an
> ximported file to cross from one flash into another. I don't see
why not,
> but there is a sacred boundary between the two blocks of memory
for no
> apparent reason. I suspect that you may be hurt by a large
#ximport that
> doesn't quite fit on the first flash, so it gets placed on the
second flash
> and leaves a large hole in the xmem space. You could try
adjusting the
> placement of your #ximport statements--maybe at the end of your
code,
> although that has a few problems of trying to access things that
aren't
> defined yet, although it can be worked around.
>
> Be sure to use up that 52K root space when using separate I&D--xmem
> functions will not be placed in that block, so don't let it go to
waste.
> You could also try #memmap anymem NNNN. This is actually the
default
> compile method, with NNNN 00. This will cause the root space to
get
> filled up until within 2000 bytes of running out; then it places
everything
> in xmem unless specifically requested to be in root. Make this
number as
> small as possible without running out of root code space.
Thanks for all with prompt replies.
This is the latest situation.
I have a struct of size 128 and have 15 of them declared. I actually
need 30 of them to fulfill my task.
In all instances I am compiling with seperate I&D space DISABLED With 15 of the struct types metioned about the code compiles. As
below.
//Segment Origin Size
Root Code 00:0000 005722
Root Data b1:cbff 006bc3
Xmem Code f8:e000 066598 With 16 of the struct types the compilation fails with out of
variable data space error.
Root Code 00:0000 004757
Root Data b1:5ffe ffff9b0a
Xmem Code f8:eae8 05db22
Can you see what I am doing wrong and where?.
Richard, how do I interpret the above table? the origin column says
xx:xxxx what is the first parameter?
HOw can I manipulate the DATAORG value according the the above data?
CUrrently it is set at 0x6000
I reduced this by intervals of 0x1000 up to 0x3000 and them I get "
Out of root code space, try moving code to XMEM"
Increased it similarily up to 0xB000, then I still get "Out of
variable space"
So I guess its pointless using the DATAORG at this level? I am still confused on how this root, xmem works and where the
variables are go. Currently I have only about four functions that
have "root" in front. The rest I assume is in xmem as #memmap xmem
is defined.
Also, Some of my variable names are fairly long eg:
AnalogueSensorData[40]; Now does it make a diff if I had it as
An_S_Dat[40]; would this allow me more space on Root data/ root code?
I took advice and have done the following to get this far.
* Got rid of unneccessary printf commands
* shorted the needed printf lines
* read Read technical note 238 at
http://www.rabbitsemiconductor.com/documentation/docs/refs/TN238/TN23
8.htm
* Hoping to reduce the size of ximports. (currently at 221KB)
Any other thoughts?.
Would really like to thank every one replied and read this thread.
Regards
Nil --- In rabbit-semi@rabb..., "Robert Richter" <robertr@h...>
wrote:
> Keep in mind that with separate I&D enabled, if you don't use root
code
> space, you lose it. Still keep #memmap xmem, but go about forcing
> functions here and there into root. You have 52K of root code
space, of
> which you are only using 13K according to your post showing a size
of 33C0.
>
> The size of 66df9 has 52K added to it for root code, 16K root
constants
> (it appears DATAORG=0x4000, although by default it is 0x3000), and
32K for
> the user block, and that does indeed put you right at the 512K
limit.
>
> You mention a lot of #ximport's. I don't know if ZWorld allows an
> ximported file to cross from one flash into another. I don't see
why not,
> but there is a sacred boundary between the two blocks of memory
for no
> apparent reason. I suspect that you may be hurt by a large
#ximport that
> doesn't quite fit on the first flash, so it gets placed on the
second flash
> and leaves a large hole in the xmem space. You could try
adjusting the
> placement of your #ximport statements--maybe at the end of your
code,
> although that has a few problems of trying to access things that
aren't
> defined yet, although it can be worked around.
>
> Be sure to use up that 52K root space when using separate I&D--xmem
> functions will not be placed in that block, so don't let it go to
waste.
> You could also try #memmap anymem NNNN. This is actually the
default
> compile method, with NNNN 00. This will cause the root space to
get
> filled up until within 2000 bytes of running out; then it places
everything
> in xmem unless specifically requested to be in root. Make this
number as
> small as possible without running out of root code space.
Reply by ●June 18, 20042004-06-18
----------
> From: aintnoprobs <nilkamal@nilk...>
> To: rabbit-semi@rabb...
> Subject: [rabbit-semi] Re: Out of variable data space & Out of xmem code
space, use a larger ROM/RAM
> Date: Thursday, June 17, 2004 8:53 PM
>
> Hi,
> Thanks for all with prompt replies.
> This is the latest situation.
>
> I have a struct of size 128 and have 15 of them declared. I actually
> need 30 of them to fulfill my task.
> In all instances I am compiling with seperate I&D space DISABLED > With 15 of the struct types metioned about the code compiles. As
> below.
>
> //Segment Origin Size
> Root Code 00:0000 005722
> Root Data b1:cbff 006bc3
> Xmem Code f8:e000 066598 > With 16 of the struct types the compilation fails with out of
> variable data space error.
>
> Root Code 00:0000 004757
> Root Data b1:5ffe ffff9b0a
> Xmem Code f8:eae8 05db22
>
> Can you see what I am doing wrong and where?.
> Richard, how do I interpret the above table? the origin column says
> xx:xxxx what is the first parameter?
>
> HOw can I manipulate the DATAORG value according the the above data?
> CUrrently it is set at 0x6000
> I reduced this by intervals of 0x1000 up to 0x3000 and them I get "
> Out of root code space, try moving code to XMEM"
> Increased it similarily up to 0xB000, then I still get "Out of
> variable space"
> So I guess its pointless using the DATAORG at this level? > I am still confused on how this root, xmem works and where the
> variables are go. Currently I have only about four functions that
> have "root" in front. The rest I assume is in xmem as #memmap xmem
> is defined.
>
> Also, Some of my variable names are fairly long eg:
> AnalogueSensorData[40]; Now does it make a diff if I had it as
> An_S_Dat[40]; would this allow me more space on Root data/ root code? >
> I took advice and have done the following to get this far.
> * Got rid of unneccessary printf commands
> * shorted the needed printf lines
> * read Read technical note 238 at
> http://www.rabbitsemiconductor.com/documentation/docs/refs/TN238/TN23
> 8.htm
> * Hoping to reduce the size of ximports. (currently at 221KB)
>
> Any other thoughts?.
> Would really like to thank every one replied and read this thread.
> Regards
> Nil
Well, the way memory works is different depending upon whether separate I&D
is enabled or disabled.
The prefix in xx.xxxx simply tells where in physical memory the memory
segment points to. All segments on the Rabbit except the root code segment
can be mapped to anywhere in physical memory.
With Separate I&D off, DATAORG is the boundary between root code and root
variables. Root code also includes root constants, such as string
literals, and any array or structure initialization (which in DC requires a
different constant array for initializing).
Let's take DATAORG=0x6000. From physical address of 00000 to 05FFF, the
flash is mapped to this segment of memory. The root memory from 0x6000 to
0xCFFF is mapped to RAM, and the B1:CCFF tells where in RAM it is mapped
to. Since only 64K is accessible directly from memory, xmem is a way of
accessing the entire memory, but a bit inconvenient. There is an 8K
segment known as the XPC segment from e000-ffff. This segment has a CPU
register called XPC that tells where in the one meg space this window
points to. XMEM code runs within this 8K window.
Now, decreasing DATAORG tells the Rabbit where the boundary between using
RAM and using FLASH is. If you lower it, you get more RAM, at the expense
of less flash. As I pointed out in a previous post, the area of flash
reserved for root code will not put XMEM code in that area of flash.
With separate I&D enabled, 52K of flash is set aside for root code.
DATAORG tells how much flash to set aside for root constants, string
literals, and initialized arrays and structures. The root constant and
root code are in different areas of flash. XMEM allows the rest of the
flash to be accessed for code, but through the little 8K window.
One thing that hurts a lot is string literals. They use up root code
space, even when using separate I&D. In the files section, I have a macro
that puts them in xmem. You use it like this:
void foo() {
auto char Buffer[100];
SetXVar(Buffer, "This is a string literal\n");
printf(Buffer);
} SetXVar is a macro that causes the line to be expanded in such a manner
that your string literals do not use up root code space. The macro
actually expands in assembly to look like this:
#asm
c Buffer; // Put the address of where we want our string in the HL
register
call SetXVar2
db "This is a string literal\n", 0
#endasm
Since this is part of the code, it goes into XMEM with the code--what
SetXVar2 does is looks at where it was called from, copies the string
following the return address into the variable you specify, and then
modifies the return address to point to the code after the NULL terminating
zero. Obviously, executing string literals as code will cause
unpredictable results, but SetXVar doesn't do that.
Since you are so tight on memory, I hate to say "Move your data into XMEM",
because that may cause your code to grow too much. Look at how many string
literals you have, and if you use this macro, you eliminate that many bytes
of root code--If you can eliminate enough bytes, you can drop DATAORG by 4K
(0x1000)--and maybe get it small enough to fit all your data.
Reply by ●June 18, 20042004-06-18
Just looking at your problem from a different
angle, if you are making a webserver on a LAN why don't you move your html,
jpeg files to another server and let the Rabbit have simple, redirect pages.
That way you can update the web pages without having to reflash the Rabbit and
also reduce the memory usage. - Just a thought!
----- Original Message -----From: aintnoprobsTo: r...@yahoogroups.comSent: Friday, June 18, 2004 4:53 AMSubject: [rabbit-semi] Re: Out of variable data space & Out of xmem code space, use a larger ROM/RAMHi,
Thanks for all with prompt replies.
This is the latest situation.
I have a struct of size 128 and have 15 of them declared. I actually
need 30 of them to fulfill my task.
In all instances I am compiling with seperate I&D space DISABLEDWith 15 of the struct types metioned about the code compiles. As
below.
//Segment Origin Size
Root Code 00:0000 005722
Root Data b1:cbff 006bc3
Xmem Code f8:e000 066598With 16 of the struct types the compilation fails with out of
variable data space error.
Root Code 00:0000 004757
Root Data b1:5ffe ffff9b0a
Xmem Code f8:eae8 05db22
Can you see what I am doing wrong and where?.
Richard, how do I interpret the above table? the origin column says
xx:xxxx what is the first parameter?
HOw can I manipulate the DATAORG value according the the above data?
CUrrently it is set at 0x6000
I reduced this by intervals of 0x1000 up to 0x3000 and them I get "
Out of root code space, try moving code to XMEM"
Increased it similarily up to 0xB000, then I still get "Out of
variable space"
So I guess its pointless using the DATAORG at this level?I am still confused on how this root, xmem works and where the
variables are go. Currently I have only about four functions that
have "root" in front. The rest I assume is in xmem as #memmap xmem
is defined.
Also, Some of my variable names are fairly long eg:
AnalogueSensorData[40]; Now does it make a diff if I had it as
An_S_Dat[40]; would this allow me more space on Root data/ root code?
I took advice and have done the following to get this far.
* Got rid of unneccessary printf commands
* shorted the needed printf lines
* read Read technical note 238 at
http://www.rabbitsemiconductor.com/documentation/docs/refs/TN238/TN23
8.htm
* Hoping to reduce the size of ximports. (currently at 221KB)
Any other thoughts?.
Would really like to thank every one replied and read this thread.
Regards
Nil--- In r...@yahoogroups.com, "Robert Richter" <robertr@h...>
wrote:
> Keep in mind that with separate I&D enabled, if you don't use root
code
> space, you lose it. Still keep #memmap xmem, but go about forcing
> functions here and there into root. You have 52K of root code
space, of
> which you are only using 13K according to your post showing a size
of 33C0.
>
> The size of 66df9 has 52K added to it for root code, 16K root
constants
> (it appears DATAORG=0x4000, although by default it is 0x3000), and
32K for
> the user block, and that does indeed put you right at the 512K
limit.
>
> You mention a lot of #ximport's. I don't know if ZWorld allows an
> ximported file to cross from one flash into another. I don't see
why not,
> but there is a sacred boundary between the two blocks of memory
for no
> apparent reason. I suspect that you may be hurt by a large
#ximport that
> doesn't quite fit on the first flash, so it gets placed on the
second flash
> and leaves a large hole in the xmem space. You could try
adjusting the
> placement of your #ximport statements--maybe at the end of your
code,
> although that has a few problems of trying to access things that
aren't
> defined yet, although it can be worked around.
>
> Be sure to use up that 52K root space when using separate I&D--xmem
> functions will not be placed in that block, so don't let it go to
waste.
> You could also try #memmap anymem NNNN. This is actually the
default
> compile method, with NNNN 00. This will cause the root space to
get
> filled up until within 2000 bytes of running out; then it places
everything
> in xmem unless specifically requested to be in root. Make this
number as
> small as possible without running out of root code space.
Reply by ●June 18, 20042004-06-18
When DC's compilation fails, the reported information for code and data
sizes may not be (and isn't, in my experience) accurate. The information
from your application's successful compile with 15 structs should be
correct though. According to that information, your application used
0x6BC3 bytes of root data space including the 15 structs.
Adding another 128 byte struct would make 0x6C43 bytes of root data, but
(assuming no changes to RabbitBios.c's orgs definitions, flash compile mode
and shared I&D space) the total available root data space is only 0x6C00
(0xD000 - 0x200 - 0x200 - 0x6000 for bottom of stack, bottom of interrupt
vectors, bottom of watch code, and bottom of the root data org,
respectively. The preceding numbers are taken from the following macro
definition: "#define ROOTDATAORG
STACKORG-(0x0200+WATCHCODESIZE)-BBROOTDATASIZE-0x1 // Beginning of root
data" in RabbitBios.c.)
You could regain a small amount of root data space by decreasing the amount
reserved for watch code, but you will need to trim some of your
application's other root data items if you want to fit 17 more 128 byte
structs into shared I&D space's root data area.
You may want to consider placing the array of structs in xmem, and then
shuffling only one or two or a few at a time, as they are needed, into root
data memory.
At 08:53 PM 6/17/2004, you wrote:
>Hi,
>Thanks for all with prompt replies.
>This is the latest situation.
>
>I have a struct of size 128 and have 15 of them declared. I actually
>need 30 of them to fulfill my task.
>In all instances I am compiling with seperate I&D space DISABLED >With 15 of the struct types metioned about the code compiles. As
>below.
>
>//Segment Origin Size
>Root Code 00:0000 005722
>Root Data b1:cbff 006bc3
>Xmem Code f8:e000 066598 >With 16 of the struct types the compilation fails with out of
>variable data space error.
>
>Root Code 00:0000 004757
>Root Data b1:5ffe ffff9b0a
>Xmem Code f8:eae8 05db22
>
>Can you see what I am doing wrong and where?.
>Richard, how do I interpret the above table? the origin column says
>xx:xxxx what is the first parameter?
>
>HOw can I manipulate the DATAORG value according the the above data?
>CUrrently it is set at 0x6000
>I reduced this by intervals of 0x1000 up to 0x3000 and them I get "
>Out of root code space, try moving code to XMEM"
>Increased it similarily up to 0xB000, then I still get "Out of
>variable space"
>So I guess its pointless using the DATAORG at this level? >I am still confused on how this root, xmem works and where the
>variables are go. Currently I have only about four functions that
>have "root" in front. The rest I assume is in xmem as #memmap xmem
>is defined.
>
>Also, Some of my variable names are fairly long eg:
>AnalogueSensorData[40]; Now does it make a diff if I had it as
>An_S_Dat[40]; would this allow me more space on Root data/ root code? >
>I took advice and have done the following to get this far.
>* Got rid of unneccessary printf commands
>* shorted the needed printf lines
>* read Read technical note 238 at
>http://www.rabbitsemiconductor.com/documentation/docs/refs/TN238/TN23
>8.htm
>* Hoping to reduce the size of ximports. (currently at 221KB)
>
>Any other thoughts?.
>Would really like to thank every one replied and read this thread.
>Regards
>Nil >--- In rabbit-semi@rabb..., "Robert Richter" <robertr@h...>
>wrote:
> > Keep in mind that with separate I&D enabled, if you don't use root
>code
> > space, you lose it. Still keep #memmap xmem, but go about forcing
> > functions here and there into root. You have 52K of root code
>space, of
> > which you are only using 13K according to your post showing a size
>of 33C0.
> >
> > The size of 66df9 has 52K added to it for root code, 16K root
>constants
> > (it appears DATAORG=0x4000, although by default it is 0x3000), and
>32K for
> > the user block, and that does indeed put you right at the 512K
>limit.
> >
> > You mention a lot of #ximport's. I don't know if ZWorld allows an
> > ximported file to cross from one flash into another. I don't see
>why not,
> > but there is a sacred boundary between the two blocks of memory
>for no
> > apparent reason. I suspect that you may be hurt by a large
>#ximport that
> > doesn't quite fit on the first flash, so it gets placed on the
>second flash
> > and leaves a large hole in the xmem space. You could try
>adjusting the
> > placement of your #ximport statements--maybe at the end of your
>code,
> > although that has a few problems of trying to access things that
>aren't
> > defined yet, although it can be worked around.
> >
> > Be sure to use up that 52K root space when using separate I&D--xmem
> > functions will not be placed in that block, so don't let it go to
>waste.
> > You could also try #memmap anymem NNNN. This is actually the
>default
> > compile method, with NNNN 00. This will cause the root space to
>get
> > filled up until within 2000 bytes of running out; then it places
>everything
> > in xmem unless specifically requested to be in root. Make this
>number as
> > small as possible without running out of root code space. >Yahoo! Groups Links >
>
sizes may not be (and isn't, in my experience) accurate. The information
from your application's successful compile with 15 structs should be
correct though. According to that information, your application used
0x6BC3 bytes of root data space including the 15 structs.
Adding another 128 byte struct would make 0x6C43 bytes of root data, but
(assuming no changes to RabbitBios.c's orgs definitions, flash compile mode
and shared I&D space) the total available root data space is only 0x6C00
(0xD000 - 0x200 - 0x200 - 0x6000 for bottom of stack, bottom of interrupt
vectors, bottom of watch code, and bottom of the root data org,
respectively. The preceding numbers are taken from the following macro
definition: "#define ROOTDATAORG
STACKORG-(0x0200+WATCHCODESIZE)-BBROOTDATASIZE-0x1 // Beginning of root
data" in RabbitBios.c.)
You could regain a small amount of root data space by decreasing the amount
reserved for watch code, but you will need to trim some of your
application's other root data items if you want to fit 17 more 128 byte
structs into shared I&D space's root data area.
You may want to consider placing the array of structs in xmem, and then
shuffling only one or two or a few at a time, as they are needed, into root
data memory.
At 08:53 PM 6/17/2004, you wrote:
>Hi,
>Thanks for all with prompt replies.
>This is the latest situation.
>
>I have a struct of size 128 and have 15 of them declared. I actually
>need 30 of them to fulfill my task.
>In all instances I am compiling with seperate I&D space DISABLED >With 15 of the struct types metioned about the code compiles. As
>below.
>
>//Segment Origin Size
>Root Code 00:0000 005722
>Root Data b1:cbff 006bc3
>Xmem Code f8:e000 066598 >With 16 of the struct types the compilation fails with out of
>variable data space error.
>
>Root Code 00:0000 004757
>Root Data b1:5ffe ffff9b0a
>Xmem Code f8:eae8 05db22
>
>Can you see what I am doing wrong and where?.
>Richard, how do I interpret the above table? the origin column says
>xx:xxxx what is the first parameter?
>
>HOw can I manipulate the DATAORG value according the the above data?
>CUrrently it is set at 0x6000
>I reduced this by intervals of 0x1000 up to 0x3000 and them I get "
>Out of root code space, try moving code to XMEM"
>Increased it similarily up to 0xB000, then I still get "Out of
>variable space"
>So I guess its pointless using the DATAORG at this level? >I am still confused on how this root, xmem works and where the
>variables are go. Currently I have only about four functions that
>have "root" in front. The rest I assume is in xmem as #memmap xmem
>is defined.
>
>Also, Some of my variable names are fairly long eg:
>AnalogueSensorData[40]; Now does it make a diff if I had it as
>An_S_Dat[40]; would this allow me more space on Root data/ root code? >
>I took advice and have done the following to get this far.
>* Got rid of unneccessary printf commands
>* shorted the needed printf lines
>* read Read technical note 238 at
>http://www.rabbitsemiconductor.com/documentation/docs/refs/TN238/TN23
>8.htm
>* Hoping to reduce the size of ximports. (currently at 221KB)
>
>Any other thoughts?.
>Would really like to thank every one replied and read this thread.
>Regards
>Nil >--- In rabbit-semi@rabb..., "Robert Richter" <robertr@h...>
>wrote:
> > Keep in mind that with separate I&D enabled, if you don't use root
>code
> > space, you lose it. Still keep #memmap xmem, but go about forcing
> > functions here and there into root. You have 52K of root code
>space, of
> > which you are only using 13K according to your post showing a size
>of 33C0.
> >
> > The size of 66df9 has 52K added to it for root code, 16K root
>constants
> > (it appears DATAORG=0x4000, although by default it is 0x3000), and
>32K for
> > the user block, and that does indeed put you right at the 512K
>limit.
> >
> > You mention a lot of #ximport's. I don't know if ZWorld allows an
> > ximported file to cross from one flash into another. I don't see
>why not,
> > but there is a sacred boundary between the two blocks of memory
>for no
> > apparent reason. I suspect that you may be hurt by a large
>#ximport that
> > doesn't quite fit on the first flash, so it gets placed on the
>second flash
> > and leaves a large hole in the xmem space. You could try
>adjusting the
> > placement of your #ximport statements--maybe at the end of your
>code,
> > although that has a few problems of trying to access things that
>aren't
> > defined yet, although it can be worked around.
> >
> > Be sure to use up that 52K root space when using separate I&D--xmem
> > functions will not be placed in that block, so don't let it go to
>waste.
> > You could also try #memmap anymem NNNN. This is actually the
>default
> > compile method, with NNNN 00. This will cause the root space to
>get
> > filled up until within 2000 bytes of running out; then it places
>everything
> > in xmem unless specifically requested to be in root. Make this
>number as
> > small as possible without running out of root code space. >Yahoo! Groups Links >
>
