AVR Freaks

Be aware that avr-size only reports statically allocated data. How are the stack sizes specified in FreeRTOS? Unless they are specified in a way that results in them being statically allocated they won't show up in the avr-size output.

What you probably need is additional information about the dynamic requirements, i.e. how much stack space does each task need (including the worst-case space for all ISRs you're using). You can determine this empirically by seeding each stack with a known value, running the tasks (making sure that all paths through the code are taken), and then determining how much of the stack space each task is "unused".

Another strategy is to use a static analysis tool to determine the worst-case stack use of each task. There have been several discussions of stack use analysis on this forum and someone (ezharkov perhaps) posted code for a tool that works for a well-defined subset of all possible applications. You'd probably have to modify it to compute stack use for multiple tasks.

See the thread below, for example, for more information.
https://www.avrfreaks.net/index.p...

Oh, and one other thing: The space for the task info (TCB) and it's stack is allocated using vPortMalloc which uses heap space you have pre-allocated using the setting in FreeRTOSConfig.h:

Make sure you allocate enough spavce for all the tasks you intend to create, plus the space you intend to dynamically allocate using vPortMalloc().

Stu

Once you make the choice of using an RTOS then it's generally the case (with the proviso that fragmentation may be an issue) that malloc() will become your new friend. For small automatics up to (say) 32 bytes then continue to have them created on the task stack. But for any "large blob" use malloc() from the shared, system heap and don't forget to check the returned pointer for being NULL ! Be aware that the fragmentation issue will be worse if you have a lot of tasks all sharing heap usage - you may want to keep most of the data heavy stuff in a single task to avoid this and try to watch the sequence of malloc()s and free()s to avoid fragmentation as much as possible.

First off, sorry for the late post. I have not been able to follow 'Freaks as often as I once did.

Yes. Each task is cut from the FreeRTOS heap. The heap allocated to FreeRTOS' heap manager is static; it is reflected in the standard RAM measurements. It's set aside in .bss, IIRC.

Ummm, no. The 425 bytes are pulled from the 100 bytes of FreeRTOS heap (along with the TCB overhead). It depends on whether you use a static or dynamic allocation for your arrays. The task information and the stack for each task is allocated out of the heap provided to the FreeRTOS heap manager. If you use pvPortMalloc() to allocate any dynamic storage, that too will come from the heap provided to FreeRTOS.

In your calculations, the 2*85 + 255 bytes of stack comes out of the FreeRTOS heap (along with, of course, the space allocated for the TCB (Task Control Block).

I would say in this case that pvPortMalloc() is his best fried. the system supplied malloc() will pull space from whatever is left of RAM after allocating all the static structures, including the FreeRTOS heap.

On the other hand, global variables are still allocated from the system heap, not from the FreeRTOS heap. If there is a task that requires a buffer to be allocated and deallocated often, it may make better sense to statically allocate is as a global and avoid malloc/pvPortMalloc completely. I would certainly put any variable/buffers that interface to an ISR into a global!

Now this is very true. The default FreeRTOS heap manager (type 1) is pretty stupid. Type 2 is usually good enough but does not re-coelesce very well. Type 3 is supposed to be the "high-zoot" version, although I have never used it.

A coworker added some code to the Type 2 heap manager (and called it "2.5") that would coelesce chunks of freed memory that were next to each other. His usage was temporary storage for logging and the chunks were usually allocated and then deallocated at roughly the same time. This left "bubbles" of free space at the top of the heap. His modified heap manager looked for those and combined them into one big freespace on-the-fly. If you run into problems, let me know and I'll post the code.

Stu

Are there any tools that can be used to debug a RTOS app. ? How do you track heap usage in a multi-MB RAM app. like a digital recorder ?

This is not normal. Since (I hope) you are using a makefile, request a map file be generated. You should find the space allocated under .bss to heap_1.o. In my case, it it looks like:

where 0x177d (6013) bytes are allocated to heap_2p5.o (my heap manager). When I last compiled this I believe I had 6000 bytes allocated to the heap. (Ya gotta love that ATmega2560! Xmegas are even better! :D)

That is, unfortunately, the situation here. I set my heap space to take almost all of the free space left after global allocation to avoid this. (There is a problem with this approach: FreeRTOS needs "native" stack to wake up; all initialization runs in the native stack until the tasks are awakened. I had to be careful with my I/O and task initialization routines to not overrun the FreeRTOS heap during wakeup.)

My suggestion with stack over/underflows (if this is the case) is to use JTAG and data breakpoints (with masked range). This works much like a simplified MPU.

Debugging OS without dedicated tools can be painful. I wonder how FreeRTOS (which is written in C) checks task stack under/overflow run-time (even with statical allocation of these stacks).. It must be aware calling a function, if SREG_I is set, requires 2*2/3 pushes + all extra arguments actually before each foo() is called. Even more when prologues are called. Some, like printf, have variable arg count. And the foo itself can have autos on the stack - pretty complicated.

If there is a method of run-time stack range check in C, perhaps this can be easily ported to regular no-OS applications, similar to assert()?
Like:

Who knows how to check this with AVR-GCC in run-time?