It might be time to change Teensy's Arduino architecture from AVR to ARM

[shawn]

I was making a PR for the Arduino_ConnectionHandler project (https://github.com/arduino-libraries/Arduino_ConnectionHandler/pull/128), and the build complained (just a warning) that AVR platforms aren't supported. That finally pushed me to write this post because I've been thinking about this topic for a while.

Some questions, since Arduino's "architecture" model isn't quite there yet:
1. Should "arm" be used as the architecture?
2. Should a new "teensy" architecture be created?
3. Is "avr", even though there's still technically some "sort-of source compatibility", still a desirable thing to support?

 

[KurtE]

FWIW - I agree with you, that it would be beneficial to break away from the Arduino avr architecture designation, and then maybe split up
the Teensy Arduino install into 2 or maybe 3 different installs (AVR, Teensy 3.x, Teensy 4.x), should 3.x and 4.x be split? Not sure.

It would be nice, to be able to mark library properties to say it only runs on Teensy 4.x or 3.x...

Source compatibility with Avr boards like UNO? Good questions. Even Arduino is not doing a very good job of this.

For example, they do not appear to be overly concerned about making the UNO R4 compatible with the UNO R3... But at least in the past it has probably been a net positive for PJRC to have that compatibility.

If Paul were to agree to split it up (Or simply change to different architecture designation), my guess is that it will be lot of work,
and would take a while for things to be fixed. And it will probably cause some form of ripple effect. Things like:

a) If multiple board types, which libraries, go with which types. Do you also then take the opportunity to maybe embrace the library manager, and reduce the number of actual libraries that are installed?

b) What the actual split should be? Do you reorganize the source files on Github? and/or do you have release scripts that do this? Like how Arduino does MBED? That is their development setup is, that all of the MBED boards are one project, but their release scripts are such that many of the boards, like GIGA are shown individually in the board manager...

c) Fix up all of the things, that are installed by the board manager (or Teensyduino)... That is are the libraries marked with architecture.

d) update the documentation on PJRC, like how to install...

All of the above maybe can be fully contained by Paul, but where it could get tricky, are things like:
a) How many libraries are out there, that might do things like, check for Architecture == AVR and TeensyDuino and then
check for KinetisK/L or IMXRT ... How do they need to be updated? In the end would probably be cleaner, but... What do you do when there are
libraries that are no longer actively maintained?

b) What impact if any on other tools/setups? PlatformIO, Visual Micro? ...

The real question is, is this something that Paul believes that would be beneficial enough to PJRC to spend his time doing it?

 

[PaulStoffregen]

I'm not a fan of Arduino's architecture names. My general feeling is we need to make the best of a bad situation.

Even though all the Teensy 2 and Teensy 3 hardware is discontinued, we're still publishing software support. So today we're shipping a single package which could be considered to a several architectures. In CPU instruction sets, we have 8 bit AVR, ARM Cortex-M0+ (Teensy LC), ARM Cortex-M4, and ARM Cortex-M7. Peripheral-wise, we have at least AVR, Kinetis, and IMXRT. Or perhaps Kinetis-L could be considered different from Kinetis-K? I've never really understood what Arduino really meant by the architecture name, but my best guess is we have 3...

I absolutely do not want to divide Teensy's software support into 2 or 3 or more separate packages. Software maintenance is part of it, but I also really want to preserve the relatively simple user interface where all the supported hardware appears as a single list in the Arduino IDE user interface. Keeping the GUI-based user experience as simple as possible is my top priority.

Appearance and usability with Arduino CLI is a secondary concern. Likewise for Github repositories. If something looks ugly or awkward in CLI usage, like calling everything "avr" when most of the hardware is not actually AVR, improvements for CLI usage must not come at the cost of GUI-based user experience.

The concept of pure technical correctness is an even lower level of concern. Any change which make the internal names more technically correct, but which makes both GUI and CLI user experience more complicated, is definitely not worth doing!

I do believe we need to bring just a bit more of the AVR register emulating stuff from Teensy 3 to Teensy 4. The only case I've seen recently is some libraries which depend on AVR SREG to disable and re-enable interrupts. But if there are more libraries out there which aren't compiling for Teensy 3 or 4, and if they appear to have any substantial usage in these modern times, maybe we should look at what those need too. But I don't recall seeing any for the last few years. That sort of code was really common 12 years ago when Teensy 3.0 was released. Today, not so much.

Maybe there are other reasons to consider the architecture name? Right now I'm having a hard time imagining much benefit. But if there is something to be gained that I've missed, please do explain. Just know that GUI-based end user experience is by far my top concern, overriding pretty much everything else.