Reasons for outdated versions of third party software in Wifi SDK

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

As part of my [process to understand the changes between the previous version and the current, primarily in the FreeRTOS space, I started with a comparison between your modified v8.2.1 and the original v8.2.1.

This comparison raised a couple of questions that I would appreciate some feedback on, just to better understand your strategy with respect to FreeRTOS.

Q1. The version of 8.2.1. used by Broadcom as foundation is slightly different from the released 8.2.1 version. Did you use a pre-release as basis for your work? For examples see

     heap_3.c,

     queue.c    in xQueueGenericCreate()

     tasks.c    in prvInitialiseTCBVariables()

Q2. Considering that FreeRTOS v8.2.3 has been available since mid October and considering that a number of bugs have been fixed in the last 2 revisions, are there any plans to release SDK v3.5.x based on FreeRTOS v8.2.3 rather than the 9 month old 8.2.1?

Q3. Since a number of your changes such as NO_MALLOC functionality and the OpenOCD enhancements makes sense, have you ever considered engaging with Richard Barry / Real Time Engineers for them to consider including some/all of your requirements into the base FreeRTOS functionality?

Q4: Regarding LwIP and the use of version 140rc1, a final version v1.4.1 has been available since 2012, any specific reason for continuing with rc1?

Q5: FreeRTOS is making significant progress with their open source PlusTCP stack, and from our examination it looks very neat, clean and well integrated with the RTOS. Any possibility of replacing LwIP with Plus TCP since that will remove a significant degree of complication that comes with LwIP?

As a company we develop applications that need to run on 3 different platforms, one of which is USI/WICED CM3 based. The changes made in the ARM CM3 port forces us to also relook one of our other platforms which is CM4F based.

Having to twice test and debug a portion of "supposedly" common code ie FreeRTOS that is now not really common any more, makes life very difficult....

All feedback appreciated.

Andre

2 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Adding the Wi-Fi team: gangi  vik86  abirjepatil  nikvh  bdawood seyhan

0 Likes
Anonymous
Not applicable

ammaree

1. We have made some changes to FreeRTOS which may account for the differences.

2. We do intend to update to the latest FreeRTOS however doing so creates a large test burden as we must verify the behaviour for all our applications. We must also take into consideration the needs of customers who are in, or very near to, production and do not want to modify their RTOS at the last minute.

3. We have engaged with the FreeRTOS team and have discussed merging our changes back to the FreeRTOS mainline.

4. No specific reason for continuing with rc1 apart from the requirement to perform full regressions tests of all network features.

5. WICED can support multiple network stacks and we have spoken with the FreeRTOS team on porting their network stack to WICED however there are no specific plans to do so internally.

Can you expand on the changes made to common code that unfortunately increased your test burden?

0 Likes