Broadcom WICED upgrade to FreeRTOS 8.2.2

I have started a process to port an application from the CC3200 to the EMW3162/Particle Photon but require v8.2.2. In the process of upgrading I can across some functions, seemingly present in FreeRTOS 7.5.2 that my good friend Google could only find 2, yes two, reference for and both are WICED related…. In wwd_rtos line 99 is “xTaskIsTaskFinished” and in line 121 is “vTaskFreeTerminated” No mention anythere in the FreeRTOS changelog? No mention anywhere in documentation related to porting from 7.x to 8.x? Any help on this “history”?

Broadcom WICED upgrade to FreeRTOS 8.2.2

These are not FreeRTOS functions, so I assume Broadcom have added them in themselves. Can you contact me on r [dot] barry ##at## freertos org so I can see if I can assist in getting this compiling for you. Thanks.

Broadcom WICED upgrade to FreeRTOS 8.2.2

Having completed most of the migration work, I am left with a single piece of functionality to replace. I need to find a mechanism (if possible using existing functionality) whereby a task can be forced to awake, irrespective of whether it is in a delay, or blocked on a semaphore, mutex of similar. In the current implementation the function provided simply removes the task from xEventList and xGenericList, adds it to the Ready List, sets a ForceAwake flag (they added to the TCB) then return. The challenge comes in that this ForceAwake flag is also checked in xQueueGenericReceive() to handle queue unlocking and status returns. Adding the additional code to original 8.2.2 source has been done, and all compiles and (seems to) run, but I do not feel this is a clean solution. Any suggestions?

Broadcom WICED upgrade to FreeRTOS 8.2.2

That makes sense, and it seems Broadcom have a good understanding of the code. Without the extra flag, if a task is removed from an event list, it will simply re-check the event and its timeout and if the event still had not occurred and its timeout has not expired – it will add itself right back to the event list. What they have implemented is a sort of ‘abort’ function – it might be something that is good to include in the official code too, although hopefully just by setting a bit in an existing TCB member rather than introducing a whole new one. Regards.

Broadcom WICED upgrade to FreeRTOS 8.2.2

So do you recommend I leave the Broadcom code I have brought across from 7.5.2 in my code? If so, is this something I have to manually carry across when a new version of FreeRTOS is shipped? Or is there a better way to handle, maybe send you my rough changes to see if it can be incorporated into the next release?

Broadcom WICED upgrade to FreeRTOS 8.2.2

I will look to see if there is a way of doing this using trace macros, so the code doesn’t need to be changed, or at least changed only minimally. However a this time it probably is something you will have to carry over into new versions (unless we adopt this as a feature anyway). Regards.