are constants copied into RAM??
jean_randhahn
I am trying desperatly to minimze my RAM usage as I do not have lots of
it for the task I am running. So I am wondering if constants are copied
into RAM or not. Since they are constant and don't change value they can
be placed into the programm code section, can't they?
Thanks for comments
-Jean-
--------------------
http://randhahn.de
Michael Hillmann
>I am trying desperatly to minimze my RAM usage as I do not have lots of
>it for the task I am running. So I am wondering if constants are copied
>into RAM or not. Since they are constant and don't change value they can
>be placed into the programm code section, can't they?
Right, you can do that.
In C you must! declare the variable as a constant variable:
const unsigned char msg[] = "Some Text";
This signals the compiler, that this value is a real constant, which can't
be written. So this variable is placed in ROM.
If you declare:
unsigned char msg[]="Some Text";
The compiler will place this variable in RAM, because the functions could
change the text.
This variable is called an initialized variable and is placed in a special
ROM section. This ROM section is copied to the RAM area during startup the C
environment, because the initial value must be present, before the
application become active.
Greetings
Michael
----
Michael Hillmann
software development
syscon regelungs- & systemtechnik
johannes-jung-str. 7
88239 wangen
Peet Grobler
e.g, you can have like the following:
#define MY_CONST = 5
printf(MY_CONST)
The compiler will translate this to : printf(5).
So no, it does not get stored in RAM.
Jean Randhahn wrote in message
<20010814...@hering.e-technik1.uni-rostock.de>...
Richard F. Man
Jean, Randhahn wrote:
> Hi all!
>
> I am trying desperatly to minimze my RAM usage as I do not have lots of
> it for the task I am running. So I am wondering if constants are copied
> into RAM or not. Since they are constant and don't change value they can
> be placed into the programm code section, can't they?
>
It depends on your target processors, what you mean by constants (simple
data or aggregates), the compilers etc.
--
// richard
http://www.imagecraft.com
Spehro Pefhany
> Hi all!
> I am trying desperatly to minimze my RAM usage as I do not have lots of
> it for the task I am running. So I am wondering if constants are copied
> into RAM or not. Since they are constant and don't change value they can
> be placed into the programm code section, can't they?
Usually they can, however the method for specifying what memory space
the compiler uses is not standard. See your compiler manual.
It *may* do it automatically if you declare the variable "const", but
there are sometimes disadvantages (speed and code size) to this and the
compiler may not- the const only constrains the program, it doesn't
automatically specify the storage space (of which there may be many, not
just the two obvious ones, depending on the hardware, etc.).
Best regards,
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.BlueCollarLinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Walter Banks
RAM. ROM locations are not always used to store a single constant
either.
In the case
#define x 5
the constant x becomes part of the macro expansion.
In the case
const char z = 6;
z may not need a single physical ROM location. By treating z
as a #define the compiler can avoid the overhead associated with
the time for extra fetch required to get the constant address.
Walter Banks
http://www.bytecraft.com
Ulf Samuelsson
news:20010814...@hering.e-technik1.uni-rostock.de...
Hi all!
Thanks for comments
-Jean-
--------------------
http://randhahn.de
They way to go is to look in the compiler documentation as Richard F Man
points out.
For instance the IAR AVR compiler (Sorry Richard :-) I normally use has a
keyword "flash"
which is used to say that things should be in flash, instead of in RAM.
Also, there is a global option to force things into RAM.
const str[] = "0123456789";
can thus end up either in RAM or reamin only in flash.
Note that if you keep the constants in the flash, there could be problems
when using a Harvard Architecture. If you pass a pointer to a constant
as a parameter to a subroutine,then it must be known to the subroutine
if the pointer is in flash or not.
I solved the problem by maintaining a RAM copy of the constant in the stack.
While it still uses RAM, the RAM used is shared between all constants..
It is not persistent, so it could cause problems,
and it takes more performance, since the copy to RAM is done everytime it is
used
instead of at startup.
const str1[] = "This is useful!\n";
const str2[] = "This sux greatly\n";
void myfunc(void)
{
BYTE x[20];
copy_from_flash(x,str1);
printf(x);
copy_from_flash(x,str2);
printf(x);
}
The same RAM is used for both strings and is recovered when the subroutine
is exited.
--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden
jean_randhahn
I found out that my constants ARE stored in the FLASH. So there si no
more need to worry about the constants using up RAM.
I still have to reduce my RAM usage. I am kind of missing roughly 630
bytes of RAM, of which I do not know what they are being used for. I
cannot believe my stack uses up that much.
Do you have any advice on general rules to keep RAM usage low?
-Jean-
David Brown
>-Jean-
It would help greatly if you told us what sort of processor you are using,
and what compiler software you are using. Without knowing that, we can only
make random guesses - on some systems, 630 bytes is a drop in the ocean, on
others it is far more than the MPU's total RAM.
Sven
> I am kind of missing roughly 630
bytes of RAM, of which I do not know what they are being used for. I
cannot believe my stack uses up that much.
Read the linker report. I don't know which compiler/linker you use. I am
using the Keil C-Compiler/Linker for 80c51 controllers and when I am not
sure about the location of a certain variable etc, I search the linker
report for it.
--
-cu
Sven
s dot petersen at amotec dot de
Jamie
> I am kind of missing roughly 630
>bytes of RAM, of which I do not know what they are being used for. I
>cannot believe my stack uses up that much.
You should be able to specify you stack size...check your documentation
Mark Borgerson
Don't use printf()! The standard I/O functions like this
are notorious for using RAM for temporary buffers. You can
often get a clue about such temporary RAM usage by checking
to see if the function is re-entrant. If it is, it probably
uses the stack for temporary variables. If not, it probably
has a dedicated temporary RAM buffer.
Sometimes the map file will tell you who is using a particular
chunk of RAM. Have you checked it for unexplained RAM usage?
Mark Borgerson
Mark A. Odell
>
>
> Jean, Randhahn wrote:
>>
>> Thanks for all the replies!!
>>
>> I found out that my constants ARE stored in the FLASH. So there si no
>> more need to worry about the constants using up RAM.
>> I still have to reduce my RAM usage. I am kind of missing roughly 630
>> bytes of RAM, of which I do not know what they are being used for. I
>> cannot believe my stack uses up that much.
>>
>> Do you have any advice on general rules to keep RAM usage low?
>>
>
> Don't use printf()! The standard I/O functions like this
> are notorious for using RAM for temporary buffers.
Unless you have an embedded optimized version that does not buffer. The one I
use sends each char out the UART as it generates them. Thus is only uses a
few working variables, no buffer space.
--
Warmest regards.
8051 or bust.
Mark Borgerson
That brings to mind another possibility: Does the comm lib set up
some default input and output queues for interrupt-driven serial I/O??
Mark Borgerson
Richard F. Man
Ulf Samuelsson wrote:...
> For instance the IAR AVR compiler (Sorry Richard :-) I normally use has a
> keyword "flash"
> which is used to say that things should be in flash, instead of in RAM.
> ...
It's OK Ulf. I will use you as my ultimate test - if I get you to switch to
ImageCraft ICCAVR, then I know I have done it :-)
Mark A. Odell
>> Unless you have an embedded optimized version that does not buffer. The
>> one I use sends each char out the UART as it generates them. Thus is
>> only uses a few working variables, no buffer space.
>>
> That brings to mind another possibility: Does the comm lib set up
> some default input and output queues for interrupt-driven serial I/O??
What comm lib? C only provides get/putchar and printf as basic stdio
functions. Usually, one needs to write get and putchar() for the hardware and
then printf() will call them.
Clark G. Smith
"Sven" <sv...@nospam.de> wrote in message
news:9lbdpa$q0k$00$1...@news.t-online.com...
Jonathan M Hill
It would really help to know what processor and tools you
have in mind. But I guess I came face to face with a similar
problem. I was writing code for an embedded 8088 application
using the Borland C/C++ compiler and assembler. I ended up
using an old copy of the Paradigm locater to organize memory.
If you are using a somewhat conventional processor, then a
good linker will give you the flexibility to control where and
how memory sections or segments will be allocated. Many tools
automatically define a bss section for uninitialized variables
and a data section for initialized variables. Sounds like you
need a data section that is only allocated in read only memory.
Of course, you will need to make sure that your compiler is
hip to all this.
Now, if your tools are not so flexible or if you are
programming a Harvard architecture that won't let you perform a
simple ROM access, or ROM to RAM copy, then things get dicey.
Good luck;
Jonathan Hill
jmh...@ece.wpi.edu
JeanRandhahn wrote:
: Hi all!
:
: I am trying desperatly to minimze my RAM usage as I do not have lots of =
:
: it for the task I am running. So I am wondering if constants are copied =
:
: into RAM or not. Since they are constant and don't change value they can=
: =20
: be placed into the programm code section, can't they?
Mark Borgerson
Yes, but if there is an OS on the system, it may provide those
services (and use lots of other RAM besides.) I don't recall
if the original message specified the processor and whether
or not there was an RTOS or any other OS present.
Mark Borgerson
Tony Whitley
"Michael Hillmann" wrote...
> Hi,
>
> >I am trying desperatly to minimze my RAM usage as I do not have lots of
> >it for the task I am running. So I am wondering if constants are copied
> >into RAM or not. Since they are constant and don't change value they can
> >be placed into the programm code section, can't they?
>
> Right, you can do that.
>
> In C you must! declare the variable as a constant variable:
> const unsigned char msg[] = "Some Text";
> This signals the compiler, that this value is a real constant, which can't
> be written. So this variable is placed in ROM.
>
Some compilers for some processors still copy the const area into RAM,
usually for speed or ease of access. I know this was the default behaviour
for Microsoft C for the 8086 family and trying to get it to access them
directly was a nightmare.
--
Tony Whitley
Frequency Ltd
Ulf Samuelsson
me to the occasional beer :-)
--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden
"Richard F. Man" <ric...@imagecraft.com> skrev i meddelandet
news:3B797833...@imagecraft.com...
jean_randhahn
I am using a MSP430F148/9 and the IAR workbench. That micro has 2kB RAM
and 48/60kB+256B FLASH.
I tried to get a memory map listing but I cannot manage to get one made
for viewing?!?
I am not using printf() and the like, though I was planing on using quite
a few ANSI C functions for string manipulation. Are they using up lots of
memory?? I have not incorporated them anywhere in my program, yet. Of
course if they will use large buffer space I cannot use them, since I
have a chunck of roughly 140B free memory left.
-Jean-
--------------------
http://randhahn.de
Elizabeth D. Rather
You might look at our SwiftX cross-development system for the MSP430.
As shipped, it uses ~600 bytes of RAM for stacks and sets aside 768 bytes
for interactive code testing. But you have 100% control over RAM usage
in your program (i.e., it can be much less than this, and you don't need to
keep the 768-byte testing page). Of course, it isn't C, it's Forth and
assembler, but there are a lot of string handling functions for you, and
it certainly isn't going to set up buffers on its own.
Cheers,
Elizabeth
http://www.forth.com
--
================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
================================================