Dear freeRTOS As part of my project, I am starting to draw some pictures to help understand how freeRTOS uses memory and stack — because I need to prove, on my limited-resource dsPIC CPU, that my relatively simple (5 task) project isn’t going to blow (run out of space on ) the stack or the heap. Simply running the project without observing a failure isn’t really acceptable. I can’t believe that mine is the only project that requires such diligence. At the moment, these are messy pen-and-ink drawings that I intend to re-draw on the computer for digital reproduction as part of the project documentation. What is the best format for such files if I plan on submitting some of them for publication to the project?

Hi Christenson,

I can’t believe that mine is the only project that requires such diligence.

Sure, every embedded programmer faces this complex problem 🙂 On the side of FreeRTOS things are relatively simple: the kernel and API’s have a low and predictable usage of stack and heap. We programmers decide how much of the heap will be allocated by the API’s. Things get more complex if you use things like TCP/IP, or if you have ‘users’ giving variable input and commands. To simplify things, use a fixed (or at least a predictable) number of tasks. To save stack space, look if several tasks can be combined. Often this requires the use of so-called status machines, each one handling a sub-task. Some people say: observe the maximum needs of an application and multiply it by two (if you have that available). I’m sure you have found these functions:

size_t xPortGetFreeHeapSize( void );
size_t xPortGetMinimumEverFreeHeapSize( void );
UBaseType_t uxTaskGetStackHighWaterMark( TaskHandle_t xTask ) PRIVILEGED_FUNCTION;

or this one:

UBaseType_t uxTaskGetSystemState(
    TaskStatus_t * const pxTaskStatusArray,
    const UBaseType_t uxArraySize,
    uint32_t * const pulTotalRunTime );

What is the best format for such files

Whatever is comfortable for you: BMP, PNG, JPEG, or even a document is OK. You can put them here as an attachment. Regards.

Am I supposed to report typographic-level problems I catch — for example: freeRTOS 8.2.1 tasks.c has a number of comments that don’t quite make sense…such as the following fragment

if ( INCLUDE_uxTaskPriorityGet == 1 )

UBaseType_t uxTaskPriorityGet( TaskHandle_t xTask )
{
TCB_t *pxTCB;
UBaseType_t uxReturn;

    taskENTER_CRITICAL();
    {
        /* If null is passed in here then we are changing the
        priority of the calling function. */
        pxTCB = prvGetTCBFromHandle( xTask );
        uxReturn = pxTCB->uxPriority;
    }
    taskEXIT_CRITICAL();

    return uxReturn;
}

endif /* INCLUDE_uxTaskPriorityGet */

Clearly, the comment at the beginning of the critical section is copy/pasted in from uxTaskPrioritySet…..and someone forgot to change the wording. P.S. My question was NOT “what to do about the problem itself?”(I am in the middle of working that out, and have noted those functions), it was “how do I best help others with the problem?”. I have MPLAB real ICE, so for my situation, the emulator/debugger can also be used to get answers.

Thanks for taking the time to point out the error in the comments – it is appreciated and nice and quick and easy to fix. If you find any more then please post them here too. Regards.

It looks like there’s a fair number of typos hanging around. I hope you don’t mind me trying to stomp on them. Please understand that these aren’t at all on any kind of urgent priority level for me, I just think I’m a good spotter because I am reading and auditing stuff for my project. The typo monster bites me, too! Lol So here’s another: https://sourceforge.net/p/freertos/wiki/Home/ (from the second paragraph of the body text) FreeRTOS is professionally developed, strictly quality controlled, robust, supported, and free to use even in commercial applications, with no requirement to expose propitiatory (proprietary) source code.

Don’t mind at all, in fact quite the opposite, it would be nice if more people took the time. I will fix any you highlight. Regards.

Both typos have been fixed. The source code comment edit won’t be visible until the next release.

When is the next release?

The version number has aleady been up-issued in the public SVN repository (in SourceForge) but the .zip file has not been uploaded yet. We are hanging back slightly to allow additional FreeRTOS+Trace testing (by Percepio) and it might be that, following the other thread, some PIC32/dsPIC changes will be made too. The .zip file will have to be uploaded asap though is it might be that the code doesn’t change from that already in SVN.

A different problem (commissioning a rather large DC drive with some new design features and an 8051 core) is now in my lap, and I am still working on hardware checkout on my 30F5013 board. In addition, I’ve already patched my copy of freeRTOS with my preferred solution, so I’m in good shape as far as freeRTOS goes. A little cybersecurity form my boss dropped in my lap also helped today. Finally, I caught this one not because it happened to me, but because I read thee errata, had to fix my own code, and thought it a good idea to audit freeRTOS to see if it had the same problem.