STM32FreeRTOS config bugged.

[Mangy_Dog]

I'm trying to introduce freertos into a project, its been a little while so I'm rusty...
However I've ran into some issue that might actually be a bug in the library.
Firstly on a fresh pull from github, the config file untouched. I get the error ... when trying to compile.

Code: Select all

..\STM32FreeRTOS\portable\MemMang\heap_1.c:61:24: error: variably modified 'ucHeap' at file scope
   61 |         static uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];

Following the defines up into the config defaults file which is called by FreeRTOSConfig.h
On line 115

Code: Select all

#define configTOTAL_HEAP_SIZE             ((size_t)((uint32_t)&_estack - (uint32_t)&_Min_Stack_Size - (uint32_t)&_end))

Which uses

Code: Select all

extern char _end; /* Defined in the linker script */
extern char _estack; /* Defined in the linker script */
extern char _Min_Stack_Size; /* Defined in the linker script */

Firstly _end doesnt exsist in the linker script, so that macro will fail right away.

Secondly _Min_Stack_Size = 0x400; /* required amount of stack */ wont fit within a char

And nor would _estack = ORIGIN(RAM) + LENGTH(RAM); /* end of "RAM" Ram type memory */ fit within a char.

If I have made a mistake in this varient setup where these defines are meant to be more properly ... defined somewhere... Or if i need to manually set these values within the freertos config. Please let me know. But at the moment this looks like a bug.

[Mangy_Dog]

Ive gone through entering the actual values to all the macros, and thats just opened a whole can of worms. Just having a whole chain of errors now.

[Mangy_Dog]

Has anyone got this version of the library working?

[ag123]

well, not familiar with FreeRTOS
but I found some inspiration from
https://github.com/greiman/SdFat/blob/m ... reeStack.h

Code: Select all

extern "C" char* sbrk(int incr);
inline int FreeStack() {
  register uint32_t sp asm("sp");
  return reinterpret_cast<char*>(sp) - reinterpret_cast<char*>(sbrk(0));
}

so here is what, sp is stack pointer the stack pointer builds downwards, so that is the bottom of stack.
sbrk(0) is actually top of heap
https://en.wikipedia.org/wiki/Sbrk
so free_memory (FreeStack) = bottom_of_stack (sp) - top_of_heap(sbrk(0))

now we go back to that macro

Code: Select all

#define configTOTAL_HEAP_SIZE             ((size_t)((uint32_t)&_estack - (uint32_t)&_Min_Stack_Size - (uint32_t)&_end))

so perhaps you can use

• sp for _estack
• sbrk(0) for _end

_Min_Stack_Size I'm not too sure the use case, it seemed to be a reserved stack size.
note that I'm not sure if this is after all correct or if it may after all 'blow up', hang, etc.

off-topic:
I found the FreeRTOS approach brittle on small memory devices (e.g. that 20k sram stm32f103c8 bluepill)
and evolved into using an event loop instead
https://github.com/ag88/stm32duino-eventloop
that is developed for libmaple, but that it'd likely work in STM core.

event loop is an effective way to multi-task using co-operative multitasking.
But that your
https://github.com/ag88/stm32duino-even ... sk.cpp#L29

Code: Select all

bool handleEvent(Event& event)

must not block. i.e. handle the event, update state in your class and return immediately

[Mangy_Dog]

Tbh ive been having a right nightmare trying to get this library to build let alone actually run. It might have been a red herrin... But also might have been part of the problem...
Whats annoying is the cubeide freertos works perfectly fine. But im not prepared to port that over yet.

[ag123]

btw those char definitions for _end , _estack don't seemed to be correct they should more correctly be unsigned char*, but I'm not sure too, there is likely some typedefs for these.

unless _end , _estack are after all markers predefined somewhere.

[fpiSTM]

Which core you used with the library?

[Mangy_Dog]

The stm stm32dunio not rogers core... But with my own custom u575 variant.

But I've managed to get it all working it seems... But I'm not quite sure how , if its fully supported at the moment...
I've now attached the library with sloeber ides own library attach tool. It does something strange. It excludes the portable folder right out.

Even though it appears I have heap4 selected in the heap config... it still builds even though heap 4 file is excluded from the build... So yeah all very strange and confusing.

But when I try to have the have the library included by having the files in my project folder. It just causes all sorts of include loop around issues with or without portable excluded from the cmake....

Im not really sure whats broken with it any more... Its just been really a pita to get working this time round...

[fpiSTM]

I'm ooo. I will test it when back.