Printable View
Hi,
Can anyone be kind enough to tell me how to saved usage of RAM when RAM is very limited? I am writing codes to a microcontroller and the RAM is extremely limited. I have almost used up the RAM and i desperately need to free some. One of the ways i can think of is to use as less global variable as possible. But i dont think this will help much as most of the variables is shared among functions.....So.....PLEASE HELP
Thanks :(
It's not that easy to trim the fat on a pig you can't see, but first check into special options your compiler may provide. If you have sub-character-sized data, you might pack them into some sort of bit arrays.
[edit]Investigate what your stack size is set to, measure what you need, and consider adjusting accordingly.
I am not sure whether #define goes into RAM or ROM coz i have plenty of defines. Maybe i can trim this off a bit?
It goes in to neither. #define statements are handled during compile time, and don't make it into the actual binary.Quote:
I am not sure whether #define goes into RAM or ROM coz i have plenty of defines. Maybe i can trim this off a bit?
EDIT: To clarify this. Define statements are the equivalent of substituing text in your source file. For instance, if you have:
Your compiler will replace that withCode:#define HELLO_WORLD "Hello World"
printf(HELLO_WORLD);
before it even begins to compile your code.Code:printf("Hello World");
Well...i'm kinda fresh in C programming... So i'm weak in handling the ROMs and RAMs.....Can i know what goes into the RAM and what goes into the ROM...
there are a couple of things you could do, one would be to pass
function parameters by reference using pointers - since only the
memory location of a variable is passed instead of a copy of it.
also, if your code has any structs, you might be able to use unions
instead, they are described very briefly here:
http://www.cprogramming.com/tutorial/lesson7.html
you could also attempt to use bit fields, allowing you to essentially
use individual bits to represent data, like menu choices that will
either be 0 or 1. that is all i can think of, i dont have much
experience in hardware programming yet. here are some links
that may be of use, nothing more i can do. also i think that you
should be able to use an optimiser to reduce the memory
requirements of the program.
just one point though, if RAM is so tight, it might be a good
idea to stick with the microcontrollers assembly, since
using the methods described are really just attempts to
program in C like assembly.
http://www.scit.wlv.ac.uk/cbook/chap10.bit.fields.html
http://cboard.cprogramming.com/archi...p/t-10029.html
http://www.cs.cf.ac.uk/Dave/C/node13.html
Variables.Quote:
Originally Posted by suzanne_lim
Code (functions) and (possibly) constants.Quote:
Originally Posted by suzanne_lim
The ROM memory just holds your program code. This is the actual code that gets executed by the processor. The RAM is the memory that your code uses to create and store varables/data.Quote:
Can i know what goes into the RAM and what goes into the ROM...
In other words, if you make your program shorter (fewer lines of code), that doesn't have any bearing on the amount of RAM that will be used, it will just make your program use less ROM space.
There are many ways to conserve memory. The ones that make sense depend on the application that you're working on.
You say you don't know what goes into ROM and what goes into RAM. In general, your code (the machine instructions generated by the compiler, along with code from the libraries you link with) goes into ROM. String constants (quoted strings) usually end up in ROM as well, as can const "variables". Your stack, local and global variables, and the heap (where dynamic allocation comes from) are stored in RAM.
As was suggested by Richie T, use of the smallest data type for a variable that still gives you the desired result (including the use of bit fields) can save you a lot of RAM, though bit fields are not useful except within structures. The use of bit fields can increase code size in some cases, so it's a trade-off between performance/code size and RAM utilization. The use of the smallest data type is generally only important for globals, function and file scope static variables, and members of structs; automatic local variables, which are stored on the stack, generally don't matter that much unless you are short on stack space.
The best way to save ROM space is to write your code as tightly as possible. Unfortunately, much of that comes from experience, and it's hard to give advice on that without knowning the sort of program this is.
- Write common subroutines/functions for frequently done operations, learn how to pass and use function pointers, and then use them.
- Make sure you don't use library routines like sprintf() and sscanf() unless you absolutely must. Though some embedded development systems provide stripped down versions of these functions, they still bring in a lot of extra baggage (the ability to format/decode pretty much every flavor of floating point, for example). Look at the documentation for your development environment for any options in this area. Avoid most of stdio like the plague.
- If you use a lot of similar (or identical) strings literals (quoted strings), put them all as const char[] or const char * in global scope, and reuse the same string as much as possible. There are a number of tricks for compacting strings, but they're hard to describe clearly in a short (or even medium length) posting such as this.
To save RAM, there are several steps you can take. If you have a large number of globals, create a large struct that contains all of them. Make one instance of that struct in global scope. Reference the fileds of the struct (mystruct.fieldname) where you would have otherwise referenced the equivilent global variable. You may find that adjusting the order of the fields within this structure (and any structure you define) may save you RAM space that would otherwise be wasted as padding for aligning fields. This is very processor dependent, and is usually a matter of some trial and error to see what the compiler will do. See if your compiler has a "#pragma packed" option to help make for more compact structs. The use of the global struct will allow you to use more bit fields, and also make it easier to make your code reentrant in the future.)
Tools that will help you figure out how you're doing are things like link maps (that can be generated optionally by the linker) and looking at the assembly output from the compiler (the -S option on many compilers).
This is quite incomplete, and somewhat incoherent advice, but I hope it helps.
redo the algorithmn,patching up wont work well,incorporate limited ram usage and the option of extended ram usage (for efficiency)in your program design.Actually u should have thought of this b4 the implementation phase,see u r running into troubles now.Think about the people who will get the job of improving your software for advanced versions of the hardware.MAKE IT EASIER FOR THEM.
nothing goes into ROM because ROM isn't writable.
Now if you're creating for a game console that uses ROM cartridges your entire binary code will go into one of those just like it would go onto a CD or DVD when you're distributing on one of those.
It would still be loaded into RAM at execution time.
Unfortunately.....I am the "THEM"..... :pQuote:
Originally Posted by qqqqxxxx
I see....i'll take a look at all the comment u guys gave....Do please give more suggestion if u have.....Thanks :D
Maybe there is no need to explain.
Just becareful. The terms ROM and RAM, have different meaning in programing and hardware terms.
In programming:
ROM==The executable code
RAM==The space for vars, objects, etc
But in hardware terms:
ROM==A place where it's content can't be changed when computer is turned on (ex. BIOS)
RAM==The physical memory that all programs will be loaded in it at runtime
Both ROM and RAM in programing terms, are placed in "RAM in hardware terms".
The posts from others explain use programing term. When you say the RAM is limited, usualy you are using hardware term and you mean my physical memory is limited.
When you want your program to use less physical memory(RAM in hardware term), you should both reduce your executive code(RAM in programing term) and storage memory(ROM in programing term) as other's posts explain.
(If you don't know what is ROM in hardware term, I think you don't need to.)
The original posting from suzanne_lim stated something about microcontrollers, so I'm assuming that when she/he used the term "ROM", she/he meant ROM (or more likely, EEPROM). It doesn't need to be a video game, and the code is probably not copied into R/W RAM at runtime.Quote:
Originally Posted by jwenting
Embedded programmers do write code that ends up in ROM.
Yes, in those devices ROM is like a HDD in PCs. As I know there is two way for the code to be executed then:
1) Code executes from the ROM and objects will use RAM. (Needs less RAM)
2) Code will be loaded into RAM and will be executed there. (Faster execution)
We can see both in PCs when computer uses BIOS. (Shadow, cachable, etc)