someone elses malloc

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

This topic has a solution.
Last Edited: Mon. Aug 20, 2018 - 09:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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;
}

 

 

Last Edited: Mon. Aug 20, 2018 - 02:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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;
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fianawarrior wrote:

... I'll have to implement malloc myself, ...

 

Kartman wrote:

... 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<<.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. Aug 20, 2018 - 01:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
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=...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
2a.  I guess if one would follow the path outlined then one would have to mimic the operation of the >>operating system calls<<.
arm's Red Hat newlib does that though arm newlib-nano for most arm MCU.

Shrink Your MCU code size with GCC ARM Embedded 4.7 - Embedded blog - Embedded - Arm Community

by 

https://community.arm.com/iot/embedded/b/embedded-blog/posts/shrink-your-mcu-code-size-with-gcc-arm-embedded-4-7

...

 

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

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Mon. Aug 20, 2018 - 06:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OP is blaming the C lib for bugs in his own code - see previous threads.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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;
}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
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.
Concur for the common computer languages as there's some to a lot of effort for such defect prevention.

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

https://github.com/avr-rust

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
where is the stack? Can they collide?

You mean with the 50M variable?  Out of context, but still...

Fianawarrior wrote:
/* Symbol defined by linker map */ char end_[50000000]; /* start of free memory (as symbol) */

 

But we already have a solution.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Tue. Aug 21, 2018 - 04:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The heap is only a temporary solution lads.