ZZ-Cat
commented
7 months ago It appears I may have hit a wall with this.
According to the documentation, external CRSF transmitter modules are using inverted half-duplex UART.
This could severely limit my options here, because a lot of supported targets don't have the ability to invert their GPIO pins what service UART. The SAMD51J19A being one of those.
I'm not entirely sure on where to go from here, because of that actually. I really feel like I have hit a wall here.
Probably the best thing for this Pull Request for the time being is to have it so that the Serial Transmitter Interface only works with internal transmitter modules, because those use full-duplex non-inverted UART. That is more straightforward.
Writing full-duplex is incredibly straightforward, because it means I don't need to get into the bare metal side of things. Whereas with half-duplex, that's a little more involved, and not all hardware natively supports it (let alone the ability to assign custom UART pins). Even with targets that support it, I still need to write the parts where one pin and pad combination is swapped over (EG from Tx to Rx and vice versa), and that almost invariably involves bare metal coding - IE Dicking around under the hood with direct hardware registers.
IIRC, I did enable the ability to assign custom UART pins on supported hardware... so, it's likely that the Serial Transmitter Interface may only work with these targets if someone wants to use CRSF for Arduino with an external module (such as the RadioMaster Ranger).
ABLomas
dbloemhard
Woz4tetra
Overview
This Pull Request will bring in an exciting new feature: The Serial Transmitter Interface.
Details
If you recall the Serial Receiver Interface is the middleware layer between your Sketches (via the Sketch Layer) and your connected ExpressLRS or TBS Crossfire reciever (via the Hardware Abstraction Layer, which is managed by the Arduino API for back-end functionality).
The Serial Receiver Interface is so-called this because it implies CRSF for Arduino communicated with your connected ExpressLRS receiver. EG A RadioMaster RP3.
The Serial Transmitter Interface will add bi-directional communication to-and-from your handset's internal transmitter module.
Up until now, I have been focusing on the receiver-to-"flight controller" end of The Crossfire Protocol, and I had not even thought about the handset's side of the protocol... until it was brought to my attention by a group called Atopile and their Swoop project.
Atopile have asked me to put the Serial Transmitter Interface together, so that it MAY serve as the communications between the handset itself and its internal ExpressLRS transmitter module.
How this has impacted my quality-of-life and what can be done about it
This is the first time a company has approached me to implement a feature they need
In fact, Atopile are the first company I have ever worked with in this context, period.
At first, I thought this was pretty exciting and wanted to get it done ASAP for them.
However, as time marched on, the novelty of that wore off and reality set in... and that reality is "Oh f*ck. A bona fide company has asked me to essentially 'work for them' for free." Thus, putting me into the same bucket as most other FOSS developers out there.
Since that realisation, I have felt an unnecessary amount of pressure to get this done... even more than what I normally get when someone asks me to implement something. To be clear here, I can easily handle feature requests and what-not with no problems at all. Also, the company themselves have not done anything to make me feel this way.
It is simply me getting in my own head and over-thinking into Oblivion about it.
With that being said, it has still burned me out all the same.
Because of that, I have been stuck on how to actually go about this, and I had overwhelmed myself with "option paralysis" when I learned that on the handset side of things the internal and external transmitter modules handle things in completely different ways as far as their physical layers are concerned.
So, I figured it would be a good idea at the time to implement both in this Pull Request... only to burn myself out on option paralysis even harder.
So now, I need to remember to....
Focus on one feature at a time
In other words: Don't sacrifice myself in favour of my own project!
Instead of me being ambitious at the expense of my own quality-of-life, I have decided to drop implementing the external module bay version of the Serial Transmitter Interface for the time being.
I had a long time to think this one through, and the more I thought about it, the more I felt tackling both versions at once in one Pull Request was too overwhelming for me.
Atopile have only requested I implement communication to-and-from an internal transmitter module, and me doing both the internal transmitter module and external transmitter module bay communications would be me going above-and-beyond.... and what has that done to me as a developer? It burned me out to the point of getting dangerously close to shutting this project down.... which is something that I had a history of doing with other projects in my past. CRSF for Arduino is the only project of mine that has seen any success at all (for real: 100+ stars and 4,000 users is nothing to sneeze at), and that is what's currently keeping me from hitting that "delete repository" button. That success is all from you guys, and I am very grateful for that.
Tackling the much wider issues - Developer burnout, social engineering, and supply chain attacks
Currently, there is a lot on my plate as far as the upcoming Version 1.1.0 is concerned... probably a lot more than what I am used to. Most of which is all security-related stuff in light of the XZ Utils Backdoor incident.
I know, I know. I keep banging on about XZ Utils, and I probably should shut up about it. However, it's not just the back door itself. It's how it happened. It was a supply chain attack. A burned out sole maintainer was about to chuck in the towel on their project, and some clever cybercriminal named Jia Tan came along and socially engineered the maintainer into making them (Jia Tan) the primary maintainer before they (the original maintainer) left the project.
Over time, Jia Tan got to work on writing (and implementing) dodgy code... and a few years later... hey presto, we have a back door on our hands what's slated to be released into the wild that could have spelled devastating results to an ecosystem what prides itself on its security.
I keep bringing up XZ Utils, 'cause I be like "Who's to say the same thing won't happen to me?" 'Cause I am in the exact same position - A burned out and overwhelmed solo maintainer of (an increasingly) widely used project.
Okay, sure, I write firmware, and CRSF for Arduino is a firmware library that targets microcontrollers. How could malware possibly be deployed to that? Quite easily. In fact, it's easier than you may think. All a threat actor would need to do is convince me that I can trust them (good luck with that, 'cause I got severe trust issues to begin with, and because I'm neurodiverse, social engineering doesn't work on me anyway), they gain access to my project, do their thing, and the next thing you know... malware has been covertly deployed under the guise of my legitimate project... and I could be powerless to do anything about it, because either I have been removed from the project (because the cybercriminal was granted admin priveleges) or I decided "enough is enough" with my project and door-slammed and completely washed my hands of it. That is a situation I don't want to happen to my project, and I am taking all steps I deem necessary to negate the chances of that happening, at all.
This begs the next question: Who would want to inject malware into my project in particular? Well, ask yourself this: Who would want to come up to you while you're on your daily commute to/from work, and mug you for your money and your ID, and impersonate you while they get up to the most heinous of crimes? If you answered "that will never happen to me", then that's all the more reason why I am doing this. Because "it will never happen to me" is the epitome of complacency. It is that complacency that I view as being equal parts as dangerous as that identity thief in my analogy. I feel as a responsible maintainer, I have an obligation to protect my project from supply chain attacks and any other potential vector a cybercriminal could use to hijack CRSF for Arduino.
Coming full circle - Reducing burnout
I have decided to return to my "old schedule" where I work only between two and four hours per working day, and that is only in the mornings, during the week and on days where I'm not in physical pain (I also have rheumatoid arthritis, which can severely impact my ability to do literally anything, let alone code).
At this point, I MUST prioritise taking care of myself before I can take care of my project(s).
Because when I am constantly burned out, how can anyone expect me to write any code at all, let alone anything that's of good quality?
Up until a few weeks ago, my philosophy with CRSF for Arduino has been "Quality over quantity" and "less is more".
Why did I change this? Because I let my own intrusive thoughts win out, and I fell back into old habits what led me to the current state I am in. So, yes, burning myself out is my own fault, and this is what I am doing to rectify that.
What this means to you
This means that it will take longer for things to be implemented, yes. So, please be patient.
I would rather provide you all with a code-base that is of good quality that does what it says on the tin, as opposed to a code-base that is focused on sacrificing quality in favour of quantity.
...and after seeing several great projects become abandonware, I prefer to not abandon CRSF for Arduino. Especially when I am well aware of how popular it is becoming. You guys are what's holding me accountable here, and I love it. =^/.~=