Hello all
i could not understand this doprnt() function. I have DC9.21 but i
can't find its docs.Can any one tell me the path or give correct
explanation to this function. I got stuck up at RCM2200/KEYLCD.C i
couldn't get this understand. Plz help me out.
With Regards
Phani.
Reg: What is doprnt( )
Started by ●May 1, 2007
Reply by ●May 2, 20072007-05-02
I don't have DC9, but on previous versions doprnt() was declared in
stdio.lib library (this should be in your LIB folder). It's the function
which does the formatting of printf( "This is a number: %d", iNum); calls.
On 4/30/07, linuxwin2005 wrote:
>
> Hello all
>
> i could not understand this doprnt() function. I have DC9.21 but i
> can't find its docs.Can any one tell me the path or give correct
> explanation to this function. I got stuck up at RCM2200/KEYLCD.C i
> couldn't get this understand. Plz help me out.
>
> With Regards
>
> Phani.
>
stdio.lib library (this should be in your LIB folder). It's the function
which does the formatting of printf( "This is a number: %d", iNum); calls.
On 4/30/07, linuxwin2005 wrote:
>
> Hello all
>
> i could not understand this doprnt() function. I have DC9.21 but i
> can't find its docs.Can any one tell me the path or give correct
> explanation to this function. I got stuck up at RCM2200/KEYLCD.C i
> couldn't get this understand. Plz help me out.
>
> With Regards
>
> Phani.
>
Reply by ●May 2, 20072007-05-02
doprnt
SYNTAX: void doprnt(int (*putc) (), char *fmt, void
*arg1, void *instanceParam);
KEYWORDS:
DESCRIPTION: Formatted output routine. This is the
support routine behind
all ...printf routines. "putc" is a function that
outputs one byte, it is
called by doprnt whenever doprnt outputs a character.
"fmt" is the format
string that specifies the output. "arg1" points to
the address of the
first parameter to be used by the formatted string.
The interpretation of
the parameters depends on the format fields in the
format string. This
routine brings in many math functions.
This routine can be called from processes of different
priorities.
The macro STDIO_DISABLE_FLOATS can be defined if it is
not necessary to format
floating point numbers. If this macro is defined, %e,
%f and %g will not
be recognized. This can save thousands of bytes of
code space.
RETURN VALUE: none.
--- linuxwin2005 escreveu:
> Hello all
>
> i could not understand this doprnt() function. I
> have DC9.21 but i
> can't find its docs.Can any one tell me the path or
> give correct
> explanation to this function. I got stuck up at
> RCM2200/KEYLCD.C i
> couldn't get this understand. Plz help me out.
> With Regards
>
> Phani.
__________________________________________________
Fale com seus amigos de gra com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/
SYNTAX: void doprnt(int (*putc) (), char *fmt, void
*arg1, void *instanceParam);
KEYWORDS:
DESCRIPTION: Formatted output routine. This is the
support routine behind
all ...printf routines. "putc" is a function that
outputs one byte, it is
called by doprnt whenever doprnt outputs a character.
"fmt" is the format
string that specifies the output. "arg1" points to
the address of the
first parameter to be used by the formatted string.
The interpretation of
the parameters depends on the format fields in the
format string. This
routine brings in many math functions.
This routine can be called from processes of different
priorities.
The macro STDIO_DISABLE_FLOATS can be defined if it is
not necessary to format
floating point numbers. If this macro is defined, %e,
%f and %g will not
be recognized. This can save thousands of bytes of
code space.
RETURN VALUE: none.
--- linuxwin2005 escreveu:
> Hello all
>
> i could not understand this doprnt() function. I
> have DC9.21 but i
> can't find its docs.Can any one tell me the path or
> give correct
> explanation to this function. I got stuck up at
> RCM2200/KEYLCD.C i
> couldn't get this understand. Plz help me out.
> With Regards
>
> Phani.
__________________________________________________
Fale com seus amigos de gra com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/
Reply by ●May 2, 20072007-05-02
If you position the cursor within the function name and press
CONTROL-H, you will get the function lookup, which will automatically
display the library's function description and the name of the LIB
file. If more than one LIB has the same function name, it will display
the Browse window and allow you to select the version you want. I
believe that for this to work, the LIB file needs to be listed in the
LIB.DIR file in the DCRABBIT_9.21 folder.
Mark
--- In r..., "linuxwin2005" wrote:
>
> Hello all
>
> i could not understand this doprnt() function. I have DC9.21 but i
> can't find its docs.Can any one tell me the path or give correct
> explanation to this function. I got stuck up at RCM2200/KEYLCD.C i
> couldn't get this understand. Plz help me out.
> With Regards
>
> Phani.
>
CONTROL-H, you will get the function lookup, which will automatically
display the library's function description and the name of the LIB
file. If more than one LIB has the same function name, it will display
the Browse window and allow you to select the version you want. I
believe that for this to work, the LIB file needs to be listed in the
LIB.DIR file in the DCRABBIT_9.21 folder.
Mark
--- In r..., "linuxwin2005" wrote:
>
> Hello all
>
> i could not understand this doprnt() function. I have DC9.21 but i
> can't find its docs.Can any one tell me the path or give correct
> explanation to this function. I got stuck up at RCM2200/KEYLCD.C i
> couldn't get this understand. Plz help me out.
> With Regards
>
> Phani.
>
Reply by ●May 2, 20072007-05-02
Hi,
Can someone provide info on bbram memory allocation for RCM3360?
For RCM3360, 256kB of bbram as the physical address 80000 - BFFFF [256kB]
But when I run the sample program "memoryusage.c "in Dynamic C 9.25 [target: RCM 3360] I get the below output.
In reference to this output I do not see the entire 256kB is allocated for bbram.
I understand there is 176kB for "free XRAM space for xalloc"
And 4kB for "reserved for battery backed root data"
But all this adds up to only 180kB.
I can not figure out what's happening with my rest 80kB of bbram.
----
PHYSADR LOGADR SIZE SIZE(Dec) USAGE
----
RAM
----
00000 00:0000 06000 024576 Reserved by Compiler for Root Code
00000 00:0000 01ea9 007849 used by BIOS
01eaa 00:1eaa 032c6 012998 used by this program for root code
----
0e000 00:e000 71e00 466432 Reserved for Xmem Code
0c000 fe:e000 0320a 012810 used by this program for xmem code
----
MORE RAM (Code and BIOS in RAM option set in compiler options)
----
06000 00:6000 05c00 023552 Reserved for Root Data
ac000 00:c000 01000 004096 Reserved for Battery Backed Root Data
0b54f 00:b54f 006b1 001713 used by this program for root data
0be00 00:be00 00100 000256 used for the internal vector table
0bf00 00:bf00 00100 000256 used for the external vector table
----
00000 f2:e000 0c000 049152 Reserved RAM space
7de00 6f:ee00 00200 000512 Reserved RAM space
7e000 70:e000 01000 004096 Reserved RAM space
7f000 71:e000 01000 004096 Reserved RAM space
ac000 9e:e000 01000 004096 Reserved RAM space
ad000 9f:e000 13000 077824 Reserved RAM space
----
7c001 6e:e001 01000 004096 Stack space
----
7f000 71:e000 01000 004096 Used for the flash buffer
----
0f20b 01:e20b 6cbf5 445429 Free XRAM space for xalloc
80000 72:e000 2c000 180224 Free XRAM space for xalloc
----br />
Much appreciated for your help.
Thanks,
Raja
Can someone provide info on bbram memory allocation for RCM3360?
For RCM3360, 256kB of bbram as the physical address 80000 - BFFFF [256kB]
But when I run the sample program "memoryusage.c "in Dynamic C 9.25 [target: RCM 3360] I get the below output.
In reference to this output I do not see the entire 256kB is allocated for bbram.
I understand there is 176kB for "free XRAM space for xalloc"
And 4kB for "reserved for battery backed root data"
But all this adds up to only 180kB.
I can not figure out what's happening with my rest 80kB of bbram.
----
PHYSADR LOGADR SIZE SIZE(Dec) USAGE
----
RAM
----
00000 00:0000 06000 024576 Reserved by Compiler for Root Code
00000 00:0000 01ea9 007849 used by BIOS
01eaa 00:1eaa 032c6 012998 used by this program for root code
----
0e000 00:e000 71e00 466432 Reserved for Xmem Code
0c000 fe:e000 0320a 012810 used by this program for xmem code
----
MORE RAM (Code and BIOS in RAM option set in compiler options)
----
06000 00:6000 05c00 023552 Reserved for Root Data
ac000 00:c000 01000 004096 Reserved for Battery Backed Root Data
0b54f 00:b54f 006b1 001713 used by this program for root data
0be00 00:be00 00100 000256 used for the internal vector table
0bf00 00:bf00 00100 000256 used for the external vector table
----
00000 f2:e000 0c000 049152 Reserved RAM space
7de00 6f:ee00 00200 000512 Reserved RAM space
7e000 70:e000 01000 004096 Reserved RAM space
7f000 71:e000 01000 004096 Reserved RAM space
ac000 9e:e000 01000 004096 Reserved RAM space
ad000 9f:e000 13000 077824 Reserved RAM space
----
7c001 6e:e001 01000 004096 Stack space
----
7f000 71:e000 01000 004096 Used for the flash buffer
----
0f20b 01:e20b 6cbf5 445429 Free XRAM space for xalloc
80000 72:e000 2c000 180224 Free XRAM space for xalloc
----br />
Much appreciated for your help.
Thanks,
Raja
Reply by ●May 2, 20072007-05-02
Raja CP wrote:
>
> Hi,
>
>
>
> Can someone provide info on bbram memory allocation for RCM3360?
>
>
>
> For RCM3360, 256kB of bbram as the physical address 80000 -- BFFFF [256kB]
>
The 3360 has 512k of bbram, not 256.
> But when I run the sample program "memoryusage.c "in Dynamic C 9.25
> [target: RCM 3360] I get the below output.
>
> In reference to this output I do not see the entire 256kB is allocated
> for bbram.
>
> I understand there is 176kB for "free XRAM space for xalloc"
>
> And 4kB for "reserved for battery backed root data"
>
> But all this adds up to only 180kB.
>
> I can not figure out what's happening with my rest 80kB of bbram.
> ----
>
> MORE RAM (Code and BIOS in RAM option set in compiler
> options)
>
> ----
>
The above says your are compiling to RAM. You should use "Compile to
Flash, run in RAM" on the RC32/33xx boards. Compile to RAM will divide
up teh RAM, especially if Separate I&D is used.
Even then, I bet DC will not map all 512k in RAM. It's memory map is a
mess and is completely undocumented. It will probably map 256k of flash
to access the user block even though that is not necessary.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
3M, under the Scotch brand name, manufactures a fine adhesive for art
and display work. This product is called "Craft Mount". 3M suggests
that to obtain the best results, one should make the bond "while the
adhesive is wet, aggressively tacky." I did not know what "aggressively
tacky" meant until I read today's fortune.
[And who said we didn't offer equal time, huh? Ed.]
>
> Hi,
>
>
>
> Can someone provide info on bbram memory allocation for RCM3360?
>
>
>
> For RCM3360, 256kB of bbram as the physical address 80000 -- BFFFF [256kB]
>
The 3360 has 512k of bbram, not 256.
> But when I run the sample program "memoryusage.c "in Dynamic C 9.25
> [target: RCM 3360] I get the below output.
>
> In reference to this output I do not see the entire 256kB is allocated
> for bbram.
>
> I understand there is 176kB for "free XRAM space for xalloc"
>
> And 4kB for "reserved for battery backed root data"
>
> But all this adds up to only 180kB.
>
> I can not figure out what's happening with my rest 80kB of bbram.
> ----
>
> MORE RAM (Code and BIOS in RAM option set in compiler
> options)
>
> ----
>
The above says your are compiling to RAM. You should use "Compile to
Flash, run in RAM" on the RC32/33xx boards. Compile to RAM will divide
up teh RAM, especially if Separate I&D is used.
Even then, I bet DC will not map all 512k in RAM. It's memory map is a
mess and is completely undocumented. It will probably map 256k of flash
to access the user block even though that is not necessary.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
3M, under the Scotch brand name, manufactures a fine adhesive for art
and display work. This product is called "Craft Mount". 3M suggests
that to obtain the best results, one should make the bond "while the
adhesive is wet, aggressively tacky." I did not know what "aggressively
tacky" meant until I read today's fortune.
[And who said we didn't offer equal time, huh? Ed.]
Reply by ●May 2, 20072007-05-02
Thanks for your reply Scott.
Yes, you're right it is 512kB.
But I am compiling to flash and running in RAM, still I get the same output.
Since my currently I am running out of bbram memory space.
Is there a way to use the remaining free space in bbram?
Do correct me in this; if the normal xmem memory is fully consumed, is that the remaining 256kB of bbram is used?
Thanks
Raja
-----Original Message-----
From: r... [mailto:r...] On Behalf Of Scott Henion
Sent: Thursday, 3 May 2007 11:48 AM
To: r...
Subject: Re: [rabbit-semi] bbram memory usage [RCM 3360]
Raja CP wrote:
Hi,
Can someone provide info on bbram memory allocation for RCM3360?
For RCM3360, 256kB of bbram as the physical address 80000 - BFFFF [256kB]
The 3360 has 512k of bbram, not 256.
But when I run the sample program "memoryusage.c "in Dynamic C 9.25 [target: RCM 3360] I get the below output.
In reference to this output I do not see the entire 256kB is allocated for bbram.
I understand there is 176kB for "free XRAM space for xalloc"
And 4kB for "reserved for battery backed root data"
But all this adds up to only 180kB.
I can not figure out what's happening with my rest 80kB of bbram.
----
MORE RAM (Code and BIOS in RAM option set in compiler options)
----
The above says your are compiling to RAM. You should use "Compile to Flash, run in RAM" on the RC32/33xx boards. Compile to RAM will divide up teh RAM, especially if Separate I&D is used.
Even then, I bet DC will not map all 512k in RAM. It's memory map is a mess and is completely undocumented. It will probably map 256k of flash to access the user block even though that is not necessary.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
3M, under the Scotch brand name, manufactures a fine adhesive for art
and display work. This product is called "Craft Mount". 3M suggests
that to obtain the best results, one should make the bond "while the
adhesive is wet, aggressively tacky." I did not know what "aggressively
tacky" meant until I read today's fortune.
[And who said we didn't offer equal time, huh? Ed.]
Yes, you're right it is 512kB.
But I am compiling to flash and running in RAM, still I get the same output.
Since my currently I am running out of bbram memory space.
Is there a way to use the remaining free space in bbram?
Do correct me in this; if the normal xmem memory is fully consumed, is that the remaining 256kB of bbram is used?
Thanks
Raja
-----Original Message-----
From: r... [mailto:r...] On Behalf Of Scott Henion
Sent: Thursday, 3 May 2007 11:48 AM
To: r...
Subject: Re: [rabbit-semi] bbram memory usage [RCM 3360]
Raja CP wrote:
Hi,
Can someone provide info on bbram memory allocation for RCM3360?
For RCM3360, 256kB of bbram as the physical address 80000 - BFFFF [256kB]
The 3360 has 512k of bbram, not 256.
But when I run the sample program "memoryusage.c "in Dynamic C 9.25 [target: RCM 3360] I get the below output.
In reference to this output I do not see the entire 256kB is allocated for bbram.
I understand there is 176kB for "free XRAM space for xalloc"
And 4kB for "reserved for battery backed root data"
But all this adds up to only 180kB.
I can not figure out what's happening with my rest 80kB of bbram.
----
MORE RAM (Code and BIOS in RAM option set in compiler options)
----
The above says your are compiling to RAM. You should use "Compile to Flash, run in RAM" on the RC32/33xx boards. Compile to RAM will divide up teh RAM, especially if Separate I&D is used.
Even then, I bet DC will not map all 512k in RAM. It's memory map is a mess and is completely undocumented. It will probably map 256k of flash to access the user block even though that is not necessary.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
3M, under the Scotch brand name, manufactures a fine adhesive for art
and display work. This product is called "Craft Mount". 3M suggests
that to obtain the best results, one should make the bond "while the
adhesive is wet, aggressively tacky." I did not know what "aggressively
tacky" meant until I read today's fortune.
[And who said we didn't offer equal time, huh? Ed.]
Reply by ●May 2, 20072007-05-02
Raja CP wrote:
>
> Thanks for your reply Scott.
>
> Yes, you're right it is 512kB.
>
> But I am compiling to flash and running in RAM, still I get the same
> output.
>
> Since my currently I am running out of bbram memory space.
>
> Is there a way to use the remaining free space in bbram?
>
DC does not handle memory well. It has no far pointer support so bbram
variables must be in root memory.
battary-backed variables are limited to 4096 bytes by the bios. Look for
the BBROOTDATASIZE defines in the rabbitbios.c. You should eb able to
increase it by 0x1000 increments.
Look at the documentation for _xalloc(), it can allocate bbram from xmem.
>
>
>
> Do correct me in this; if the normal xmem memory is fully consumed, is
> that the remaining 256kB of bbram is used?
>
xalloc() will allocate non-bbram first, the use the available bbram.
Personally, I prefer a compiler that can access all the RAM and flash ;)
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Try the Moo Shu Pork. It is especially good today.
>
> Thanks for your reply Scott.
>
> Yes, you're right it is 512kB.
>
> But I am compiling to flash and running in RAM, still I get the same
> output.
>
> Since my currently I am running out of bbram memory space.
>
> Is there a way to use the remaining free space in bbram?
>
DC does not handle memory well. It has no far pointer support so bbram
variables must be in root memory.
battary-backed variables are limited to 4096 bytes by the bios. Look for
the BBROOTDATASIZE defines in the rabbitbios.c. You should eb able to
increase it by 0x1000 increments.
Look at the documentation for _xalloc(), it can allocate bbram from xmem.
>
>
>
> Do correct me in this; if the normal xmem memory is fully consumed, is
> that the remaining 256kB of bbram is used?
>
xalloc() will allocate non-bbram first, the use the available bbram.
Personally, I prefer a compiler that can access all the RAM and flash ;)
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Try the Moo Shu Pork. It is especially good today.
Reply by ●May 3, 20072007-05-03
Some extra info on top of what Scott have you.
You can always access ALL memory on your RCM module, but DynamicC does
not necessary offer library functions to do this.
Your modules physical memory map with 'compile to Flash, run in RAM':
- 512kByte: fast-sram = your program, data, stack, etc.. and all
xalloc'ed memory until it's all used
- 256kByte: bb-sram
- 256kByte: top 256kByte of Flash = to access IDblock
The bb-sram can be accessed with the bbram keyword (4kByte in root
memory) or with the xalloc function (use the XALLOC_BB parameter).
Note that some of the 256kByte is used internally by DynamicC.
There is no DC function to access the remaining 256kByte bb-sram, but
it's easy to access. You have two possible options:
1. Disable the flash in Q3 and enable the second 256kByte of the
bb-SRAM in this quadrant. If you never use the ID-Block/Userblock,
it's no problem. If you use these, just swap Q3 back to flash before
accessing the Userblock. I find this the easiest system.
2. Swap the bottom and top 256kByte bb-sram in Q2. BUT, dont use
xalloc in bb-sram anymore. This function does not suppport this trick.
Also some DC features wont work anymore.
Once the memory is swapped to a physical memory, you can used
read/write it with direct physical memory addresses. It's the same as
xalloc. Just make a manual map of the memory and use
xmem2root/root2xmem functions to copy data to and from it.
Success,
Rudi
www.x-graph.be the next generation Rabbit SBC with (Color TFT) LCD
--- In r..., "Raja CP" wrote:
>
> Hi,
>
> Can someone provide info on bbram memory allocation for RCM3360?
>
> For RCM3360, 256kB of bbram as the physical address 80000 - BFFFF
[256kB]
> But when I run the sample program "memoryusage.c "in Dynamic C 9.25
[target: RCM 3360] I get the below output.
> In reference to this output I do not see the entire 256kB is
allocated for bbram.
> I understand there is 176kB for "free XRAM space for xalloc"
> And 4kB for "reserved for battery backed root data"
> But all this adds up to only 180kB.
> I can not figure out what's happening with my rest 80kB of bbram.
>
>
----
> PHYSADR LOGADR SIZE SIZE(Dec) USAGE
>
----
> RAM
>
----
> 00000 00:0000 06000 024576 Reserved by Compiler for Root
Code
> 00000 00:0000 01ea9 007849 used by BIOS
> 01eaa 00:1eaa 032c6 012998 used by this program for root
code
>
----
> 0e000 00:e000 71e00 466432 Reserved for Xmem Code
> 0c000 fe:e000 0320a 012810 used by this program for xmem
code
>
----
> MORE RAM (Code and BIOS in RAM option set in compiler options)
>
----
> 06000 00:6000 05c00 023552 Reserved for Root Data
> ac000 00:c000 01000 004096 Reserved for Battery Backed
Root Data
> 0b54f 00:b54f 006b1 001713 used by this program for root
data
> 0be00 00:be00 00100 000256 used for the internal vector
table
> 0bf00 00:bf00 00100 000256 used for the external vector
table
>
----
> 00000 f2:e000 0c000 049152 Reserved RAM space
> 7de00 6f:ee00 00200 000512 Reserved RAM space
> 7e000 70:e000 01000 004096 Reserved RAM space
> 7f000 71:e000 01000 004096 Reserved RAM space
> ac000 9e:e000 01000 004096 Reserved RAM space
> ad000 9f:e000 13000 077824 Reserved RAM space
>
----
> 7c001 6e:e001 01000 004096 Stack space
>
----
> 7f000 71:e000 01000 004096 Used for the flash buffer
>
----
> 0f20b 01:e20b 6cbf5 445429 Free XRAM space for xalloc
> 80000 72:e000 2c000 180224 Free XRAM space for xalloc
>
----br /> >
> Much appreciated for your help.
> Thanks,
> Raja
>
You can always access ALL memory on your RCM module, but DynamicC does
not necessary offer library functions to do this.
Your modules physical memory map with 'compile to Flash, run in RAM':
- 512kByte: fast-sram = your program, data, stack, etc.. and all
xalloc'ed memory until it's all used
- 256kByte: bb-sram
- 256kByte: top 256kByte of Flash = to access IDblock
The bb-sram can be accessed with the bbram keyword (4kByte in root
memory) or with the xalloc function (use the XALLOC_BB parameter).
Note that some of the 256kByte is used internally by DynamicC.
There is no DC function to access the remaining 256kByte bb-sram, but
it's easy to access. You have two possible options:
1. Disable the flash in Q3 and enable the second 256kByte of the
bb-SRAM in this quadrant. If you never use the ID-Block/Userblock,
it's no problem. If you use these, just swap Q3 back to flash before
accessing the Userblock. I find this the easiest system.
2. Swap the bottom and top 256kByte bb-sram in Q2. BUT, dont use
xalloc in bb-sram anymore. This function does not suppport this trick.
Also some DC features wont work anymore.
Once the memory is swapped to a physical memory, you can used
read/write it with direct physical memory addresses. It's the same as
xalloc. Just make a manual map of the memory and use
xmem2root/root2xmem functions to copy data to and from it.
Success,
Rudi
www.x-graph.be the next generation Rabbit SBC with (Color TFT) LCD
--- In r..., "Raja CP" wrote:
>
> Hi,
>
> Can someone provide info on bbram memory allocation for RCM3360?
>
> For RCM3360, 256kB of bbram as the physical address 80000 - BFFFF
[256kB]
> But when I run the sample program "memoryusage.c "in Dynamic C 9.25
[target: RCM 3360] I get the below output.
> In reference to this output I do not see the entire 256kB is
allocated for bbram.
> I understand there is 176kB for "free XRAM space for xalloc"
> And 4kB for "reserved for battery backed root data"
> But all this adds up to only 180kB.
> I can not figure out what's happening with my rest 80kB of bbram.
>
>
----
> PHYSADR LOGADR SIZE SIZE(Dec) USAGE
>
----
> RAM
>
----
> 00000 00:0000 06000 024576 Reserved by Compiler for Root
Code
> 00000 00:0000 01ea9 007849 used by BIOS
> 01eaa 00:1eaa 032c6 012998 used by this program for root
code
>
----
> 0e000 00:e000 71e00 466432 Reserved for Xmem Code
> 0c000 fe:e000 0320a 012810 used by this program for xmem
code
>
----
> MORE RAM (Code and BIOS in RAM option set in compiler options)
>
----
> 06000 00:6000 05c00 023552 Reserved for Root Data
> ac000 00:c000 01000 004096 Reserved for Battery Backed
Root Data
> 0b54f 00:b54f 006b1 001713 used by this program for root
data
> 0be00 00:be00 00100 000256 used for the internal vector
table
> 0bf00 00:bf00 00100 000256 used for the external vector
table
>
----
> 00000 f2:e000 0c000 049152 Reserved RAM space
> 7de00 6f:ee00 00200 000512 Reserved RAM space
> 7e000 70:e000 01000 004096 Reserved RAM space
> 7f000 71:e000 01000 004096 Reserved RAM space
> ac000 9e:e000 01000 004096 Reserved RAM space
> ad000 9f:e000 13000 077824 Reserved RAM space
>
----
> 7c001 6e:e001 01000 004096 Stack space
>
----
> 7f000 71:e000 01000 004096 Used for the flash buffer
>
----
> 0f20b 01:e20b 6cbf5 445429 Free XRAM space for xalloc
> 80000 72:e000 2c000 180224 Free XRAM space for xalloc
>
----br /> >
> Much appreciated for your help.
> Thanks,
> Raja
>
