ARM Cortex-M Microcontroller startup files

Jens Bauer via Digitalmars-d digitalmars-d at puremagic.com
Fri May 1 21:53:48 PDT 2015


On Saturday, 2 May 2015 at 02:08:40 UTC, Mike wrote:
> On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:
>
> IMO it should be opt in.

Agree. :)

The problem I've seen with most C-solutions, is that once someone 
uses printf, the binary suddenly grows out of proportions. (It 
may be because the programmer included a line for debugging only, 
and that causes the otherwise 1K program to be huge and almost 
not fit the MCU).

> Also, aren't you using this malloc 
> (https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/malloc.c?at=default).
>  That looks small and tight, but should be written in D :-)

It looks small and quite quick, but I think it would choke if 
allocating 256 blocks of 1 byte each and then freeing the first 
255 of them. But I absolutely like the simplicity.

I wrote a (much larger) MiniMalloc (also C), which can take any 
number of blocks and any size.
The block address is guaranteed to be on a 4-byte boundary.
Allocating a block of size 0 will always return the same address; 
this can never be freed.
The good part is that you can use it with fairly small 
microcontrollers up to the entire 32-bit address range and no 
maximum number of blocks/maximum block size, so you can easily 
allocate a couple of buffers for your 24-bit TFT display.
The drawback: If you make a 'buffer-overflow', eg write past your 
block's memory, you will corrupt the header of the next block, 
because I placed the header in front of each block.
Thus my malloc/calloc/realloc/free is very old-fashioned, but it 
does join neighbouring blocks when they're released. I've 
stress-tested it for more than 24 hours, and even though it was 
fairly fragmented, there were no signs of other problems. It's 
been tested with 0xdeadbeef fills, 0x00000000 fills and unfilled.

Is it possible to write the malloc so it's "garbage 
collector-friendly" ?
-Eg. would certain algorithms be better than others; would a few 
'accessor' or 'query' functions be helpful; would it be useful 
for the garbage collector to be able to store a couple of flags ?


More information about the Digitalmars-d mailing list