PICO_USE_STACK_GUARDS and configCHECK_FOR_STACK_OVERFLOW help, but it's pretty easy to vault right past the guard bands. One trick I use is to initialize stack-resident arrays and structs to zeros with "= {}". This forces the whole object to be written to, so it's more likely to hit the guard band right away. I like to imagine that unnecessary initialization is optimized away in Release builds....
Stack Usage
...
As a quick check, instead of the "-fstack-usage" analysis, I use "-Wstack-usage=2048", for example....
Notably, to determine my startup stack usage, I enabled -fstack-usage to produce .su files on compilation, then wrote a script to go parse them and sort. Some of my bigger static init stack sizes were nearly 2k in size. I have not found a good way yet to determine total stack depth (caller/callee), but the PICO_USE_STACK_GUARDS didn't trip, so I suspect under 4k.
I find it pretty easy to switch among the FreeRTOS-Heap implementations. You might get some insight by trying "target_link_libraries(FreeRTOS-Kernel-Heap4)", for example. With Heap4, you can also do things like...
Heap
...
I am using FreeRTOS-Heap3, which uses the native malloc/free (and also moots any FreeRTOS heap sizing params). I am using only core0 at the moment.
Code:
printf( "Configured total heap size:\t%d\n" "Free bytes in the heap now:\t%u\n" "Minimum number of unallocated bytes that have ever existed in the heap:\t%u\n", configTOTAL_HEAP_SIZE, xPortGetFreeHeapSize(), xPortGetMinimumEverFreeHeapSize());I like to add "-fanalyzer" to my "target_compile_options"....
cppcheck
Notably also I ran up cppcheck against my code base, which conveniently knows about the build compile_commands.json file generated via the sdk.
...
...
Statistics: Posted by carlk3 — Sun Mar 31, 2024 8:30 pm
