When a DC compile runs out of code or data memory, the numbers shown may
not be accurate. For example, notice that the root data sizes quoted below
are negative numbers displayed in hexadecimal format.
In any case, for compiling with separate I&D space enabled, it is very
often a good idea to ensure that an application does ***not*** declare
"#memmap xmem" anywhere. When #memmap xmem is used, DC will not
compile C
functions to the root code org unless they are explicitly declared
root. What may happen is that a large percentage of the root code org is
empty, even though a large application has overfilled the xmem code org
(and so DC generates an out of xmem space error).
At 04: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
>
>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-
>
>
>Yahoo! Groups Links
>
>
Out of variable data space & Out of xmem code space, use a larger ROM/RAM
Started by ●June 17, 2004
Reply by ●June 18, 20042004-06-18
Reply by ●June 18, 20042004-06-18
One other tip occurs to me. When #ximporting files and compiling using a
mode that has more than one xmem code org (IE: separate I&D space enabled,
USE_2NDFLASH_CODE enabled, or both), it is often possible to "recover" some
xmem code space by "resuming" to the first xmem code org immediately after
the files have been #ximported.
For example, with separate I&D space (with or without USE_2NDFLASH_CODE)
enabled the directive is:
#xcodorg sid_xmemcode resume
For shared I&D space with USE_2NDFLASH_CODE enabled, the directive is:
#xcodorg xmemcode resume
If #ximporting a large file caused Dynamic C to move on to the next xmem
code org, the appropriate one of the above directives may help to recover
xmem code space that would otherwise be wasted. If there isn't available
space at the end of an earlier xmem code org, then a too-large application
will still run out of memory, of course.
At 12:17 PM 6/18/2004, you wrote:
>When a DC compile runs out of code or data memory, the numbers shown may
>not be accurate. For example, notice that the root data sizes quoted below
>are negative numbers displayed in hexadecimal format.
>
>In any case, for compiling with separate I&D space enabled, it is very
>often a good idea to ensure that an application does ***not*** declare
>"#memmap xmem" anywhere. When #memmap xmem is used, DC will not compile C
>functions to the root code org unless they are explicitly declared
>root. What may happen is that a large percentage of the root code org is
>empty, even though a large application has overfilled the xmem code org
>(and so DC generates an out of xmem space error).
>
>At 04: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
> >
> >
> >
> >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-
mode that has more than one xmem code org (IE: separate I&D space enabled,
USE_2NDFLASH_CODE enabled, or both), it is often possible to "recover" some
xmem code space by "resuming" to the first xmem code org immediately after
the files have been #ximported.
For example, with separate I&D space (with or without USE_2NDFLASH_CODE)
enabled the directive is:
#xcodorg sid_xmemcode resume
For shared I&D space with USE_2NDFLASH_CODE enabled, the directive is:
#xcodorg xmemcode resume
If #ximporting a large file caused Dynamic C to move on to the next xmem
code org, the appropriate one of the above directives may help to recover
xmem code space that would otherwise be wasted. If there isn't available
space at the end of an earlier xmem code org, then a too-large application
will still run out of memory, of course.
At 12:17 PM 6/18/2004, you wrote:
>When a DC compile runs out of code or data memory, the numbers shown may
>not be accurate. For example, notice that the root data sizes quoted below
>are negative numbers displayed in hexadecimal format.
>
>In any case, for compiling with separate I&D space enabled, it is very
>often a good idea to ensure that an application does ***not*** declare
>"#memmap xmem" anywhere. When #memmap xmem is used, DC will not compile C
>functions to the root code org unless they are explicitly declared
>root. What may happen is that a large percentage of the root code org is
>empty, even though a large application has overfilled the xmem code org
>(and so DC generates an out of xmem space error).
>
>At 04: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
> >
> >
> >
> >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 18, 20042004-06-18
With separate I&D, there are three segments. Do you need to know which
was
was active before the failed #ximport moved you to the next segment. Will
this fail if you use the #xcodorg xmemcode resume? Without separate I&D,
you have two segments--one on the first flash chip, then you skip around
the ID block and another one on the second segment. If you resume and the
blocks are already filled up, will it just cleanly jump to the next
available segment?
It sounds like a feature request is in order--make DC do this
automatically. ----------
> From: Bruce Isted <bisted@bist...>
> To: rabbit-semi@rabb...
> Subject: Re: [rabbit-semi] Out of variable data space & Out of xmemcode
space, use a larger ROM/RAM
> Date: Friday, June 18, 2004 12:48 PM
>
> One other tip occurs to me. When #ximporting files and compiling using a
> mode that has more than one xmem code org (IE: separate I&D space
enabled,
> USE_2NDFLASH_CODE enabled, or both), it is often possible to "recover"
some
> xmem code space by "resuming" to the first xmem code org immediately
after
> the files have been #ximported.
>
> For example, with separate I&D space (with or without USE_2NDFLASH_CODE)
> enabled the directive is:
>
> #xcodorg sid_xmemcode resume
>
> For shared I&D space with USE_2NDFLASH_CODE enabled, the directive is:
>
> #xcodorg xmemcode resume
>
> If #ximporting a large file caused Dynamic C to move on to the next xmem
> code org, the appropriate one of the above directives may help to recover
> xmem code space that would otherwise be wasted. If there isn't available
> space at the end of an earlier xmem code org, then a too-large
application
> will still run out of memory, of course.
>
> At 12:17 PM 6/18/2004, you wrote:
> >When a DC compile runs out of code or data memory, the numbers shown may
> >not be accurate. For example, notice that the root data sizes quoted
below
> >are negative numbers displayed in hexadecimal format.
> >
> >In any case, for compiling with separate I&D space enabled, it is very
> >often a good idea to ensure that an application does ***not*** declare
> >"#memmap xmem" anywhere. When #memmap xmem is used, DC will not compile
C
> >functions to the root code org unless they are explicitly declared
> >root. What may happen is that a large percentage of the root code org
is
> >empty, even though a large application has overfilled the xmem code org
> >(and so DC generates an out of xmem space error).
> >
> >At 04: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
> > >
> > >
> > >
> > >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- >
> Yahoo! Groups Links
was active before the failed #ximport moved you to the next segment. Will
this fail if you use the #xcodorg xmemcode resume? Without separate I&D,
you have two segments--one on the first flash chip, then you skip around
the ID block and another one on the second segment. If you resume and the
blocks are already filled up, will it just cleanly jump to the next
available segment?
It sounds like a feature request is in order--make DC do this
automatically. ----------
> From: Bruce Isted <bisted@bist...>
> To: rabbit-semi@rabb...
> Subject: Re: [rabbit-semi] Out of variable data space & Out of xmemcode
space, use a larger ROM/RAM
> Date: Friday, June 18, 2004 12:48 PM
>
> One other tip occurs to me. When #ximporting files and compiling using a
> mode that has more than one xmem code org (IE: separate I&D space
enabled,
> USE_2NDFLASH_CODE enabled, or both), it is often possible to "recover"
some
> xmem code space by "resuming" to the first xmem code org immediately
after
> the files have been #ximported.
>
> For example, with separate I&D space (with or without USE_2NDFLASH_CODE)
> enabled the directive is:
>
> #xcodorg sid_xmemcode resume
>
> For shared I&D space with USE_2NDFLASH_CODE enabled, the directive is:
>
> #xcodorg xmemcode resume
>
> If #ximporting a large file caused Dynamic C to move on to the next xmem
> code org, the appropriate one of the above directives may help to recover
> xmem code space that would otherwise be wasted. If there isn't available
> space at the end of an earlier xmem code org, then a too-large
application
> will still run out of memory, of course.
>
> At 12:17 PM 6/18/2004, you wrote:
> >When a DC compile runs out of code or data memory, the numbers shown may
> >not be accurate. For example, notice that the root data sizes quoted
below
> >are negative numbers displayed in hexadecimal format.
> >
> >In any case, for compiling with separate I&D space enabled, it is very
> >often a good idea to ensure that an application does ***not*** declare
> >"#memmap xmem" anywhere. When #memmap xmem is used, DC will not compile
C
> >functions to the root code org unless they are explicitly declared
> >root. What may happen is that a large percentage of the root code org
is
> >empty, even though a large application has overfilled the xmem code org
> >(and so DC generates an out of xmem space error).
> >
> >At 04: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
> > >
> > >
> > >
> > >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- >
> Yahoo! Groups Links
Reply by ●June 18, 20042004-06-18
On the occasions that I have tried this, when there was not enough space
available in the "resumed" xmem code org then Dynamic C has cleanly jumped
to the next available xmem code org. I have made an entry for "automating"
this in our feature request database, but I have no idea if/when we might
expect to see it implemented.
At 01:31 PM 6/18/2004, you wrote:
>With separate I&D, there are three segments. Do you need to know which was
>was active before the failed #ximport moved you to the next segment. Will
>this fail if you use the #xcodorg xmemcode resume? Without separate I&D,
>you have two segments--one on the first flash chip, then you skip around
>the ID block and another one on the second segment. If you resume and the
>blocks are already filled up, will it just cleanly jump to the next
>available segment?
>
>It sounds like a feature request is in order--make DC do this
>automatically. >----------
> > From: Bruce Isted <bisted@bist...>
> > To: rabbit-semi@rabb...
> > Subject: Re: [rabbit-semi] Out of variable data space & Out of xmemcode
>space, use a larger ROM/RAM
> > Date: Friday, June 18, 2004 12:48 PM
> >
> > One other tip occurs to me. When #ximporting files and compiling using a
>
> > mode that has more than one xmem code org (IE: separate I&D space
>enabled,
> > USE_2NDFLASH_CODE enabled, or both), it is often possible to "recover"
>some
> > xmem code space by "resuming" to the first xmem code org immediately
>after
> > the files have been #ximported.
> >
> > For example, with separate I&D space (with or without USE_2NDFLASH_CODE)
> > enabled the directive is:
> >
> > #xcodorg sid_xmemcode resume
> >
> > For shared I&D space with USE_2NDFLASH_CODE enabled, the directive is:
> >
> > #xcodorg xmemcode resume
> >
> > If #ximporting a large file caused Dynamic C to move on to the next xmem
> > code org, the appropriate one of the above directives may help to recover
>
> > xmem code space that would otherwise be wasted. If there isn't available
>
> > space at the end of an earlier xmem code org, then a too-large
>application
> > will still run out of memory, of course.
> >
> > At 12:17 PM 6/18/2004, you wrote:
> > >When a DC compile runs out of code or data memory, the numbers shown may
> > >not be accurate. For example, notice that the root data sizes quoted
>below
> > >are negative numbers displayed in hexadecimal format.
> > >
> > >In any case, for compiling with separate I&D space enabled, it is very
> > >often a good idea to ensure that an application does ***not*** declare
> > >"#memmap xmem" anywhere. When #memmap xmem is used, DC will not compile
>C
> > >functions to the root code org unless they are explicitly declared
> > >root. What may happen is that a large percentage of the root code org
>is
> > >empty, even though a large application has overfilled the xmem code org
> > >(and so DC generates an out of xmem space error).
> > >
> > >At 04: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
> > > >
> > > >
> > > >
> > > >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-
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>Yahoo! Groups Links >
>
available in the "resumed" xmem code org then Dynamic C has cleanly jumped
to the next available xmem code org. I have made an entry for "automating"
this in our feature request database, but I have no idea if/when we might
expect to see it implemented.
At 01:31 PM 6/18/2004, you wrote:
>With separate I&D, there are three segments. Do you need to know which was
>was active before the failed #ximport moved you to the next segment. Will
>this fail if you use the #xcodorg xmemcode resume? Without separate I&D,
>you have two segments--one on the first flash chip, then you skip around
>the ID block and another one on the second segment. If you resume and the
>blocks are already filled up, will it just cleanly jump to the next
>available segment?
>
>It sounds like a feature request is in order--make DC do this
>automatically. >----------
> > From: Bruce Isted <bisted@bist...>
> > To: rabbit-semi@rabb...
> > Subject: Re: [rabbit-semi] Out of variable data space & Out of xmemcode
>space, use a larger ROM/RAM
> > Date: Friday, June 18, 2004 12:48 PM
> >
> > One other tip occurs to me. When #ximporting files and compiling using a
>
> > mode that has more than one xmem code org (IE: separate I&D space
>enabled,
> > USE_2NDFLASH_CODE enabled, or both), it is often possible to "recover"
>some
> > xmem code space by "resuming" to the first xmem code org immediately
>after
> > the files have been #ximported.
> >
> > For example, with separate I&D space (with or without USE_2NDFLASH_CODE)
> > enabled the directive is:
> >
> > #xcodorg sid_xmemcode resume
> >
> > For shared I&D space with USE_2NDFLASH_CODE enabled, the directive is:
> >
> > #xcodorg xmemcode resume
> >
> > If #ximporting a large file caused Dynamic C to move on to the next xmem
> > code org, the appropriate one of the above directives may help to recover
>
> > xmem code space that would otherwise be wasted. If there isn't available
>
> > space at the end of an earlier xmem code org, then a too-large
>application
> > will still run out of memory, of course.
> >
> > At 12:17 PM 6/18/2004, you wrote:
> > >When a DC compile runs out of code or data memory, the numbers shown may
> > >not be accurate. For example, notice that the root data sizes quoted
>below
> > >are negative numbers displayed in hexadecimal format.
> > >
> > >In any case, for compiling with separate I&D space enabled, it is very
> > >often a good idea to ensure that an application does ***not*** declare
> > >"#memmap xmem" anywhere. When #memmap xmem is used, DC will not compile
>C
> > >functions to the root code org unless they are explicitly declared
> > >root. What may happen is that a large percentage of the root code org
>is
> > >empty, even though a large application has overfilled the xmem code org
> > >(and so DC generates an out of xmem space error).
> > >
> > >At 04: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
> > > >
> > > >
> > > >
> > > >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-
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>Yahoo! Groups Links >
>
Reply by ●June 20, 20042004-06-20
Hello all,
The replies are great, and I have understood the memory map much
better than before. Thank you for all.
I have cut down significantly on string literals and managed to fit
the code in.
I had HTTP_MAXSERVERS defined as 5 to make the http server fast, and
cut it down to 3, and got some extra space to fit in the struct
types i wanted.
I also got rid of the watchcode space, by definfing it as
WATCHCODESIZE = 0x00; under project options giving me a further
512 bytes of root space. (bios files declares it as 0x200) Using both USE_2NDFLASH_CODE and seperate I & D space was not
allowed. Gave me
"line 2665 : ERROR ZSERVER.LIB : Internal Error: Cannot generate
code around origin directive follows specifier. Please contact Z-
World, Inc.
"
If I have enabled seperate I & D, and cut down on my ximports it
compiles even with the required arrays and having HTTP_MAXSERVERS as
5, but soon as the ximports reach just over 221K , the error is out
of xmem space, use larger ROM/RAM.
What is the max size of XMEM? is it 1 Meg as they specify?.
Also I still don't know if short variable names saves any root space?
Regards.
Nil
--- In rabbit-semi@rabb..., "Robert Richter" <robertr@h...>
wrote:
> With separate I&D, there are three segments. Do you need to know
which was
> was active before the failed #ximport moved you to the next
segment. Will
> this fail if you use the #xcodorg xmemcode resume? Without
separate I&D,
> you have two segments--one on the first flash chip, then you skip
around
> the ID block and another one on the second segment. If you resume
and the
> blocks are already filled up, will it just cleanly jump to the next
> available segment?
>
> It sounds like a feature request is in order--make DC do this
> automatically. > ----------
> > From: Bruce Isted <bisted@z...>
> > To: rabbit-semi@rabb...
> > Subject: Re: [rabbit-semi] Out of variable data space & Out of
xmemcode
> space, use a larger ROM/RAM
> > Date: Friday, June 18, 2004 12:48 PM
> >
> > One other tip occurs to me. When #ximporting files and
compiling using a
>
> > mode that has more than one xmem code org (IE: separate I&D
space
> enabled,
> > USE_2NDFLASH_CODE enabled, or both), it is often possible
to "recover"
> some
> > xmem code space by "resuming" to the first xmem code org
immediately
> after
> > the files have been #ximported.
> >
> > For example, with separate I&D space (with or without
USE_2NDFLASH_CODE)
> > enabled the directive is:
> >
> > #xcodorg sid_xmemcode resume
> >
> > For shared I&D space with USE_2NDFLASH_CODE enabled, the
directive is:
> >
> > #xcodorg xmemcode resume
> >
> > If #ximporting a large file caused Dynamic C to move on to the
next xmem
> > code org, the appropriate one of the above directives may help
to recover
>
> > xmem code space that would otherwise be wasted. If there isn't
available
>
> > space at the end of an earlier xmem code org, then a too-large
> application
> > will still run out of memory, of course.
> >
> > At 12:17 PM 6/18/2004, you wrote:
> > >When a DC compile runs out of code or data memory, the numbers
shown may
> > >not be accurate. For example, notice that the root data sizes
quoted
> below
> > >are negative numbers displayed in hexadecimal format.
> > >
> > >In any case, for compiling with separate I&D space enabled, it
is very
> > >often a good idea to ensure that an application does ***not***
declare
> > >"#memmap xmem" anywhere. When #memmap xmem is used, DC will
not compile
> C
> > >functions to the root code org unless they are explicitly
declared
> > >root. What may happen is that a large percentage of the root
code org
> is
> > >empty, even though a large application has overfilled the xmem
code org
> > >(and so DC generates an out of xmem space error).
> > >
> > >At 04: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
> > > >
> > > >
> > > >
> > > >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-
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
The replies are great, and I have understood the memory map much
better than before. Thank you for all.
I have cut down significantly on string literals and managed to fit
the code in.
I had HTTP_MAXSERVERS defined as 5 to make the http server fast, and
cut it down to 3, and got some extra space to fit in the struct
types i wanted.
I also got rid of the watchcode space, by definfing it as
WATCHCODESIZE = 0x00; under project options giving me a further
512 bytes of root space. (bios files declares it as 0x200) Using both USE_2NDFLASH_CODE and seperate I & D space was not
allowed. Gave me
"line 2665 : ERROR ZSERVER.LIB : Internal Error: Cannot generate
code around origin directive follows specifier. Please contact Z-
World, Inc.
"
If I have enabled seperate I & D, and cut down on my ximports it
compiles even with the required arrays and having HTTP_MAXSERVERS as
5, but soon as the ximports reach just over 221K , the error is out
of xmem space, use larger ROM/RAM.
What is the max size of XMEM? is it 1 Meg as they specify?.
Also I still don't know if short variable names saves any root space?
Regards.
Nil
--- In rabbit-semi@rabb..., "Robert Richter" <robertr@h...>
wrote:
> With separate I&D, there are three segments. Do you need to know
which was
> was active before the failed #ximport moved you to the next
segment. Will
> this fail if you use the #xcodorg xmemcode resume? Without
separate I&D,
> you have two segments--one on the first flash chip, then you skip
around
> the ID block and another one on the second segment. If you resume
and the
> blocks are already filled up, will it just cleanly jump to the next
> available segment?
>
> It sounds like a feature request is in order--make DC do this
> automatically. > ----------
> > From: Bruce Isted <bisted@z...>
> > To: rabbit-semi@rabb...
> > Subject: Re: [rabbit-semi] Out of variable data space & Out of
xmemcode
> space, use a larger ROM/RAM
> > Date: Friday, June 18, 2004 12:48 PM
> >
> > One other tip occurs to me. When #ximporting files and
compiling using a
>
> > mode that has more than one xmem code org (IE: separate I&D
space
> enabled,
> > USE_2NDFLASH_CODE enabled, or both), it is often possible
to "recover"
> some
> > xmem code space by "resuming" to the first xmem code org
immediately
> after
> > the files have been #ximported.
> >
> > For example, with separate I&D space (with or without
USE_2NDFLASH_CODE)
> > enabled the directive is:
> >
> > #xcodorg sid_xmemcode resume
> >
> > For shared I&D space with USE_2NDFLASH_CODE enabled, the
directive is:
> >
> > #xcodorg xmemcode resume
> >
> > If #ximporting a large file caused Dynamic C to move on to the
next xmem
> > code org, the appropriate one of the above directives may help
to recover
>
> > xmem code space that would otherwise be wasted. If there isn't
available
>
> > space at the end of an earlier xmem code org, then a too-large
> application
> > will still run out of memory, of course.
> >
> > At 12:17 PM 6/18/2004, you wrote:
> > >When a DC compile runs out of code or data memory, the numbers
shown may
> > >not be accurate. For example, notice that the root data sizes
quoted
> below
> > >are negative numbers displayed in hexadecimal format.
> > >
> > >In any case, for compiling with separate I&D space enabled, it
is very
> > >often a good idea to ensure that an application does ***not***
declare
> > >"#memmap xmem" anywhere. When #memmap xmem is used, DC will
not compile
> C
> > >functions to the root code org unless they are explicitly
declared
> > >root. What may happen is that a large percentage of the root
code org
> is
> > >empty, even though a large application has overfilled the xmem
code org
> > >(and so DC generates an out of xmem space error).
> > >
> > >At 04: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
> > > >
> > > >
> > > >
> > > >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-
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
