V4.8.0 is now available for download as a release .zip file.  This will not get announced on the FreeRTOS.org site until I have written documentation for the new features.  The change history is available here: http://www.freertos.org/History.txt. Regards.

Richard, you probably get this all the time but I wanted again to say thank you for your excellent work. I use your RTOS on my home projects for some time now and I think it is just great. Thank you again. Regards, Borut

Thanks :o)  Its always nice to hear. Regards.

Hi Richard! Nice work!!!! I’m happy to see in this release some features we discussed in forum! I appreciated trace macros in the core api!! Just some questions: 1. I saw in task.c this code for stack highwatermark: #if ( INCLUDE_uxTaskGetStackHighWaterMark == 1 )     unsigned portBASE_TYPE uxTaskGetStackHighWaterMark( xTaskHandle xTask )     {     tskTCB *pxTCB;         pxTCB = prvGetTCBFromHandle( xTask );         return usTaskCheckFreeStackSpace( ( unsigned portCHAR * ) pxTCB->pxStack );     } #endif This code can give information about the worst level reached by the stack. If you want only the current stack size, can we do something like: (pxTCB->pxTopOfStack – pxTCB->pxStack) to obtain the current used stack? 2. I didn’t use in the past ricursive mutex… so i hope we” find some explanation in api documentation in website 3. what’s the purpose of portCriticalNestingInTCB ???? bye, Piero

> Nice work!!!! Thanks. > I’m happy to see in this release some features we discussed in forum! Not everything yet, but we are getting there. > I appreciated trace macros in the core api!! I’m just writing the documentation for those now and realise that some are not placed in optimal positions to get out the best information.  I will make some minor adjustments for the next release but these will only be tiny. > Just some questions: > > 1. I saw in task.c this code for stack highwatermark: > > #if ( INCLUDE_uxTaskGetStackHighWaterMark == 1 ) > >     unsigned portBASE_TYPE uxTaskGetStackHighWaterMark( > xTaskHandle xTask ) >     { >     tskTCB *pxTCB; > >         pxTCB = prvGetTCBFromHandle( xTask ); >         return usTaskCheckFreeStackSpace( ( unsigned > portCHAR * ) pxTCB->pxStack ); >     } > > #endif > > This code can give information about the worst level reached > by the stack. > If you want only the current stack size, can we do something like: > (pxTCB->pxTopOfStack – pxTCB->pxStack) to obtain the current > used stack? On the assumption that the stack is growing down (correct for nearly all architectures), pxStack will be the lowest address toward which the stack is growing, so I think it would be more like ( total stack size – ( pxTCB->pxTopOfStack – pxTCB->pxStack ) ) to give the actual current stack usage rather than the high water mark. > > 2. I didn’t use in the past ricursive mutex… so i hope we” > find some explanation > in api documentation in website That was there already.  See http://www.freertos.org/xSemaphoreCreateRecursiveMutex.html and FreeRTOS/demo/common/recmutex.c. > 3. what’s the purpose of portCriticalNestingInTCB ???? Ports that use a critical nesting count have to save and restore the critical nesting count as part of the task context.  This means the save/restore asm code has to access the critical nesting variable and push/pop to/from the stack.  As this is done in asm code it is different for each port.  As an alternative I decided that the critical nesting count could actually be stored in the TCB, this way the saving and restoring of the critical nesting can be done in a portable way from C code rather than from asm code.  The PowerPC port (being the newest) is the only port that uses this mechanism so far.  It is RAM neutral in that you save a word of stack space, but loose a word in the TCB. Regards.

> On the assumption that the stack is growing down > correct for nearly all architectures), pxStack will > be the lowest address toward which the stack > is growing, > so I think it would be more like > ( total stack size – ( pxTCB->pxTopOfStack – pxTCB->pxStack ) ) > to give the actual current stack usage rather than the high water mark Richard, … yes, i think this is a good solution. Do you think is it possible to add a function for this (with different implementation depending on stack grow define), in the next release? And, OUT OF THREAD, a question asked to me by our legal office: If i use freertos for our commercial embedded device (so, firmaware is distributed INSIDE the microcontroller, no binary file is provided), and we want to be compliance with freertos license (without distribution of our application source code), have i to add in OUR WEBSITE link to freertos website and link to freertos download page? OR other actions are NECESSARY? Thanks, Piero

With respect to the license.  The GPL states you have to document that the product uses FreeRTOS.org, and give a written offer to provide the source code to anybody that requests it.  These days of coarse getting the source code is simply a matter of going to the WEB site and downloading it so it makes no sense for you to be posting it to people on a CD.  Therefore I am satisfied that the criteria is being met if you tell people where they can obtain the source code, which is basically just a link to the FreeRTOS.org site.  "This product uses the FreeRTOS.org real time kernel – the FreeRTOS.org source code can be obtained by visiting http://www.FreeRTOS.org" would seem to suffice.  Tiny print in the back of the manual, or on the product page of your WEB site. You can of course remove this requirement by buying a commercial license, very reasonably priced :o)  See http://www.OpenRTOS.com for details.

Thank you Richard. FreeRTOS is really a great "little" RTOS. It fits neatly in the tiniest of spaces and does exactly what it says on the tin. I just integrated the latest version (v4.80) into my project and got two compile errors when compiling for an AVR ATMega platform using winavr (20071221 i.e. gcc 4.2.2) In queue.c there is a slight little type inconsistency of the return value of the following two functions: portBASE_TYPE xQueueIsQueueEmptyFromISR( const xQueueHandle pxQueue ); portBASE_TYPE xQueueIsQueueFullFromISR( const xQueueHandle pxQueue ); should be signed portBASE_TYPE xQueueIsQueueEmptyFromISR( const xQueueHandle pxQueue ); signed portBASE_TYPE xQueueIsQueueFullFromISR( const xQueueHandle pxQueue ); to be consistent with the definition further down in the file or change the return type of the definitions. Otherwise all is working as before, just better response times for queue operations. Great work as usual.

Thanks for pointing that out – I have added the ‘signed’ but not yet checked the files in.  Trying to compile with a dozen different compilers that don’t all agree! Regards.