When digging around in .platformio/, one can find a multitude of platform-framework combinations, with the ST-framework related packages holding a folder called Middlewares/. In there, useful middleware such as FreeRTOS, FATFS and USB can be found. Here is an example path for the STM32G4:
~/.platformio/packages/framework-stm32cubeg4/Middlewares
As far as I understand the build process, the contents there aren’t built or linked; they just sit there, closely resembling the same structure that a STM32-Cube-IDE project might have.
When looking for examples online for an inclusion of these middlewares (e.g. FreeRTOS), lib_deps is used to specify a FreeRTOS (or other middleware) inclusion, see this. This then proceeds to download, build and link a library from the registry, but why do that when it is already present in the package? To achieve this, some users have tried the following:
- Using
lib_extra_dirswith theMiddlewarepath - Custom
extra_scriptfor middleware building and linking - Another custom script
I myself also used a custom script (for reference), which seems to reinvent the wheel again and again. I did not look at middleware of other platforms, but I infer that they have similar “unbuilt” middleware. What is the proper way to iclude these middlewares in a project? Since they are part of the PIO package structure, I wonder if it would be the easiest if such files were to be treated as library with their own library.json. The build process could then use that library if a specific macro is appended to the build_flags or lib_deps contains a path, not a registry entry. It seems complicated and redundant to fetch an entirely new copy of the FreeRTOS source from the registry when it’s already there on disk or to write an entire script to link these deeply nested source files. Any thoughts on this? I am also curious as to why this was not implemented, maybe there’s a good reason for it that I have yet to spot.