Malloc?

[interfect]

Hello,
Does anyone have an implementation of malloc? We really need some way to dynamically allocate memory, as we're running up against the 256 byte global per file limit.
Thanks,
Interfect

[MikeDubreuil]

I don't have an implementation for you but I will caution you against using malloc. In general, using malloc in an embedded software design is perilous at best and just plain wrong at worst. Mainly because in an embedded application you should keep a tight check on how much RAM your design uses. When there's not a lot available you have to ration the goods. If I were you I would try a different design to accomplish the task.

[Orborde]

Some thoughts:

Are you defining constants as globals? You should really use #defines in header files for values that don't change, or alternatively:

rom const int my_constant = 6;

"rom" means "put this in read-only memory"; "const" means "I'm not going to change this, so do optimizations like putting it in read-only memory". I'm not sure if "const" is sufficient to get it out of RAM, but you get the picture.

You might also look into storing things in EEPROM (there is some sample code on Kevin Watson's site: http://kevin.org/frc ) if you want to "remember" variables between sessions. Or you could go completely hog-wild and implement swapping stuff to EEPROM... yeah, I'm getting carried away.

If you absolutely NEED a "dynamic" array, maybe you could allocate one on the stack, as follows:

int sum_numbers(int numbers)
{
  int arr[numbers];
  /* etc. Arr is only useful in this scope, though! */
}

The downside to this is that you only get to use the array as long as it's in scope, and I'm not sure if MCC18 supports that kind of array allocation, anyway.

As Mike said, if you need malloc(), your design needs to be modified. Kudos to you for being so good at C, but embedded programming is a different animal than a PC.

[Ken Streeter]

Originally Posted by interfect

Does anyone have an implementation of malloc? We really need some way to dynamically allocate memory, as we're running up against the 256 byte global per file limit.

There are a few different alternatives for getting around the 256 byte global per file limit.

If you need additional storage for variables, one option is to use the "#pragma" directive to explicitly put data into different memory "sections". Earlier this season, there was a previous Chief Delphi thread which discussed this approach. Another posting describing this technique can be found in this thread from 2006. Whether you use the "idata" or "udata" declarations depends upon whether or not the variables you are using are "initialized data" or "uninitialized data."

For more information on the use of the "#pragma" directive, you'll need to look at the MPLAB C18 Users manual. I don't know where to find the manual for version 2.4 of the compiler, but the MPLAB website does have the manual for the newer 3.0 version.

In the above manual, see pages 20-26 for information on using the #pragma directive to be able to use more than one memory section for a given file.

If the storage you need is for "constant" data (for example, a large lookup table that is initialized to certain values, but then never changed) you can declare the "variables" (the ones that are constants that never change) with the "rom" qualifier so that these "variables" are actually stored in program memory. In that way, you can store much larger lookup tables, as long as the code never changes them dynamically. (The lookup tables would need to be changed by recompiling in that case.)

Hopefully one of these approaches will work for you!

[Tom Line]

I'm curious guys -

I've read the white paper on the limits of the pic - 30k, 256 bytes, etc etc.

Can someone tell me HOW to measure those on the program I'm writing? How do I know how many bytes my variables will take, and how do I know whether I'm using the full 30k or not?

Do I go through and manually try to figure out how big it's going to be by counting variables and their sizes?

[Mark McLeod]

If you're using MPLAB you can see that info. about your program at:

View -> Memory Usage Gauge

Note that the program memory is expressed in two-byte integers, but Data Memory is number of bytes.

You can also set a flag in MPLAB under Project -> Build Options -> Project, then the MPLINK Linker tab and click on "Generate map file." That'll create a text file in your project directory with the extension .map that shows you where your variables get pegged in the PIC memory.

The PIC we're using this year (and last year's '06 version as well) has more memory, e.g.128k of program memory.

[Metalgod4eva]

got to go to class but you can print back the size of malloc of a file.