Teensyduino 1.52 Released

Not open for further replies.


Staff member
Teensyduino 1.52 has been released.


1.52 brings support for Teensy 4.1, USB audio on Teensy 4.x, OctoWS2811 support for Teensy 4.x with LEDs on any number of pins, USB dual & triple serial, 4/6/8 channel I2S on Teensy 4.x, RGBW support in WS2812Serial, and many small improvements and bug fixes.

Changes since Teensyduino 1.52-beta6:

Workaround for USB memory bandwidth at very slow CPU speeds
Fix import bug in Audio Design Tool (Frank B)
OctoWS2811 fix memory use with fewer than 8 pins
Clean up compiler warnings in USBHost_t36 ADK driver

The full list of changes since Teensyduino 1.51:

Support for Teensy 4.1 USB Audio support for Teensy 4.0
OctoWS2811 ported to Teensy 4.0
WS2812Serial support for RGBW SK6812 LEDs
FreqMeasureMulti ported to Teensy 4.0 (KurtE)
Dual & Triple USB Serial (Geert Uytterhoeven)
Audio support for 4,6,8 channel I2S on Teensy 4.0
Audio support for SPDIF input on Teensy 4.0 (FrankB)
Audio DAC support for Teensy LC (Ben Kurtz)
Fix Serial.print() conflict with USB Touchscreen
Fix contact count on USB Touchscreen (purple-ben)
Defined FLASHMEM on Teensy 3.x, for compatibility with Teensy 4 code (FrankB)
Fix cache handling in I2S audio input on Teensy 4.0 (Frank B)
Fix numerous iMXRT register field defines
MTP USB descriptors on Teensy 4.0 - actual MTP support still experimental
Libraries updated: FlexCAN_t4, ST7735_t3, RA8875
Fix USB RawHID on Teensy 4.0 (KurtE)
Fix USB audio+midi+serial descriptor on Teensy 4.0 (widdly)
Add ADK to USBHost_t36 (Matt Bergman)
Fix USB Host MIDI transmit race condition (essej)
Optimize USB interrupt on Teensy 4.0 (Frank B)
Arduino compatibility of digitalWrite control pullups (FrankB)
Add missing MPU traps on Teensy 4.0 (FrankB)
Fix SGTL5000 clock ratio setting (FrankB)
Fix I2S slave on Teensy 4.0 (widdly)
Add DMAMEM & fix warnings in I2S on Teensy 4.0 (FrankB)
Improve SPI use by SD on Teensy LC (rutmarti)
Support alternate SPI pins on Teensy 4.1 (KurtE)
Support alternate Teensy 4.1 CS pins on ILI9341_t3 (KurtE)
Fix Teensy Loader on MacOS 10.13 with Catalina version
Fix teensy_serialmon 100% CPU on Linux if Arduino process killed
Workaround for rare Windows Defender flase positive when installing Java classes
Allow SD.begin() to be called more than once
Support hardware serial CTS pins on Teensy 4.1 (KurtE)
Fix double float promotion (Frank B)
Fix I2S input use of cache (Frank B)
Fix installer crash on Jetson Nano
Update libs: RA8875, ILI9844_t3, QuadEncoder, ST7735_t3
Fix RTC auto-set on Teensy 4.x with daylight savings time
Fix RTC set on Teensy 4.0 (Silverlock)
Audio ADC input on Teensy 4.0 - experimental
Hardware serial pin fixes for Teensy 4.1 (KurtE)
Add dummy Keyboard.h on Teensy 4, for Arduino compatibility
Use standard (not low power) ADC mode
Align DMA buffers to 32 bytes (Frank B)
Fix ADC_ETC defines
Use recommended analog bias current on Teensy 4.x (Frank B)
Update Snooze library
Fix Audio ADC input on Teensy 3.x
Initialize PSRAM chips at startup on Teensy 4.1
Increase PSRAM clock to 88 MHz & fix error in writing clock setting
Use strong drive & hysteresis for FlexSPI2 pins
Minor improvement in OctoWS2811 for Teensy 4.x
Workaround for USB memory bandwidth at very slow CPU speeds
Clean up compiler warnings in USBHost_t36 ADK driver
Fix import bug in Audio Design Tool (Frank B)
OctoWS2811 support for any group of pins on Teensy 4.x
OctoWS2811 fix memory use with fewer than 8 pins
Downloaded and installed 1.52 over existing betas with 1.8.12 IDE. Install - no problems with Win10x64 pc.

Ran a couple of quick tests: PSRAMmemoryTest and one of my 3dModels on the RA8876, and ILI9488 graphics test sketches no problems. Testing done on T4.1 with 2 PSRAM chips installed.
Actual Debian with actual Arduino: usb audio out and analog in / i2c in both on T3.6 and T4 work well. I now get much cleaner signals! Thanks for the enhancements.
Downloaded and installed 1.52 over existing betas with 1.8.12 IDE. Install - no problems with Win10x64 pc.

Ran a couple of quick tests: PSRAMmemoryTest ... Testing done on T4.1 with 2 PSRAM chips installed.

Same here - PSRAM test on 1 and 2 chip T_4.1's, TimeTeeny3 sample works on T_4.1, Logger to SD (sdfat-beta) using 14+MB of PSRAM for buffer space working.
@Paul: this is the effect I mentioned:
2020-05-17 21_15_21-Start.png
You see different numbers: 10002/0/0/B/3 vs 10002/0/0/B/4
The serial monitor does not open now - but if I select the usual COM11 again (this is the number for this teensy) it will work normally.

No problems on Mac Catalina install.

Also installed on Raspberry Pi4 with Debian Buster 4.19. Had issue with libusb-0.1.so.4 similar to but not exactly like https://forum.pjrc.com/threads/4096...0-1-so-4-error?p=127854&viewfull=1#post127854

Solved with "sudo apt-get install libusb-dev". Then realized forgot to do apt-get update, apt-get upgrade before Arduino-Teensyduino install and after I did that it had a different issue seeing the T4 until Pi was re-booted then all worked well again.

Just for info 1st compile of 'Examples/Audio/WaveFilePlayer' took 45 seconds. Subsequent compiles about 4 seconds.
Hi, there's something I don't understand, that might be a copy/paste bug:

in usb_raw_hid.c, line 140 :
arm_dcache_flush_delete(txdata, SEREMU_TX_SIZE);

I would rather have expected :
arm_dcache_flush_delete(txdata, RAWHID_TX_SIZE);

Since SEREMU_TX_SIZE and RAWHID_TX_SIZE are both 64 in usb_desc.h this won't change the final result, but I thought it should be corrected.
I get now warnings on not to include "Time.h" but "TimeLib.h"
This is 'interfering' with plain system routines.

IMHO, TimeLib should be redesigned to NOT use Time.h
IMHO, capitalizing the T is NOT, repeat NOT the proper way to avoid compilation conflicts, (It only indicates a Linux centric mind)
Indeed this message is recurrent and confusing:
T:\arduino-1.8.12\hardware\teensy\avr\libraries\Time/time.h:1:2: warning: #warning "Please include TimeLib.h, not Time.h.  Future versions will remove Time.h" [-Wcpp]

 #warning "Please include TimeLib.h, not Time.h.  Future versions will remove Time.h"

When the header has this code:
//#include <time.h>
#include <TimeLib.h>

... this is in the new dataLogger library from @MBorgerson

it seems like it chains in from somewhere else a few layers up:
"T:\\arduino-1.8.12\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=152 -DARDUINO=10812 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\TEMP\\arduino_build_989179/pch" "-IT:\\arduino-1.8.12\\hardware\\teensy\\avr\\cores\\teensy4" "-IT:\\tCode\\libraries\\DataLogger" "-IT:\\tCode\\libraries\\SdFat\\src" "-IT:\\arduino-1.8.12\\hardware\\teensy\\avr\\libraries\\SPI" "-IT:\\arduino-1.8.12\\hardware\\teensy\\avr\\libraries\\Time" "T:\\TEMP\\arduino_build_989179\\sketch\\Fast_LoggerT4_1.ino.cpp" -o "T:\\TEMP\\arduino_build_989179\\sketch\\Fast_LoggerT4_1.ino.cpp.o"
In file included from t:\arduino-1.8.12\hardware\tools\arm\arm-none-eabi\include\sys\stat.h:9:0,

                 from t:\arduino-1.8.12\hardware\tools\arm\arm-none-eabi\include\sys\_default_fcntl.h:188,

                 from t:\arduino-1.8.12\hardware\tools\arm\arm-none-eabi\include\sys\fcntl.h:4,

                 from t:\arduino-1.8.12\hardware\tools\arm\arm-none-eabi\include\fcntl.h:1,

                 from t:\tcode\libraries\sdfat\src\common\fsapiconstants.h:30,

                 from T:\tCode\libraries\SdFat\src/ExFatLib/ExFatFile.h:36,

                 from T:\tCode\libraries\SdFat\src/ExFatLib/ExFatVolume.h:28,

                 from T:\tCode\libraries\SdFat\src/ExFatLib/ExFatLib.h:27,

                 from T:\tCode\libraries\SdFat\src/SdFat.h:33,

                 from T:\tCode\libraries\DataLogger/DataLogger.h:12,

                 from T:\tCode\sd\Fast_LoggerT4_1\Fast_LoggerT4_1.ino:1:
Teensyduino 1.52 (and 1.51 before it) is crashing often and consistently.

All I have to do is upload cmd-U and open serial monitor cmd-shift-m about 5 or 6 times and it will crash. The program I am uploading is 3000+ lines of code, and once the serial monitor is open it prints about 20 short lines in an instant and then terminates.

If I just upload, open serial monitor, let it execute, then close serial monitor, about 3 times in a row, on the 4th time I will see a spinning beach ball for a few seconds, and by the 5th or 6th time it's more like 10-15 seconds of spinning beach ball, and around the 7th time I crash with the attached OutOfMemory message.

The work-around is to simple quit and restart about every 5 uploads. I am currently working very actively on my program, so 5 uploads can be 5 minutes. Quite a PITA. Also, restart is *very* slow, always, but that is not the issue here.

I'm on a 2018 MacBook Pro, 13", running OS-X 10.15.5 Beta. The USB is going thru a short Apple usb-c to usb-3 conversion cable and then a short usb to usb-mini cable to the Teensy board.

I have tried this on a Teensy 3.2 and a new 4.0, same results. I've set the cpu speeds to min, same. I have deleted and re-downloaded the Teensyduino app several times, and used the 1.51 and now the latest 1.52 versions, same.

Any thoughts?

Screen Shot 2020-05-23 at 1.21.31 PM.jpg
@immortalSpirit - one thought ... given no idea of sketch behavior WRT to the following ...
How does setup() start before printing - is there a 'no print' before connect like below? On Windows this hasn't happened directly recently - maybe code like this helps prevent a series of prints that can get lost and confuse the system during the completion of USB_init:
 // don't Serial.print() yet - other prep okay
 while (!Serial && millis()<1000) ; // wait
 Serial.print("Hello World! @ ms = ");

Teensy enters setup() at 300 ms - but fastest ready on Windows measured when SerMon ready is like 345 ms and 400 ms is closer to typical and 500+ms happens not sure about mac? But unrestrained print in that time could be problematic depending on how it resolves.
Thanks for quick reply. Yes, actually I had something very similar. But just "while (!serial) {};" without the millis(). (And instead of "Hello World" I print out "Welcome, O Great and Mighty Master!"). So I changed it to exactly your suggested code, same results.

This led me to thinking... (always a dangerous thing to do)...

I loaded "Blink" from the examples! It's setup is: void setup() { pinMode(led, OUTPUT); } and it does no Serial i/o.

10 times in a row: cmd-U, wait for "Done uploading.", wait 1 second, repeat. No unusual action. Teensy blinking away.

Next, restart Teensyduino, load blink, cmd-u just once. Then:

5 times in a row: cmd-shift-M, wait 1 second, cmd-W


OMG! Something is terribly wrong. I'm just opening and closing the serial monitor. No other keystrokes and no serial i/o from the program! OMG!

Just for grins, I changed the Blink setup to include your example code, print out "hello world". No change to loop(). Same, crash on merely opening and closing the serial monitor 4 times!

For more fun, I got out an old Arduino Uno and loaded blink. cmd-u once, repeat { cmd-shift-m, wait 1 sec, cmd-w) at least 10 times, no problem, instant open and close.

There u go.

Serial monitor open and close with Teensy 3.2 or 4.0 connected seems to be leaking memory like crazy. Is it me or can u reproduce this???
Oh, I've seen the Serial Monitor printing its own sourcecode, on windows, so ...
These are the first signs of the coming improbability drive on Teensy 5. For sure.

Make sure you have your towel handy.
Probably losing my mind, but I'm on Manjaro with Arduino 1.8.12 and 1.52 TeensyDuino. I am recording snippets of audio and writing .raw SD files. When I play them back using playSdRaw, they sound fine, but when I import a raw file into audacity, it seems that the bitrate is 22050? The previous TeensyDuino I was testing with was 1.52beta4, where these raw files were indeed 44100.

Could there possibly be something in the release version of 1.52 that changed the bitrate I'm seeing in my recorded raw files?

Yes, most instructions on the T4 require only one cycle. Two of them can be executed simultaneously (->0.5)
The next teensy has a second CPU... ...so we subtract one cycle, and we have -0.5.
That means the program is finished before you run it! Or , if you wait some time longer.. before you write it!

No, but seriously, something's wrong with the serial monitor.
Thank you for responding Frank. Yes I'm sure. When I get home tonight I'm going to do a fresh install of Arduino and 1.52....i don't remember if I installed 1.52 release over the top of the beta, although it seems unlikely this could be a side effect, no? Dumbfounded right now but will test again tonight.
Problem solved!!

I have stumbled upon a "fix"!

When I click the "Tools" pulldown and select the Port, I have a choice at the top called "/dev/cu..... Serial (Teensy 3.2)"

And below, there is another choice, "/dev/cu... (Teensy)"

I always assumed they were identical, and I always picked the top one.

Screen Shot 2020-05-23 at 5.56.50 PM.jpg

When I started choosing the bottom one (today), the *bug* goes away!!!!!

I can open and close the serial window now any number of times and see no spinning beach ball and no crash. Who wudda thunk it?

Still seems like a bad bug, or at least a UI unclarity, but I'm relatively satisfied now with the "fix".

Thanks for listening,
Hello Frank et al.

So, yes, I'm an idiot. Here is what I didn't realize about importing into audacity. I thought that when the "import" dialog appears after choosing the file to import, it is populated with default values not related to the raw file being imported. My problem was that when importing a raw file from my program compiled with 1.52 release, my audacity import dialog defaults to "stereo".....I didn't catch that. So the file indeed is 44100, but I *still* don't know why importing my raw files created with 1.52 release default to "stereo" in the audacity import dialog, and raw files from my same code compiled with 1.52beta 3 & 4 result in audacity's import dialog correctly defaulting to mono. I didn't think there was any header or other info in the raw file that would indicate *anything* to audacity about the raw audio data. It all doesn't matter at this point, as the matter is solved for my purposes, but does it make sense that audacity's import dialog would default to mono for pre-1.52 release and stereo for raw files created with the release version of 1.52?

Sorry for my dumb posts and thank you for reading!
realize now its probably got nothing to do with beta vs release 1.52. When I've been importing, it seems random as to whether the default import dialog is at 'mono' or 'stereo'. Possibly audacity is looking at some bit for a clue as to whether its mono or stereo, but since the raw is pure audio data, that bit will randomly be a 1 or a 0...?
When you mention the 'Tools' menu - is this in the Aduino IDE or something else. I'm running Win 10 and don't see the same layout, so any help would be appreciated


Yes, most instructions on the T4 require only one cycle. Two of them can be executed simultaneously (->0.5)
The next teensy has a second CPU... ...so we subtract one cycle, and we have -0.5.
That means the program is finished before you run it! Or , if you wait some time longer.. before you write it!

No, but seriously, something's wrong with the serial monitor.

Frank B - I am chomping at the bit to play with Duff's snooze lib included in 1.52 for Teensy 4. Do you think that the
serial monitor is so broken that someone with only medium Teensy experience (2.5 year) and medium programming
skills (amateur for 44 year) could get anything done with 1.52 or should I wait ? running 1.48 now. thanks
Not open for further replies.