Determining RAM available at compile or run time

[mikeprotts]

I want to be able to allocate a large static circular buffer, where I will use as much RAM as I can up to a certain amount, e.g. I might want 64KB, but if there is not sufficient RAM I'd allocate maybe 16KB. The buffer is accessed in 2KB chunks, using an array of pointers. I want to make the code portable between STM32F4, F7 and H7 ranges, but I can't see an obvious way to determine RAM size at compile time. At the moment I use a different makefile for the boards I'm using, so I set the buffer size there.

The RAM is described in the relevant processor files, but with start address, and then the size in a comment, but the definitions are not consistent (e.g. SRAM1_BASE in stm32f767xx.h and D1_AXISRAM_BASE in stm32h743xx.h, and the definitions do not give an end address or size. The information is available at link time (coded into the linker script file).

It may make more sense to determine the free space at run time (chCoreGetStatusX()), and allocate at initialisation time (chCoreAlloc()), but that adds a bit more complexity with managing pointers (as I would need a dynamic list rather than static array).

Any suggestions welcome. Is it better to allocate dynamically or statically?

Mike

[Giovanni]

Hi,

It is better to allocate statically but you cannot know the free RAM size at compile time, it is calculated at link time.

You could use the two symbols exported for the core allocator and not use it: __heap_base__, __heap_end__.

Overall it is easier to just allocate it using chCoreAllocFromTop().

Giovanni

[FXCoder]

Hi,
Consider the memory pool system (chmempools) as a convenient means of managing the allocation and free listing of an array of arbitrary memory objects.
Once you determine the free core at runtime just allocate a percentage of core memory to your pool of objects.
Then depending on your use case the objects can be just plain buffers managed by a simple linked list.
Or the objects could embed another management object such as a queue (halqueues) with a matching embedded buffer inside the main object.
This is good for for high side (ISR) -> low side(thread) queue handling.

There are plenty of options in ChibiOS for queues, fifos, (including factory system) etc. to help.
--
Bob

[mikeprotts]

Thanks for these tips.

I'm moving data from ISR to buffers to allow for network latency, so the hal queues idea makes sense. I'll try chCoreAlloc to create the appropriate size, and then create my pool. As I should be able to do this before I start anything time critical, it shouldn't need too much change in the main processing.

Cheers
Mike