-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(devboard) Add support for STM32 F103, F4, and H7 targets #81
Conversation
… with STM32 hardware CRC drivers
There simply isn't enough flash memory on this target to support CRSF for Arduino
…rements in `devboard-request.yml`
…generic STM32F103C6 target
…lt `Serialn` port if `Serial1` is not available So far, this is only applicable to STMF1 targets
…k Pill STM32F103C8
This is the last of the F4 line of STM32 support.
Right-oh. Now, I am up to adding the H7 targets. After that, that's this Pull Request done and dusted. I know there are a few more STM32 targets, however F103, F4, F7 and H7 are the main four I wanted to add, because I know for a fact that Betaflight, INAV, and ArduPilot make use of these targets. If anyone wants me to add more targets, thar quite welcome to ask me to do so via my Issues tab. I am a little disappointed at the lack of STM32F722xxxx support that the current version of the stm32 package has. But, this is easily offset by the overwhelming amount of F4 and H7 targets, as both of these seem like the desired path for Betaflight and ArduPilot, respectively anyway. Now... the person that made the request for me to add in STM32 support was not specific about the targets they wanted. The next time someone is vague about what they need me to do for them, I will ask them to be specific about their needs. |
You're getting stm32duino STM32F722 targets, care-of my own spite. You're welcome! 😈
Again, the spite won out on this one.
…ortenta H7 targets
… to Adafruit Metro M4
Right! That's it. I'm done with this Pull Request. I didn't add literally every STM32 target in existence, because this PR was starting to feel like I was bashing my head against a wall. |
Overview
This Pull Request adds a handful of STM32 targets to CRSF for Arduino's Compatibility Table.
I want to add in as many STM32 F103, F4, F7, and H7 targets as I can, provided they meet the minimum 32 KB of flash memory (see my notes below on why this is now a requirement).
Targets
Here is what's been added:
Spite won out - F722 for Arduino IDE
The abysmal F722 support in PlatformIO pissed me off that much, that I added F722 support out of pure spite.
I looked over at stm32duino and found they had every STM32F722 target imaginable. So, I thought "Right! F*** you! I need them! F722 or bust!"
This means that PlatformIO users are still out-of-pocket because the only F722 target you have is the Nucleo F722ZE. Yea, yea. I know. This pisses me off too. Go hit PlatformIO themselves up about it via their Issues tab.
I'm spiteful about the F405, F722, and H745 targets because these are literally used in all of our drone flight controllers. Especially ones that use ArduPilot, Betaflight, INAV, and RotorFlight.
I am also aware that some legacy flight controllers such as the MSH Brain2, BeastX, VBar NEO all use either STM32F103CB or a variant of STM32F405xx.
Additional notes
While working on this Pull Request, I have noticed CRSF for Arduino overflows the flash memory for targets that have smaller than 32 KB of flash memory. Even on targets that have 32 KB of flash memory, CRSF for Arduino takes up approx. 50~60 % of available space. I am not entirely sure on how usable this will be for some of you. If you run into any troubles, let me know.
I am tentatively adding some STM32F103 targets as long as they have at least 32 KB of flash memory.
If I am made aware of these targets being problematic, I may remove them at a later date, and raise the minimum required memory space to around 64~128 KB instead.
Another thing I have noticed with some STM32 targets, is they don't declare
Serial1
in their variant layer. Thus, producing a compiler error along the lines of "Undefined reference toSerial1
inSerialReceiver.cpp
in functionserialReceiverLayer::SerialReceiver()
"So, as a workaround, I'm using preprocessors for STM32 targets that automatically selects the nearest available port as the default. EG If
Serial1
isn't available andSerial2
is, CRSF for Arduino's default constructor will pickSerial2
.This only affects the default constructor. Not the constructor you use to provide your own
HardwareSerial
instance.IE:
CRSFforArduino()
👈 This constructor is affected.CRSFforArduino(HardwareSerial *serialPort)
👈 This constructor is not affected.I told y'all STM32 is a rabbit hole. =^/.~=