Teensy 3.2 End Of Life

Paul

Paul

Administrator
Staff member
With great sadness, we’re discontinuing Teensy 3.2.

t32eol.png

Teensy 4.0 and 4.1 will continue. We’re able to get the new 600 MHz chips in sufficient quantity.

But the sad reality is we simply can’t get enough of the old 72 MHz chips. The ongoing problems with old chip supply has become a huge distraction which is impeding progress on Teensy 4.x development.

When the small stock we have remaining for Teensy 3.2 runs out, it will be discontinued.
 
Ordered one since I had none in factory pack.

T_3.2 - Great and ahead of its time and still better than most ... good for reduced hassles ... slowing the even better T_4.x's advance.
 
Hate to see them go. I’ve done so many fun projects with these (and the 3.1’s) over the last 7 or 8 years. Thanks for all your hard work.
 
Hello, I just bought the Teensy 3.2 and installed the arduino 1.8.19, and later the Teensyduino. However, when trying to verify the code or compile it, I get this error message:

fork/exec C:\Program Files (x86)\Arduino\hardware\teensy/../tools/arm/bin/arm-none-eabi-g++.exe: %1 no es una aplicación Win32 válida.
Error compilando para la tarjeta Teensy 3.2 / 3.1.

In any case, I don't know what the problem is, I did everything step by step and it seems that it doesn't recognize the driver. Or I don't know if it's because my computer is 64-bit.
 
Maybe Windows Defender or some other anti-virus software mistakenly identified arm-none-eabi-g++.exe as a threat and deleted or quarantined it?

The other situation we sometimes see where files are missing happens with newer versions of Arduino IDE. If Teensy Loader is still running when you try to reinstall a different version (using Boards Manager inside Arduino IDE rather than running the dedicated installer than modifies a copy of Arduino IDE) then Windows can prevent deleting the old copy, and Boards Manager has trouble installing the new copy. But this problem is with Boards Manager inside Arduino IDE 2.x.x. With the special installer, if Windows prevents any file from being written, you'll see a clear error and the install won't be able to complete.

Since you're using Arduino IDE 1.8.19 and running the Teensyduino installer, the only likely explanation is anti-virus software deleting or blocking access to essential files.
 
Only 64 bit OS's been in use here for past years and never a problem.

Odd thing is this: "C:\Program Files (x86)\Arduino\"
> it was installed in Program Files which has more restrictive permissions in some ways.
> Also building under Windows here there is no instance of "fork/exec"? Not sure where that came from and have never seen it.

What is the installed version of TeensyDuino 1.58 is the current release and 1.59 has a beta 3 released. Seems there were some tool changes (?) that may change the

Here installs have always been an UNZIP to a known folder for the IDE 1.8.19. Then run the Arduino.exe from that folder after installing TeensyDuino 1.58 (or beta 3 of 1.59 if desired) and install to the location where the UNZIP folder is on the machine.
> if the ZIP is downloaded then do a manual scan of any installed anti-virus or malware software on that file.
> do the same for the downloaded TeensyDuinoInstall_###.exe
 
The version of windows may be relevant, e.g. if the compilers were built targetting Win8 onwards and somebody is still using Win7...
 
MichaelMC said:
Coughs. Windows 7 is still in active use by many, including yours truly.
Click to expand...

I didn't say anything that implied otherwise, but at this time even the default target for VS2017 (let alone newer builds) is Windows 10. Support for older versions of windows has to be explicitly chosen.
 
3.2 RIP
Things I'll miss the most:
1. RTC that can last for years on a teensy 1220 battery.
2. Low power.
3. 5V tolerant. Also me tolerant, never wrecked one. Wrecked many 4.1 and Arduino nano's
4. Robust leaded package, sorry but large pga packages suck in dynamic environments.
5. <66 page data sheet (no PHD req'd)
6. Great support. Whoops, I guess I'll still get that on the remaining and future processors!
 
Paul, I assume PJRC will continue to make the T3.x bootloader chip available. Do you have any idea how long it will continue to be available?
 
yeahtuna said:
Paul, I assume PJRC will continue to make the T3.x bootloader chip available. Do you have any idea how long it will continue to be available?
Click to expand...
Paul posted yes, it is the same bootloader "CHIP" used on T_4.x's - testing 'new' forum search didn't find real fast ...
 
Last edited:
My guess is because the CMOS process used wasn't able to support sufficient analog performance within a realistic die area.
 
Kindof sad. The one thing I had used the LC for was a project that needed DAC output. The 4.x doesn't have that built in.
 
Since you recommend to move to Teensy 4.0 and 4.1 as a replacement, it would really be very good to develop a version of these controllers that provide a better ADC accuracy. There are numerous users that have problems with missing bits etc., as discussions in other forums show. I personally suffer a lot, because I need the speed of the Teensy 4 together with the ability of a fast AD conversion on 8 channels. The Teensy 4.1 is an ideal controller for that, if there were not the bad performance of the ADCs. All suggestions to use multiple sampling or averaging are really just third class solutions and do not solve the problem from its roots.
 
Several times I've considered making an ADC shield. Might still do it. Recently have been playing with a relatively cheap (~$4) single channel 16 bit ADC chip and a 8:1 mux, both controlled with FlexIO. Input setting time is a difficult problem which leads to channel crosstalk, so not a simple thing, especially if running at speeds like 300-500 ksamples/sec. Of course there are chips with the mux built in, but the cost goes up quickly.

I hope you can understand with the built-in ADC, we simply have to live with whatever NXP provides. I really wish they would have done better. They probably do too, since they could sell more chips. But it's not so simple. Generally speaking, the improvements in silicon which allow digital circuits to run faster tend to make analog circuit less precise. With the much older & slower silicon used by Teensy 3.2, they were able to make the ADC better because the transistors were different, and specially certain analog circuits like a differential pair amplifier can be more precisely made than in chips meant for faster digital circuitry.
 
Thank you very much for your response. I completely understand what you write. In earlier communications on the topic I saw you writing that the stability of the reference voltage is a reason for the problems. Would it make sense to try improving the ADC performance at least gradually by giving the user an input for an external reference voltage, e.g. by sacrificing one of the GPIO connection pins?
 
hmprasser said:
Would it make sense to try improving the ADC performance at least gradually by giving the user an input for an external reference voltage, e.g. by sacrificing one of the GPIO connection pins?
Click to expand...

Unfortunately this is impossible. NXP simply did not provide this capability (in the RT1062 chip). No amount of wishful thinking or crafty software can cause a wire to exist where there is none inside the chip between a GPIO pin and the ADC reference.

Edit: this unfortunate design decision NXP made is well documented in the reference manual, on page 3401.

1701339795434.png
 
Last edited:
You must log in or register to reply here.
Back
Top