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 > > > > > > > > > >

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 > >

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

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-

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 > >

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 > >

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: aintnoprobs

To: r...@yahoogroups.com

Sent: Friday, June 18, 2004 4:53 AM

Subject: [rabbit-semi] Re: Out of variable data space & Out of xmem code space, use a larger ROM/RAM

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 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.

---------- > 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.

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.

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.