Broadcom WICED upgrade to FreeRTOS 8.2.2

ammaree wrote on Friday, September 25, 2015:

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”?

rtel wrote on Friday, September 25, 2015:

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.

ammaree wrote on Tuesday, September 29, 2015:

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?

rtel wrote on Tuesday, September 29, 2015:

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.


ammaree wrote on Tuesday, September 29, 2015:

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?

rtel wrote on Tuesday, September 29, 2015:

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).