STM32 ThreadX target platform

[g4sp3r]

Hi,
At Ubiquity robotics we are happy users of zenoh-pico running on multiple of our stm32 based embedded projects 😍

We would like to contribute back this pull request that adds new STM32 platform with ThreadX system implementation.

Currently only supports serial transport. Implementation is with circular DMA for data reception.

[github-actions]

PR missing one of the required labels: {'documentation', 'bug', 'new feature', 'internal', 'enhancement', 'breaking-change', 'dependencies'}

[jean-roland]

Hello @g4sp3r, thanks for your contribution, it seems the PR has two issues currently:

• Formatting is not correct, please run find include/ src/ tests/ examples/ tools/ -iname "*.ino" -o -iname "*.h" -o -iname "*.c" | xargs clang-format -i in your zenoh-pico repo, you'll need to install clang-format if you haven't.
• Your threadX files seem to be visible from other systems, make sure the includes are guarded against that.

[jean-roland]

Highly possible the cpp CI failure is due to a flaky test and not related to your changes, so don't worry about it for now.

[sashacmc]

Dear @g4sp3r, thanks for your contribution!
Some cosmetic fixes.

I'm also curious, it seems strange that we can't do without copying the source files and manually excluding some of them from the project. Doesn't the build system provide an option to use a proper CMake file to do this, as it does for other platforms?

[g4sp3r]

Hey @sashamc! Thanks for your fixes. They are accepted and PR is updated.

About the project setup, I am also not a fan and understand your concerns.

In my experience, most of the users will probably work with STMCubeIDE (eclipse) using CDT managed build and gui tools to configure their project and peripherals. This is also how our projects were configured from start and is also the way most of the examples for stm32 you can find online are done.

You can see the examples in this PR don't do any peripheral or kernel initialization so user needs to provide those layers by themselves. But this means examples could be run on any target that the manufacturer toolchain supports.

The main issue I see for CMake support is that the landscape is wider than for other platforms. To give some examples:

• Correct hal drivers would need to be downloaded from ST for which license agreements need to be accepted.
• threadx low level initialization is done in assembly and generated by the project configuration tool.

I am not saying its impossible to do a CMake build for stm32 target, I just think this way will be better suited for majority of users.

At some point support for libopencm3 can be added but it will surely support less targets.

Maybe the instructions are not clear, but zenoh-pico could also be located outside your project folder. What is required is adding one source and one include path to the project configuration together with other defines. The exclusion pattern is used because it requires less operations from user than adding each folder in src/ individually. If all the system.c and network.c files from every platform would have #ifdef guards, then this exclusion pattern would not be needed.