feat(devboard): Add support for Teensy 3.x and 4.x

[ZZ-Cat]

Overview

This Pull Request adds support for Teensy development boards.

Tasks

The following lists the boards that are being added to CRSF for Arduino's Compatibility Table:

• Teensy 3.0
• Teensy 3.1/3.2
• Teensy 3.5
• Teensy 3.6
• Teensy 4.0
• Teensy 4.1

So far, only Serial1 is used, because this is in early stages of development and board support takes priority.
Options to use other UART ports may be added in future, if requested.

Additional notes

Regarding Teensy 3.x:

Not recommended for new designs or projects.
PJRC recommends use of Teensy 4.0 / 4.1 for new projects. We do not believe supply of chips for Teensy 3.x is likely to ever fully recover. These chips are made with 90 nm silicon process. Most of the world's semiconductor fabs are focusing on 45 nm or smaller, leaving limited supply for older chips. We anticipate the cost of these chips is likely to increase as the supply continues to dwindle.

With this being said, I have decided to add support for the entire Teensy 3.x and 4.x range.
Initially I was only going to support Teensy 4.0 and later and not bother with Teensy 3.x due to it being discontinued. However, I have since changed my mind on this. I am adding full support for all Teensy 3.x development boards with caveats:
If you compile CRSF for Arduino for one of the Teensy 3.x boards, you will see a compilation warning stating that these boards have been discontinued and that Teensy 4.0 (and later) is recommended for new projects.

If and when PJRC fully discontinues their entire Teensy 3.x range (IE No longer being available for purchase from their website), I will deprecate (and eventually remove) support for Teensy 3.x, later on down the track.

[ZZ-Cat]

Right-oh, @Kristabel28.
Can you go ahead and check out the ZZ-Cat/issue36 branch, flash that onto your Teensy 3.5, and let me know how it goes?

[Kristabel28]

At first glance, it works!! Tried both the channels and telemetry examples. Thank you so much ^^

Is there anything specific you would like me to test?

By the way, I am also up for testing all the other Teensy 3.x and 4.x as and when you need help :)

[ZZ-Cat]

At first glance, it works!! Tried both the channels and telemetry examples. Thank you so much ^^

Is there anything specific you would like me to test?

By the way, I am also up for testing all the other Teensy 3.x and 4.x as and when you need help :)

Excellent. I will get to that over the coming days. Fingers crossed all goes well.

[ZZ-Cat]

@Kristabel28, I just finished adding the entire Teensy 3.x and Teensy 4.x range to CRSF for Arduino's Compatibility Table.
I have compile-tested them on my end, and everything compiles a-okay.

Can you flash this PR on your dev boards and let me know how it goes? TIA.

[Kristabel28]

Hi @ZZ-Cat , real quick update.

I can't seem to find a Teensy 3.6 right now (will take some digging), but I have acquired 3.2, 3.5, 4.0, 4.1. Preliminary testing of T3.2 and T4.0 suggests issues—it won't work out of the box, but it might be user error. Compiles and uploads fine, but when I monitor the serial output, I'm not getting anything.

My first test with 4.0 just had no output, and after I inserted some print lines, it seems that the serial port opens successfully, but it never gets to printing "CRSF for Arduino initialization failed!". It just repeatedly Serial.prints the line before if (!crsf.begin()), which is weird because the setup() should only run once. I suspect that this means it is rebooting, and thus possibly a power issue(currently powering off USB only), but I will have to do further testing. Note that T4.0 is NOT 5V tolerant, which meant extra hardware to convert the logic levels, which means more points of potential errors.

First test with 3.2 did not work out of the box, surprisingly, as it is basically a T3.5 with smaller footprint—most users treat these boards as identical. Compiled and uploaded fine, first test printed "CRSF for Arduino initialization failed!", and all following tests did not output anything.

I've been sick for the past week (out of office = no access to hardware), so I haven't quite tested in detail, sorry!

Will update you again :)

[ZZ-Cat]

I've been sick for the past week (out of office = no access to hardware), so I haven't quite tested in detail, sorry!

Yikes! Being sick is not fun. Take care of yourself first, yea?

My first test with 4.0 just had no output, and after I inserted some print lines, it seems that the serial port opens successfully, but it never gets to printing "CRSF for Arduino initialization failed!". It just repeatedly Serial.prints the line before if (!crsf.begin()), which is weird because the setup() should only run once. I suspect that this means it is rebooting, and thus possibly a power issue(currently powering off USB only), but I will have to do further testing. Note that T4.0 is NOT 5V tolerant, which meant extra hardware to convert the logic levels, which means more points of potential errors.

That's weird. 🤔
You should be able to power both your development board and a connected Crossfire or ExpressLRS receiver over USB with no issues whatsoever.
If it's a power issue, you may need to consider connecting an external 5V source to the 5V lines of both your development board & your receiver. There may be an under-spec polyfuse in your development board (on the USB's 5V line) that could be rated to around 100~150 mA, which isn't really enough to power a receiver as well as the board itself. IIRC, the Metro M4 has a 500 mA polyfuse on the USB's 5V line, and that's probably why I can connect a receiver directly to the 5V output.

If the board's pins aren't 5V tolerant, you don't need a logic level shifter. IIRC, all Crossfire and ExpressLRS receivers use 3.3 V logic levels on their UART Tx & Rx lines. If anything, those are the pins that aren't 5V tolerant (and, by extension need to be guarded with a level shifter if your development board uses 5V logic level).
Literally how I found this out was when I connected both my Crossfire Nano Diversity & RadioMaster RP3 Diversity receivers to the Serial1 port of my Metro M4, flashed both example firmwares and everything worked well. My Metro M4 Express runs on 3.3 V & its logic levels are 3.3 V.

Compiled and uploaded fine, first test printed "CRSF for Arduino initialization failed!", and all following tests did not output anything.

I have given you some serial print messages in CRSF for Arduino's begin() function, which will provide the both of us with some insight into what's going on.

👇 This is what I have on my end, with my Metro M4 Express. From here on out, this is our "known good state".

By rights, your Teensy boards should return something similar to that screenshot. Only, your development board's name would be in place of Adafruit Metro M4 Express in the Compatibility Table message.
If any error message show up instead, that will help us pinpoint where the problem is.
If you can, flash your Teensy 4.0 with the RC Channels example with 5564dd1, screencap your Serial Monitor after everything has initialised (Including any error messages) and post it here.

First test with 3.2 did not work out of the box, surprisingly, as it is basically a T3.5 with smaller footprint—most users treat these boards as identical. Compiled and uploaded fine, first test printed "CRSF for Arduino initialization failed!", and all following tests did not output anything.

Again, that's strange.
There isn't a lot of reasons for CRSFforArduino::begin() to fail outside the board still somehow being seen by the Compatibility Table as incompatible.

Other than that, the CRSF Protocol is dynamically allocated, along with its related telemetry interface.
Those are the only other two reasons why CRSFforArduino::begin() would fail... is if one of those two fail to allocate memory to their respective object pointers. This is extremely unlikely to happen. Though, it's worth mentioning here so that you're aware of it.

This is also why I have provided Serial Print messages in my latest commits here, because I really want to know what's happening "under the hood" here. 'Cause I'm not gonna lie: I'm scratching my head about this just as much as you. I have been coding (with the Arduino framework) since 2013, and this is the first time I am encountering this particular issue.

So, let's figure this one out together, eh?

[Kristabel28]

Hi @ZZ-Cat , sorry for the delay

I've never seen a Teensy 3.0 or 3.1 in my life, so I won't be able to test those for you.

T3.2 claims to be incompatible.

T3.5 works great!

I've not managed to find a T3.6 lying around. I'll update you if I ever do, but it might not be likely as they are no longer in production.

T4.0 and T4.1 work great! You were right about it working with 3v3. Very pleasant surprise, I can skip the logic level converter :>

[ZZ-Cat]

Hi @ZZ-Cat , sorry for the delay

I've never seen a Teensy 3.0 or 3.1 in my life, so I won't be able to test those for you.

T3.2 claims to be incompatible.

T3.5 works great!

I've not managed to find a T3.6 lying around. I'll update you if I ever do, but it might not be likely as they are no longer in production.

T4.0 and T4.1 work great! You were right about it working with 3v3. Very pleasant surprise, I can skip the logic level converter :>

It's all good. On any of my Pull Requests, I have a grace period of 14 days after the last comment. If I haven't heard anything from the other person in over two weeks, it's safe to say that they won't respond, and I need to keep my project moving forward. Depending on the completion state of the Pull Request, I may merge it at my discretion and then keep an eye on my Issues tab to track any bugs that it may bring (if any, at all).

The only reason why Teensy 3.2 is showing up as "Incompatible", is simply because it isn't populated in the compatibility table. IIRC, there's a bit of a crossover with Teensy 3.1 and 3.2. I assumed that Teensy 3.2 basically had the same preprocessor definitions as Teensy 3.1, so I didn't bother with populating it.
If Teensy 3.2 has its own preprocessor definition then it's easy enough for me to populate the Compatibility Table with it.
That's because I am having to do it "the old school way" and go by the preprocessor definitions for the microcontroller and the name of each board that uses it... and it is somewhat of a jankier (IE Failure-prone) implementation than by going with the preprocessor definitions of the USB VID and PID.

At this point, I am considering only maintaining compatibility with Teensy 4.x, granted Teensy 3.x is obsolete (IE Discontinued by the manufacturer). So, I am weighing up the likelihood of keeping Teensy 3.x around or to simply drop it and only maintain compatibility with Teensy 4.x and later.
Because in my mind, it doesn't make sense to support a platform (or an older version of a platform) that isn't supported by the manufacturer. However, if it is still widely in use by the community, there may still be some benefit to keeping it around.
Other than that, I don't see much point in supporting a platform (or an older version of the platform) that is seeing minimal use, if it is in use at all. What's your take on this?

[Kristabel28]

Hi again @ZZ-Cat ,

I'm glad I didn't miss the 14 day mark! Really sorry about the delay, after I got back to office I was catching up with other work too. Once again I'm sorry for disappearing!

I went to look at the library again, made a simple modification and 3.2 works now! The changes are as follows:

CompatibilityTable.cpp:

#elif defined(ARDUINO_TEENSY32) device.type.devboard = DEVBOARD_TEENSY_32; #pragma message "Teensy 3.x is not recommended for new projects. Please consider using Teensy 4.0 or later instead."

CompatibilityTable.h:

Personally I feel that since it is not a lot of effort to keep the Teensies in the compatibility table, we can leave them in for now? Of course, this would be different if it required extra effort and code to maintain Teensy compatibility. I think that Teensy is a very widely used platform, and while T3.x is probably no longer being manufactured, there are still a lot of them out there, so it would be best to keep them in the compatibility table until some other incompatibility problem actually comes up, and it would take extra effort to keep T3.x.

tl;dr: the only thing stopping us from using T3.x is the compatibility table, not actual incompabilities in the code, so we should keep the option open

[ZZ-Cat]

Right-oh.

Tomorrow, I'mma go ahead and put that in, then merge the PR.

Thank you so much for helping me out, here.
=^/,..,^=

Anything else crops up down the line, don't hesitate to sing out, yea?

[Kristabel28]

hey, just to let you know
(i'm very new to github)
i made a fork and modified the example code, for more channels and better serial plotter compatibility. not sure how to ensure they do get to you. if they're useful you can merge those changes in!

https://github.com/Kristabel28/CRSFforArduino/blob/ZZ-Cat/issue36/examples/channels/channels.ino
https://github.com/Kristabel28/CRSFforArduino/blob/ZZ-Cat/issue36/examples/gps_telemetry/gps_telemetry.ino

[ZZ-Cat]

hey, just to let you know (i'm very new to github) i made a fork and modified the example code, for more channels and better serial plotter compatibility. not sure how to ensure they do get to you. if they're useful you can merge those changes in!

https://github.com/Kristabel28/CRSFforArduino/blob/ZZ-Cat/issue36/examples/channels/channels.ino https://github.com/Kristabel28/CRSFforArduino/blob/ZZ-Cat/issue36/examples/gps_telemetry/gps_telemetry.ino

Excellent! =^/,..,^=

Have a read through this on how to submit the changes in your fork as a Pull Request back to CRSF for Arduino.

If you're still unable to do that right off the bat, I may need to add you as a collaborator first.
I know for a fact that GitHub tightened up a lot of security over recent years, and changed the way that PRs can be submitted. I am kinda in the same boat as you, as CRSF for Arduino is literally the first project of mine to gain enough notoriety where others are willing to contribute to my project (which is fantastic, by the way). So, this is a first for me, as well.

In order for a Pull Request to be merged into the Main-Trunk, all of the commits in said Pull Request need to be signed/verified. This is an extra layer that I have in place to ensure code legitimacy - IE The code is coming from trusted sources.
Plus, there's automated checks-and-balances on code formatting and compilation tests on supported platforms via both Arduino and PlatformIO. This is what that green tick means when it says "All checks have passed". Whenever you see it in any Pull Requests to CRSF for Arduino... it means that the code compiles on all compatible platforms, plus the code is properly formatted.

Personally, I don't use the Serial Plotter (which is why the channel data wasn't optimised for that in the first place). Also, I consciously limited the number of RC channels that are printed to the Serial Monitor to eight (instead of the full sixteen channel capability), because I use PuTTY for my "Serial Monitor". On my end, printing all sixteen channels doesn't fit well on my screen (even though my screen resolution is 1920x1080).

In the library itself, I brought out all sixteen RC channels, so that if anyone needs to use them, they are there.
Eventually, I want to bring the entirety of the CRSF Protocol to the Arduino ecosystem, rather than restricting it to exclusively using RC channels or exclusively using telemetry.

If you like, I do have a discussions tab here, if you would like to carry the conversation on over there, after I have merged this Pull Request.