STM32Cube support

[2bndy5]

Preliminary work to get this lib working in the IDE was done by @colombojrj in an unprompted PR #863

This thread is a continuation of the discussion started from that PR. Because that PR did not follow our utility/template driver files, The PR was closed and the work was cloned to a branch here upstream: stm32cube-support

Todo

• document how to integrate the RF24 lib into the IDE
• create a CI workflow to test build/compile a gettingStarted.cpp example RF24 app using the STM32 framework. This may be optional since each STM32Cube project is specific to a user-defined chip/board. It may be better to have an example repo since 1 simple STM32Cube project has so many files.
• refactor initial work to be more readable using the utility/template paradigm (while also conforming to the .clang-format style guide).

Notes

This project is predominantly CMake driven now. Any Makefiles generated for this project are geared for the armhf compiler on Linux (RPi OS 32-bit). The STM32Cube IDE defaults to using Makefiles for the arm-none-eabi-gcc/++ compilers. The new CI may benefit from a CMake driven example, but it may not be necessary if it is a project that can be imported by the STM32Cube IDE. Using PlatformIO + STM32Cube framework may help in this regard as there should be minimal setup & configuration needed in this new CI workflow.

All use of printf() in RF24 is for debugging output only. Historically, the easiest approach to debugging programs in the Arduino IDE has been using the USB Serial monitor. However, the STM32Cube IDE largely relies on using an ST-Link debugging probe. Because an app developed in the STM32Cube IDE does not automatically include enumerating a USB CDC Serial device (which is board specific), the use of printf() is redundant and should only be used if USB CDC is setup for the STM32 project. Otherwise sprintfPrettyDetails() should be more flexible in that the buffer of debugging info can be directed to any bus (possibly even through the ST-Link). Another alternative is using the encodeRadioDetails() which dumps the radio's registers' values to a uint8_t array for external interpretation.

Lastly, all documentation provided by STM is scattered (based on components or chip family) or just non-existent. Our own document on getting RF24 started with STM32 devices may require linking to community answers for additional resources 😞.

[2bndy5]

I think easiest way to integrate RF24 lib into a STM32Cube project is to add it as an included directory (-I).

Copying all the files into the project would break builds because the build system seems to compile all files under the Core/Src folder (with gcc command by default). I had to explicitly change the build command for the Core/Src/main.c file to g++ so it could #include "RF24.h which is a C++ lib (incapable of compiling with strictly a C compiler).

@colombojrj How did you try integrating RF24 into your STM32Cube project?

CMake support is secondary since STM32Cube has no support for it (by default).

[colombojrj]

Hi, sorry for the delay. Firstly, I would like to thank for the opportunity of contributing with this library.

How I would like to integrate RF24 into my stm32 code? (aka my dream)

1. If using eclipse (stm32cubeide or cubemx) I would like to clone RF24 repository, add it into my project code, disable unwanted folders (RPi, MRAA, ATTiny, etc) and adding a compiler definition in eclipse: -DRF24_STM32 (or something like that). This approach is consistent with other libraries to stm32, for example ee and ssd1306.
2. If using CMake, then I would like to clone RF24 repository, add it into my project code and add two lines in my CMakeLists.txt: add_compiler_definitions(-DRF24_STM32) and add_subdirectory(rf24).

How to add examples into the RF24 library?

When working on stm32 projects, I (usually) keep in git only the ioc file. I (usually) do not add the STM32F1 ST library. I believe we could create examples using the STM32CubeIDE software and add only the changed files (basically main.c) and the ioc file. It may be possible to run some command to automatically generate code to that ioc file from the shell. This would allow for the automatic build tests.

Example of how I actually integrate RF24 into my code

I keep a project called Nrfusb, basically a custom BluePill with the RF24 firmware library. It is very useful to our robotics team. More specifically, here you will find how I integrated the RF24 library into my code.

What do you think? I believe that I can help with the examples.

[2bndy5]

Help with the examples would be appreciated. Although I'm still not sure how to generate Makefiles that are used to drive the compiler.

After looking into the CMake support in the IDE, it seems that STM should implement official CMake support if we go that route. I don't want to rely on third party solutions/tutorials to instruct users on how to use CMake in STM32 projects.

Therefore, I think the first point (cloning RF24 into the project) should be our official approach. We can keep a few lines of code in the CMakeLists.txt, but that would be for advanced users only (& more driven by community support).

In fact, I think you actually outlined a rough draft of the document we need to create (about getting RF24 integrated into the IDE). 💯

I will do some more testing and push my changes...

---

I would also like to see better support for using a specified SPI bus, but that will come later.

[colombojrj]

Tomorrow I will port some rf24 example and I will share it here. Em sex., 9 de set. de 2022 21:52, Brendan ***@***.***> escreveu:

…

Hello with the examples would be appreciated. Although I'm still not sure how to generate Makefiles that are used to drive the compiler. After looking into the CMake support in the IDE, it seems that STM should implement official CMake support if we go that route. I don't want to rely on third party solutions/tutorials to instruct users on how to use CMake in STM32 projects. Therefore, I think the first point (cloning RF24 into the project) should be our official approach. We can keep a few lines of code in the CMakeLists.txt, but that would be for advanced users only (& more driven by community support). In fact, I think you actually outlined a rough draft of the document we need to create (about getting RF24 integrated into the IDE). 💯 I will do some more testing and push my changes... ------------------------------ I would also like to see better support for using a specified SPI bus, but that will come later. — Reply to this email directly, view it on GitHub <#872 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYPGI2MHKYRZBOQSAROXRDV5PLWFANCNFSM6AAAAAAQIMDNCQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[colombojrj]

Wow! Replying the github email post things here! Em sex., 9 de set. de 2022 21:56, José Roberto Colombo Junior < ***@***.***> escreveu:

…

Tomorrow I will port some rf24 example and I will share it here. Em sex., 9 de set. de 2022 21:52, Brendan ***@***.***> escreveu: > Hello with the examples would be appreciated. Although I'm still not sure > how to generate Makefiles that are used to drive the compiler. > > After looking into the CMake support in the IDE, it seems that STM should > implement official CMake support if we go that route. I don't want to rely > on third party solutions/tutorials to instruct users on how to use CMake in > STM32 projects. > > Therefore, I think the first point (cloning RF24 into the project) should > be our official approach. We can keep a few lines of code in the > CMakeLists.txt, but that would be for advanced users only (& more driven by > community support). > > In fact, I think you actually outlined a rough draft of the document we > need to create (about getting RF24 integrated into the IDE). 💯 > > I will do some more testing and push my changes... > ------------------------------ > > I would also like to see better support for using a specified SPI bus, > but that will come later. > > — > Reply to this email directly, view it on GitHub > <#872 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAYPGI2MHKYRZBOQSAROXRDV5PLWFANCNFSM6AAAAAAQIMDNCQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[2bndy5]

I imagine the "Drivers" folder (in the STM32Cube project) is the correct place to clone RF24 libs, yes?

[colombojrj]

Yes. I would put it there. Em sex., 9 de set. de 2022 22:39, Brendan ***@***.***> escreveu:

…

I imagine the "Drivers" folder (in the STM32Cube project) is the correct place to clone RF24 libs, yes? — Reply to this email directly, view it on GitHub <#872 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYPGI4XNT3YKMWW7MY4E7LV5PREXANCNFSM6AAAAAAQIMDNCQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[2bndy5]

I think a separate utility/STM32/includes.h should be created for the various HAL files specific to STM chips. This should ease the contribution of patches to support STM32 chips that we might be currently overlooking.

[2bndy5]

Ok. I refactored the original work to follow the utility/template better, ran clang-format on the added/modified sources, and started a how-to doc on the stm32cube-support branch.

It compiles in my local project following the steps outlined in the new doc. I relied on the IDE's auto-code generation feature, so I'm not sure if pin_mode() is actually needed.

I haven't actually run my project on my STM32F4 board (yet) because the code in main.c is not completely filled out. I just have the bare minimum to init the radio right now.

---

The SPI wrapper could be greatly improved because it now uses an OOP pointer. Meaning people should be able to use their own RF24_SPI object and pass it to the overloaded RF24::begin(_SPI* obj).

printf_P is currently a macro that takes no args. It could be defined under certain conditions (like #ifdef CDC_Transmit_FS for USB CDC Serial), but I need to learn more about the STM32Cube HALs.

[colombojrj]

Hi,
I have worked on the GettingStarted example. It depends on Serial.available() and Serial.read(). I removed the functionality of changing the radio role during operation because these methods are not available in the stm32 natively. Although we have USB_CDC_Receive, it has different purpose than Serial.read(). In short, Serial.read reads from a local buffer. USB_CDC_Receive is an interrupt/callback, invoked asynchronously. I believe that the main purpose of that example is to illustrate how to get things working. So, I am adding a lot of commentary about how the library is being integrated.

I will test the code today, and then I will be sharing it. I need to ask about how I should share the code. I have never reached this point in sharing code with people. Should I create a new branch and submit a pull request to the stm32 branch?