Hey guys,
since realloc isn't ANSI C and for that not support by KEIL I tried to create my own realloc function.
But - as usual - I have some pointer trouble :-/ .
Here is my try for this memory reallocation function. But it doesn't compile because of the statement in the for loop:
void* Memrealloc(void* pvMem, uint32_t ulNewSize) { int i; char *ptr; //Pointer for the new memory area ptr = (char*)malloc(ulNewSize); //Allocating the amount of requested memory for (i=0; i<=ulNewSize;i++) { ptr[i]=(char*)pvMem[i]; //Copy the old content of the memory } free (pvMem); //Deallocating the old memory return (void*)ptr; //Returning pointer to the new memory }
Thats the error I get: Source\OS_Custom.c(79): error: #852: expression must be a pointer to a complete object type
What is happening here? What do I have to do to fix it?
since realloc isn't ANSI C
You might want to check your presumptions a bit better before embarking on a journey as perilous as that....
and for that not support by KEIL
While you're at it, you might want to re-check that one, too.
Sorry for that. I must have messed up something. Because Keil's ARM compiler told me, that realloc is an unkown object. Maybe there was a typing mistake. Now, it "works" (I mean, the compiling does work...)
But you are right, guys, I guess its a stupid idea to use realloc on a µC without a running OS, when I have not much experience. :(
The thing is, that I have a hardware (a field bus communication modul) here, that is connected to my host controller with an external dual port memory (host bus 8). And the communication with that hardware runs using this dual port memory. The hardware comes with a software toolkit (a bunch of functions) - and to be able to use that, I have to specify OS-depended functions.
Ok, now I checked it again: Realloc doesn't seem to be necessary in the end (I looked at an example code, using basic functions for that hardware). But a function to allocate, copy and compare memory is necessary. What happens if I use malloc, memset, memcmp on a µC (in my case a cortex m3)? Or let's say: What do I have to do, that it does the right things? Is there a way? How can I learn more about that?
What happens if I use malloc, memset, memcmp on a µC (in my case a cortex m3)? Or let's say: What do I have to do, that it does the right things? Is there a way? How can I learn more about that?
One thing could potentially be a problem: memset(), memcmp() and others may use 8-bit, 16-bit or 32-bit access to memory. If that's not a problem for your hardware (say, it's connected to an 8-bit bus anyway), then by all means do use these functions from the standard library. If malloc() is required by the proprietary library supplied with the hardware, do use it. Just make sure you know what you are doing: that you've allocated a proper amount of memory for the heap, that you'll not end up with memory leaks or heap fragmentation.
Often, communication is performed in sequence, in which case it's possible to use a ring-shaped buffer structure with preallocated memory. Sometimes with fixed-sized objects. Sometimes with a large vector where you allocate n bytes after previous allocation, or in case it doesn't fit, starts from the beginning.
The danger, when memory are allocated in random sizes, and released in random order, is that you could get a fragmented heap, where you get small holes that are too small for your next allocation, but that are not being merged because you have other allocations in-between them. With devices that runs for very long times, this can be very hard to test.
Thank you!
One thing could potentially be a problem: memset(), memcmp() and others may use 8-bit, 16-bit or 32-bit access to memory. If that's not a problem for your hardware (say, it's connected to an 8-bit bus anyway), then by all means do use these functions from the standard library.
I have a 32-bit µC and the external ram is connected with 8-bit. So in my opinion this doesn't mean, that I should be go. It rathe means: I would have a problem, if malloc really will use 32-bit access - wouldn't I? How can I find out, which bitwidth malloc uses when accessing the memory?
Just make sure you know what you are doing: that you've allocated a proper amount of memory for the heap, that you'll not end up with memory leaks or heap fragmentation.
I would if I knew how :) - I guess I have to tell my linker that it should use malloc only to allocate memory from the external ram. This means, I have to change the start for the heap to the starting address of the external ram - or am I wrong here?
Often, communication is performed in sequence, in which case it's possible to use a ring-shaped buffer structure with preallocated memory.
That sounds like a possible plan B. I could maybe simply allocate all of the external memory. I just sent an email to the support of the manufacturer aksing if it's possible to work with static memory allocation.
I would have a problem, if malloc really will use 32-bit access - wouldn't I? How can I find out, which bitwidth malloc uses when accessing the memory?
Note that I didn't say malloc(). I said memset(), memcmp() and others. This issue doesn't apply to malloc().
I guess I have to tell my linker that it should use malloc only to allocate memory from the external ram.
Well, I don't know. Normally, you would do this if you had insufficient on-chip RAM and plenty of external RAM.
I think you should develop some understanding of the way your program is supposed to work. Simple instructions like 'use external RAM for heap' can easily be irrelevant to your situation. There can be subtle issues involved.
I said memset(), memcmp() and others.
You are right. I guess I like assuming to much random stuff... :-)
I think you should develop some understanding of the way your program is supposed to work.
You are right, again. I will do that. I thought, that it would be a smart approach to first get all suggested requirements done, but I should really do some basic use of those functions first to see, what I actually need.
I'll be back :)