Teensy 4.1 in a 10+ years supported commercial project

PLLefebvre

New member
Hello, I am new to teensy and actually to arduino framework as well. Our previous projects are based on the microchip ecosystem mainly on PIC24 and dsPICs.

We would like to switch to the open source world for our next project. We have selected the Teensy 4.1 for our next project's proof of concept and so far it is going very well.

For this next project we need much more processing power to implement a set of complex equations for a measurement application. We dont have a large team and the schedule for this project is very tight. So instead of developping the microcontroller HW interface we are seriously considering to use the Teensy 4.1 right away within our PCB.

The product that we develop will operate in the field for several years in a controlled temperature room (10+). It will need to be reliable 24hour/day, 365 days/year. Any operation failure of the product could cost a lot for our customer. So far our demo board is reliable. The beta FW keeps the internal MCU temperature below 50 degre celsius. So the microcontroller will not be overwhelmed with our application. The system that we develop will need to pass a certification including EMC emission and immunity tests.

It will be a very low volume production of say 20 to 30 modules per year. We would like to select a platform that will stay around for several years (dev board and IDE). The big concern is availability of the module for the next 10 years as well as the firmware development platform (IDE). We are using platformIO so far with teensyduino and the onboard booltloader to develop the firmware. The product that we develop will need to be supported for FW updates (say one release per year) and we will need to build PCB with the Teensy for a minimum of 10 years from now (there is already a long term agreement for the service that we offer).

I would like to have your recommendations if this approach (using Teensy 4.1 in a commercial product) is viable on:

The legal side (There will also be some legal dpt questions to make sure it is ok to sell products with Teensy board embbeded. Is it?);
For the reliability 10+ years 24/7;
The platformIO with VSC IDE for firmware development and support;
The very long term support that we need to adress for this product (10+ years).

Should we go with the open source or should we continue with Microchip and switch to their M7 microcontrollers platform?

Thanks for reading this full BIG Question :eek:
 
I would think that the biggest hurdle will be CE approval. I believe that the T4.1 is a bit "noisy".
As for the rest, if the product is not going to change over that 10 year period, then you can simply "freeze" all the support tools at day1.
Do look at CE approval, first, that will be your biggest hurdle.
 
I actually had in mind a similar question, I would imagine a completely different industry but I have much your same questions specifically the legal side so interested in watching this thread.
 
First quick disclaimers. This message isn't legal advice. Generally speaking, legal advice comes from your own attorney, not messages on the internet. This message also isn't a guarantee or promise. Even in normal times, PJRC never makes promises of future availability. But as I'm sure everyone knows, we're currently in the middle of a global semiconductor shortage.

You certainly may embed Teensy inside your commercial product. There isn't any special license for the hardware (as is done with some loss-leader products like ST Discovery). You can treat each Teensy board like every other electronic component you buy.

Soon a lockable version of Teensy 4.0 & 4.1 will become available, meant for commercial products and secure applications. The lockable version will offer secure firmware update capability. Details here:

https://www.pjrc.com/teensy/td_code_security.html

However, 2 areas of concern should be license terms for any software libraries your program uses, and the Teensy trademark. The trademark is simple, just don't name your product "Teensy" or anything confusingly similar (just like you wouldn't name your product the same as other components with distinctive trademarked names). The library code PJRC publishes which becomes part of your program, and that of most 3rd party Arduino libraries, uses MIT or other "permissive" licenses which allow you to incorporate the code into your product without requiring source code disclosure. But some Arduino libraries have GPL license. Before Teensyduino 1.54, the Arduino SD library used GPL (1.54 replaced that GPL code with a thin wrapper for SdFat, which uses MIT license). Before selling your product, spending some time to review license terms for all the software libraries it includes would be a smart move.

Regarding hardware longevity, NXP has an app note with some analysis. The takeaway is reducing clock speed to 528 MHz can be expected to greatly extend the hardware's lifespan. To do this, in Arduino click Tools > CPU Speed. Then when you upload code, it will be compiled with settings to run at the speed you selected. The also recommend keeping the on-chip temperature below 70C. Use the built in temperature sensor to measure it while inside whatever enclosure your product has.

Two other common problems which can impact hardware lifespan are poor power supply startup behavior (especially overshoot) and signal quality problems on long wires which cause high frequency effects like ringing & overshoot / undershoot. These problems can do unnoticed for years, but do lead to premature hardware failure. If your product needs a very long service life, test these carefully. Series resistors on I/O pins and a power supply with good soft start behavior can make quite a difference.

I can tell you PJRC currently has a strong inventory position on Teensy 4.0 & 4.1. If sales continue as expected, the materials we currently have on hand today for Teensy 4.1 today should last until May 2022. NXP has also advised the IMXRT chips are not expected to be badly impacted by the semiconductor shortages in 2022, so we're not expecting the sort chip shortage of problems seen with some other models (currently Teensy 3.6). We're doing everything we can to keep every Teensy model continuously in stock. But PJRC doesn't have infinite space and money to buffer inventory. When the supply of chips completely dries up for longer than our inventory buffer, as happened recently with Teensy 3.6, there is nothing we can other than wait for NXP to supply more chips.

Again, at a matter of policy PJRC never makes promises of future availability (and if you look around at so many promises others made in recent years, especially about STM32 chips, you'll see those statements weren't worth the virtual paper they were printed upon once a semiconductor shortage hit). The best I can tell you is the only Teensy model PJRC currently plans to discontinue is Teensy 2.0, and some Teensy models are likelt to be impacted by chip shortages in 2022, but at this moment Teensy 4.0 & 4.1 appear likely to have the best availability in 2022.
 
With respect to the "noisy" issue, would Teensy Micromod be the same as Teensy 4.1? Any other relative pros or cons between these for use in a product? We are looking at Micromod over 4.1 for access to the pins dedicated to SD card on 4.1.
 
Thank you so much for all your well described answers. It is much appreciated!

Reducing the CPU CLK to 528 MHz will not be an issue (Actually we could probably lower it much more and it would probably be fine). The final product enclosure will be a metallic box to keep the noise inside. We have external ADCs on the PCB and the AFE is well isolated from the digital side to maximize the analog signal integrity.

Regarding the legal side, we can't open source our algorithms and application code so GNU GPL libraries are not appropriate for us. But MIT is all fine. I have a doubt thought for the LGPL. For the sake of an example, I know we need the SPI library and of course the arduino.h dependancies. In the SPI.h we find out that it is published under the GNU GPL license version 2 Or LGPL. The less restrictive license is LGPL. When we read the legal restrictions: "The LGPL will let you do anything under a closed source unless if you need to modify the library you need to share the modification", it leads me to believe that we are fine because we are not expecting to modify the libraries. If anything needs to be modified we will keep it a the application level.

I know you guys are not attorney but still I would apprecieate your advices on this. Are we OK if we need to keep the firmware in closed source if we use LGPL libraries such as arduino SPI?
 
I know you guys are not attorney but still I would apprecieate your advices on this. Are we OK if we need to keep the firmware in closed source if we use LGPL libraries such as arduino SPI?

Recommend talking with a lawyer specializing in this area. My understanding, from a lot of searching and reading, is that LGPL may be problematic since you are either statically linking libraries or just smashing everything together in one big build. LGPL was really designed for a dynamic linking environment that you would find on an operating system. Part of the point of LGPL is that your customers can link against different versions of the LGPL library.

One potential solution is to provide, or make available on request, the compiled object files and tools so that your customers could link and build against a different version of SPI and other LGPL libraries. Certainly possible with a Makefile, CMake, or other build system. I'm not sure how that would work using the Arduino IDE.
 
The Arduino developers have made official statements over the years about their interpretation of LGPL. Maybe with some searching you could find those? Whether that help, I don't know.

The only thing I can say for sure is this message is not legal advice.
 
Dear Paul,

we also consider to use the Teensy 4.1 as base for a new commercial development. NXP does not recomment the MIMXRT1062 for new designs as stated at their website, though they did not decide to discontinue it. Is it due to the current shortage or do you have some further information about the future productuion and availability? Would it be a good decission to use the µC despite of NXP's announcement?

Regrads
Peter
 
Dear Paul,

we also consider to use the Teensy 4.1 as base for a new commercial development. NXP does not recomment the MIMXRT1062 for new designs as stated at their website, though they did not decide to discontinue it. Is it due to the current shortage or do you have some further information about the future productuion and availability? Would it be a good decission to use the µC despite of NXP's announcement?

Regrads
Peter

Check the NXP site. When this came up before it referred to the "A" chip that has been replaced by the "B" version. The "B" versions have a noted "Active" support production lifetime.

The "B" version is compatible and the chip will be used in ongoing production.

These are not perhaps the right BUILD of the chip - but notice the A / B comparison:
Code:
MIMXRT1062DVJ6[B]A[/B]
(935379988557)	Not Recommended for New Designs

Code:
MIMXRT1062DVJ6[B]B[/B]
(935394382557)	Active
 
Back
Top