Using FreeRTOS from STM32Cube

[g-arjones]

Is there a reason for not using FreeRTOS from the STM32Cube repository as you do with CMSIS and BSP? That would also allow using features from CMSIS RTOS.

[Hish15]

Hi,

It ca be added to the Readme, but you can freely give the path to the FreeRTOS, included in STM32Cube ${STM32_CUBE_H7_PATH}/Middlewares/Third_Party/FreeRTOS for instance.

Forcing this version does not makes sense (In My Opinion), since you get stuck with the version released by ST.

[Hish15]

I miss read you, If you are speaking about CMSIS-RTOS is different since, ST does provide the upper layer needed to have a CMSIS-RTOS wrapper around the FreeRTOS included in their release.
In this case this might be a duplicate of #160

++

[g-arjones]

Indeed, yes. I guess I can implement the finding of CMSIS-RTOS in FindCMSIS.cmake. Would you accept a PR for that?

[atsju]

Hi @g-arjones,
I am not official maintainer of this project (neither is @Hish15 ).
But the functionality seems good so you can definitely do a PR. Note that merging could take some time though.

[g-arjones]

Note that merging could take some time though.

That's bad news, I kinda need these changes (especially the env var one). How long does it usually take? I may have to give up on the PR and keep my fork.

[Hish15]

Hello @g-arjones,
Please consider making the PRs anyway.
You can keep your fork while things are not merged, but sharing will be appreciated (We might help you discover some side effects on your changes too 😄)

[atsju]

I'm talking about months sometimes :/

I think what you could do is make the PR ( you need the code in your fork anyway) and then use your fork as long as the PR is not merged. Once the PR is merged you can switch back to official repo.

From personal experience I highly recommend you switch back to official repo once it's merged. In long term, you have lot less maintenance effort, the community benefits from your changes and you benefit from new features also.

[g-arjones]

Just did that. See #189 and #190