We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Is there any easy way to get the heap size after I call init_mempool and have called malloc several times. I want to see how much memory is left. Mark
why do you want to know, you have screwed it up already. Erik
Is there any easy way to get the heap size after I call init_mempool and have called malloc several times. It depends on your definition of easy. Source code is provided for the memory allocation routines. You could write a routine that traverses the free blocks and adds the total free space. Probably more important than the total space unused is the size of the largest free block. That tells you how big of a thing you can allocate. A cool thing about the Keil memory allocation routines is that they merge adjacent free blocks. What that means is that if you allocate all available memory and then free it, you'll end up with the whole heap free instead of lots of little free blocks (like some memory allocation implementations do). Jon
Have you reviewed recent threads on why dynamic allocation is generally a bad thing on embedded systems? Try a 'Search'
Why would it be bad? Ive used it many times where my applications store large amounts of data. I dont allocate and free memory, I allocate to set up for storage and leave it. You'd have to understand the app.
"Why would it be bad?" Like I said: read the threads, and find out! eg, http://www.keil.com/forum/docs/thread2622.asp "Ive used it many times..." Lots of people smoke - but that doesn't make it good for you...! ;-) "...my applications store large amounts of data" There is no difficulty to statically allocate large amounts of data. "I dont allocate and free memory, I allocate to set up for storage and leave it." Surely that's completely pointless?! If it's not dynamic (ie, you don't change it), why have the overheads of dynamic allocation?!
The reason is because i DONT know ahead of time how much i need. Like I said you dont know the application I'm using it for but I can tell you I've been using it for many years the way I use it with NO problems. To make a long story short, The application does datalogging of temperature, voltages and currents etc. The amount of memory needed depends on how many parts the customer is testing on the system. that's why
"The reason is because i DONT know ahead of time how much i need." Then how do you know you have enough? Using dynamically allocated memory is particularly pointless if you just malloc() up a bunch of it and keep it around.
"Then how do you know you have enough?" That's the crux of it! With PC (and similar) targets, the programmer doesn't know how much memory will be available to the program each time it is run - it will depend on the specific configuration of the particular PC being used, and on what other things are also using memory. Therefore dynamic allocation is useful in such environments. In embedded systems (especially those suited to 8051s), this is seldom the case: the memory size is usually fixed in the hardware design (or there may be a small number of variants), and the software runtime environment will usually be known at build-time. Of course, there are exceptions - but that's the way it usually is!