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.
When:
init_mempool(0x0000, 1024); p = malloc(10);
init_mempool(0x2000, 1024); p = malloc(10);
As it says in the Manual, "Source code is provided for this routine in the \lib directory. You can modify the source to customize this function for your hardware environment." Why don't you just have a look?
stay away from the allocs the '51 is NOT a PC Erik
What version of the compiler do you use? What is the return value from init_mempool? Jon
"stay away from the allocs the '51 is NOT a PC" Very true. Perhaps you should just take a step back and ask youself why you want to use dynamic memory allocation on a small embedded controller like the 8051?
What else in your program might use memory starting at address 0? Have you reserved that range of memory to use as your heap? I'd expect the heap to start near the top of memory (under any reentrant stack), unless you have no other xdata usage whatsoever.
"What version of the compiler do you use?" "What is the return value from init_mempool?" The version of the compiler is C51_6.23a. And I remember init_mempool returns nothing.
"Perhaps you should just take a step back and ask youself why you want to use dynamic memory allocation on a small embedded controller like the 8051? " I'm designing GUI components which will be displayed on a LCD panel. Each component is a small rectangular window on the display. To paint the component, I first get a canvas from the component, then draw shapes and strings on it, finally paint the canvas onto the display. The canvas is essentially a block of memory, whose size is different from component to component. Yes I can pre-define a global (or static) canvas which is big enough to hold any individual components. And there is nearly no more benefit to use the dynamic memory allocation than the fixed memory allocation in terms of the usage of memory. But the former seems more elegant, I think. Anyway, I appreciate your advice, and perhaps I will take your advice some day.
"As it says in the Manual," "..." "Why don't you just have a look? " I did have a look at the source code. But at the first glance, the code is so complicated that I wasn't patient enough to read it through. Now I know this was not the case. Maybe the macro and typedef make things that. But it seems that there is no need to read it any more -- I think I've known where the question lies. Thanks anyway. d.curie
"What else in your program might use memory starting at address 0? Have you reserved that range of memory to use as your heap? I'd expect the heap to start near the top of memory (under any reentrant stack), unless you have no other xdata usage whatsoever. " Yes, this is the matter. An array should be declared to reserve the memory used by the heap. I'm thinking why init_mempool doesn't do that for me? Thanks a lot. d.curie
I'm thinking why init_mempool doesn't do that for me init_mempool() is just a C function. It can't do anything until the code is running on your hardware. Allocating variables to particular addresses, however, is done by the linker, before the code ever starts running. The addresses of variables are embedded into the code. You need to tell the linker where you plan to put the heap, so that it can be sure to keep other variables out of that address range.
Yes. When I try to modify the source code of init_mempool to provide the function reserving the memory heap, it's obvious that I can't accomplish that, just as what you've pointed out.