Hi guys again, I looks like I'll have to implement malloc myself, so I had a quick peek at GitHub for examples and found a relatively simple malloc implementation.
Now you guys are good at back engineering other peoples code. something I myself am not as good at. So could someone tell me how I initialise the example malloc https://github.com/Snaipe/malloc/blob/master/malloc.c
Ignore, just worked sbrk out.
how could I implement sbrk????
would someone have an example?
void * __sbrk (int nbytes);
void * __sbrk (int nbytes)
{
/* The statically held previous end of the heap, with its initialization. */
static char * heap_ptr = (void *)&end; /* Previous end */
void *base = heap_ptr;
heap_ptr += nbytes;
return base;
}
You didn't Google too hard!
Generally, there's a file called syscalls.c that implements many of the low level system functions. This is for Cortex M4, so the NVIC stuff is specific.
caddr_t _sbrk(int incr)
{
extern char end asm("end");
static char *heap_end;
char *prev_heap_end,*min_stack_ptr;
if (heap_end == 0)
heap_end = &end;
prev_heap_end = heap_end;
#ifdef FreeRTOS
/* Use the NVIC offset register to locate the main stack pointer. */
min_stack_ptr = (char*)(*(unsigned int *)*(unsigned int *)0xE000ED08);
/* Locate the STACK bottom address */
min_stack_ptr -= MAX_STACK_SIZE;
if (heap_end + incr > min_stack_ptr)
#else
if (heap_end + incr > stack_ptr)
#endif
{
// write(1, "Heap and stack collision\n", 25);
// abort();
errno = ENOMEM;
return (caddr_t) -1;
}
heap_end += incr;
return (caddr_t) prev_heap_end;
}
... I'll have to implement malloc myself, ...
... This is for Cortex M4, ...
Now I'm way confused.
1. Which toolchain for C code with supported AVR8 target does not have a malloc implementation?
1a. As often mentioned, I'd like to see the justification where malloc/free has distinct advantage in an AVR8 app.
2. What does any Cortex support have to do with this forum?
2a. I guess if one would follow the path outlined then one would have to mimic the operation of the >>operating system calls<<.
What does any Cortex support have to do with this forum?
I think this is a continuation of the OP's other thread - which was about Cortex.
That was moved to the Cortex section - so it would make sense to move this with it ...
https://www.youtube.com/watch?v=...
2a. I guess if one would follow the path outlined then one would have to mimic the operation of the >>operating system calls<<.
Shrink Your MCU code size with GCC ARM Embedded 4.7 - Embedded blog - Embedded - Arm Community
by Joey Ye
...
The diet plan for libraries
...
Newlib-nano also re-implements memory allocation functions, to replace the original ones that have overall better performance but with lots of complex logic which increases code size. The so called nano-allocator uses simple and native algorithms to handle allocation, de-allocation, and defragmentation. It works effectively when the total memory that can be allocated is small. More importantly, it is only about one sixth of the original size.
...
Edit: strikethru
Nope, to get it to work I had to write a sbrk function. Since I appear not to have the heap end specified I allocated 50MBytes of RAM and used it for the heap. Not a clean solution but it will do for now.
/* Symbol defined by linker map */
char end_[50000000]; /* start of free memory (as symbol) */
void * __sbrk (int nbytes);
void * __sbrk (int nbytes)
{
/* The statically held previous end of the heap, with its initialization. */
static char * heap_ptr = (void *)&end_; /* Previous end */
void * base = heap_ptr;
heap_ptr += nbytes;
return base;
}
You’ve made a number of assumptions that haven’t turned out to be true.
Firstly, you’ve used malloc() without checking the return value.
Since you didn’t set up the bare metal environment for malloc() to work, it returned null pointers.
You’ve then blamed Atmel/Microchip.
You then posted an incomplete question that took a bit of digging to find out exactly what the issue was.
You were then pointed to sbrk()
You created another thread (this one) in the wrong area.
To save yourself from further problems, I’d suggest you read up on how to set up your heap and stack carefully. Having megabytes of ram just opens the door for you to create dormant problems that will jump up and bite you at the most inopportune time.
It's bare metal Kartman so not a lot to go to get it up and running. There are no examples that I could use to go on for example to setup a linker script.
I know my questions are not always definitive. So sorry about that. Anyway, I've got it working which is the main thing.
Having megabytes of ram just opens the door for you to create dormant problems that will jump up and bite you at the most inopportune time.
An alternative are the memory-safe computer languages of which Rust is in use for embedded systems (embedded Linux and Windows, likely beta for bare-board arm Cortex-M, alpha for AVR)
https://www.avrfreaks.net/forum/memory-safe-computer-languages
Tock OS (cooperative OS in Rust, preemptable applications in any computer language are protected by arm Cortex-M MPU, limited range of arm Cortex-M) :
https://www.tockos.org/documentation/design
https://github.com/tock/tock/blob/master/doc/Getting_Started.md#super-quick-setup
Bare metal is where I live. No examples?
https://stackoverflow.com/questi...
Also, I gave some hints as I had recently had a similar problem. My concern is you've allocated your heap, but where is the stack? Can they collide?
where is the stack? Can they collide?
You mean with the 50M variable? Out of context, but still...
/* Symbol defined by linker map */ char end_[50000000]; /* start of free memory (as symbol) */
But we already have a solution.
The heap is only a temporary solution lads.
