Closed ZZ-Cat closed 9 months ago
Right-oh. Now, I am up to adding the H7 targets. After that, that's this Pull Request done and dusted.
Gods, this was a rabbit hole and a half! =>/.<=
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.
They literally copy-and-pasted "Please add stm32 support" into their Issue several times over. Please do not do this, next time.
It doesn't do you any good, if you're not specific about what you need me to add.
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.
Failing that, I will close their Issue, if they give no response after more than two weeks.
Right! That's it. I'm done with this Pull Request.
Currently waiting on the PlatformIO checks to pass, and this sucker can be merged!
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.
I feel like there is enough there for most people to be happy. If someone wants me to add their super-obscure target, thar more than welcome to let me know via my Issues tab.
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()
:point_left: This constructor is affected.CRSFforArduino(HardwareSerial *serialPort)
:point_left: This constructor is not affected.I told y'all STM32 is a rabbit hole. =^/.~=