Teensyduino 1.57 Beta #1


Staff member
Here is a first beta test for Teensyduino 1.57.

Linux 32 bit:

Linux 64 bit:

Linux ARM:

Linux ARM64:

MacOS (Catalina to Monterey)

Old MacOS (Lion to Mojave)


Changes since Teensyduino 1.56:

USBHost_t36 USBDrive & USBFilesystem (wwatson,KurtE,mjs513)
SdFat update to 2.1.2, fixes file append bug
Wire library support slave mode on Teensy 4
Workaround MacOS serial monitor crash
Add breadcrumb feature to CrashReport
Improve AudioInputAnalog on Teensy 4
Add AudioOutputPWM on Teensy 4 (Mark Tillotson)
Tlc5940 support for Teensy 4
Update ADC library
EEPROM fix get() & put() with String (Luni64)
Ethernet allow use of other SPI ports (KurtE)
SdFat FsVolume::begin allows explicit partition location
SdFat support FAT12 & single FAT on Circuit Python (KurtE)
SdFat volume name functons (KurtE)
SD fix listfiles example on Teensy LC
SD update SdFat_Usage example with other SPI ports
SD add setMediaDetectPin() for card detection (KurtE)
Increased use of yield() in blocking functions
IPAddress != operator (Shawn Silverman)
Dynamic AudioConnection on Teensy 4 (Jonathan Oakley)
MTP handle host cancel & status control transfer
LittleFS getMediaName (mjs513)
LittleFS support 255 char filenames
OctoWS2811 getPixel() supports RGBW (Tobias Johansson)
QuadEncoder fix home and index trigger (mjs513)
QuadEncoder setCompareValue() (mjs513)
boards.txt & platform.txt updated for Arduino 2.0 beta
Add pluggable discovery & monitor for Arduino 2.0 beta
Downloaded. Win 11 install on IDE 1.8.19 went properly.
<edit>: not even a system warning about file from download on execution.

T_4.1 BUILTIN_SDCARD ListFiles built and ran properly ... all 120,726 lines worth!
@Paul: just thought to read the end lines of CONSOLE from install and build p#2:
Multiple libraries were found for "SD.h"
 Used: C:\Users\Tim\[B][U]AppData\Local\Arduino15\packages\teensy\hardware\avr\1.56.1[/U][/B]\libraries\SD
 Not used: C:\T_Drive\arduino-1.8.19\libraries\SD
Using library SD at version 2.0.0 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.56.1\libraries\SD 
Using library SdFat at version 2.1.0 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.56.1\libraries\SdFat 
Using library SPI at version 1.0 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.56.1\libraries\SPI 

Having installed the IDE 2.0 - even though running TDE 1.8.19 it is using the 1.56.1 tree tested 'back then'.

See this drive folder where unzipped 1.8.19 is installed - where TeensyDuino 1.57b1 has placed the new files:
 [B]Directory of C:\T_Drive\arduino-1.8.19\hardware\teensy\avr[/B]

01/29/2022  02:51 PM    <DIR>          .
12/20/2021  11:37 AM    <DIR>          ..
01/19/2022  06:08 PM               725 boards.local.txt
[B]05/06/2022  05:52 PM            83,394 boards.txt[/B]
01/03/2022  09:44 PM    <DIR>          cores
05/06/2022  05:52 PM            10,987 keywords.txt
12/20/2021  11:37 AM    <DIR>          libraries
[B]05/06/2022  05:52 PM             7,589 platform.txt[/B]

Seems IDE 1.8.19 give preference to Hardware in the %appdata% folder.
To confirm the IDE was closed to remove>>: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy
> could not delete the folder because Teensy.exe and Teensy_ports were still active!
<edit>, BTW: killing those tasks allowed full delete to complete

So now the 1.57b1 install is in use and indeed Listfile.ino builds and runs:
Multiple libraries were found for "SD.h"
 Used: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SD
 Not used: C:\T_Drive\arduino-1.8.19\libraries\SD
Using library SD at version 2.0.0 in folder: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SD 
Using library SdFat at version 2.1.2 in folder: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SdFat 
Using library SPI at version 1.0 in folder: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SPI
Last edited:
Morning All
See everyone was busy last night.

No problem on installing the the 1.57-beta1. As @defragster said this time no blue screens from Windows complaining about security.

Ran my updated MTP_Integrity Test sketch (has a few options to test multiple things with).

Breadcrumb: Saw this on startup do not know what the breadcrumbs mean so:
No Crash Data To Report
  Hopefully all is well, but certain types of crashes can't be reported:
	stuck in an infinite loop (technically, hardware still running properly)
	remaining in a low power sleep mode
	access to certain peripherals without their clock enabled (eg, FlexIO)
	change of CPU or bus clock speed without use of glitchless mux
  Breadcrumb #1 was 2705474578 (0xA1424412)
  Breadcrumb #2 was 4234545148 (0xFC6607FC)
  Breadcrumb #3 was 3439104072 (0xCCFC9048)
  Breadcrumb #4 was 170496750 (0xA2992EE)
  Breadcrumb #5 was 3875607432 (0xE7011388)

Tested Remove and replace on External SD Card using the Audio Shield:
### EXT1(0) removed dt:301000
... Not showing all the MTP debug stuff here....
### EXT1(0) inserted dt:1694000
then it showed up in the list on in windows explorer

As shown on the MSC thread it picks up the 2 external USB Drives:
##USB Drive: 0 connected

Partition Table
*** GPT Disk WIP ***
GPT guard:	1,0,0x0,0x2,0x0,0xEE,0xFE,0xBF,0xDB,1,4294967295
pt_#0:	2,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0,0
pt_#0:	3,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0,0
pt_#0:	4,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0,0
	 < unused area starting at: 0 length 242075647 >

GPT partition header revision: 10000
LBAs current:1 backup:242075647 first:34 last:242075614
Disk GUID:494E6C4B-0928-4119-6EED-8BD052C8A7BAStart LBA Array: 2 Count: 128 size:128
Part	 Type Guid, Unique Guid, First, last, attr, name
0	EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, 466E5E58-6453-84BB-6CDD-3B813E5167A3, 2048, 60520447, 0, 
>>> Microsoft Basic Data Partition
1	EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, 08F18C4C-41DD-48E2-2784-EFD893305C7C, 60520448, 242073599, 0, 
>>> Microsoft Basic Data Partition
3	00000000-0000-0000-0000-000000000000, 00000000-0000-0000-0000-000000000000, 0, 0, 0, 
Found new Volume:0

@@@@@@@@@@@@@@@ NEW Drives @@@@@@@@@@@

##USB Drive: 1 connected

Partition Table
FAT32:	1,0,0x20,0x21,0x0,0xC,0xFE,0xFF,0xFF,2048,47298560
Extend:	2,0,0xFE,0xFF,0xFF,0xF,0xFE,0xFF,0xFF,47300608,73844736
exFAT:	2:1,0,0x20,0x21,0x0,0x7,0xFE,0xFF,0xFF,47300672(64),73844672 (0)
pt_#0:	3,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0,0
pt_#0:	4,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0,0
Found new Volume:1
and the drive list:
Dump Storage list(7)
store:0 storage:10001 name:PgmIndx fs:20011068 pn:
store:1 storage:20001 name:EXT1 fs:20011630 pn:
store:2 storage:30001 name:RAM0 fs:20011428 pn:EXTMEM
store:3 storage:40001 name:RAM1 fs:200114f4 pn:EXTMEM
store:4 storage:50001 name:PROGM fs:20011208 pn:PROGRAM
store:5 storage:60001 name:USB0-GPTxFat fs:20011b0c pn:
store:6 storage:70001 name:USB1-FAT32-P fs:20011fa0 pn:
NOTE: Right now only the first partition of the multiple partition drive is picked up - known issue to be fixed in later beta.

As a quick test I wrote @KurtE's index file to one of the drives without an issue:
Write Large Index File
........................................................................................................................................................................ Total time to write 22015988 byte: 42368.27 seconds

	Big write KBytes per second 519.63 

and writing a Big file and small file (Tim's method)
Start Big write of 2048000 Bytes.........................
Big write /0_2MBfile.txt took  0.78 Sec for 2048000 Bytes : file3.size()=2048000
	Big write KBytes per second 2633.68 

Bytes Used: 367394816, Bytes Total:92951019520

Start Big write of 25124864 Bytes............................................................
Big write /0_bigfile.txt took  9.34 Sec for 25124864 Bytes : file3.size()=25122816
	Big write KBytes per second 2690.03 

Bytes Used: 392560640, Bytes Total:92951019520
Just as a followup I did update usb_desc to use MTP+SERIAL plus I had already uninstalled the package version in appdata for IDE2 at least for now - just makes it easier to update libraries and make changes. Besides not thrilled with IDE2 yet - there are still several outstanding PRs/Issues that need to be incorporated.

Guess maybe will test I2C slave since I never did that before.
Paul - I had wondered if this beta would also show up as a new version for the Arduino boards packages...

i.e. if you had put the pieces in place to use the newer stuff in Arduino_cli that might better support headless...

I did confirm this morning the IDE 2 does not see new board updates. So I am assuming not. looks like I will need to remove it and/or simply continue
using the build I have, where I grab all of the pieces out of <sketches>/libraries/... and symbolic link into cores and ...
Paul, I am also curious about having multiple Teensy installs using the Arduino15 stuff as mentioned versus how I have multiple Robotis OpenCM for example where one is in the Arduino15 and the others are in:

That is I tried building my Circuitpython test with new TD beta in 1.8.19 ran it from 1.8.19...
Using library USBHost_t36 at version 0.2 in folder: C:\Users\kurte\Documents\Arduino\libraries\USBHost_t36 
Using library SdFat at version 2.1.2 in folder: C:\Users\kurte\Documents\Arduino\libraries\SdFat 
Using library SPI at version 1.0 in folder: C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.56.1\libraries\SPI 
Using library MTP_Teensy at version 1.0.0 in folder: C:\Users\kurte\Documents\Arduino\libraries\MTP_Teensy 
Using library LittleFS at version 1.0.0 in folder: C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.56.1\libraries\LittleFS

Also in 1.8.19 I have a dev version of OpenCM (probably way out of date, but...), I also have the main boards package installed.

"C:\\Users\\kurte\\AppData\\Local\\Arduino15\\packages\\OpenCM904\\tools\\opencm_gcc\\5.4.0-2016q2/bin/arm-none-eabi-objcopy" -O binary "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_180226/read_write_ax.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_180226/read_write_ax.ino.bin"
Using library DynamixelSDK at version 0.0.1 in folder: C:\Users\kurte\Documents\Arduino\hardware\opencm904\OpenCM904\libraries\DynamixelSDK 
"C:\\Users\\kurte\\AppData\\Local\\Arduino15\\packages\\OpenCM904\\tools\\opencm_gcc\\5.4.0-2016q2/bin/arm-none-eabi-size" -A "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_180226/read_write_ax.ino.elf"
Sketch uses 46464 bytes (39%) of program storage space. Maximum is 116736 bytes.
Global variables use 8804 bytes of dynamic memory.

Maybe I will try a hack again back in (sketches)\Hardware to point to new teensy install...
Paul - I had wondered if this beta would also show up as a new version for the Arduino boards packages...

Nope. I automated building the package zip files (though it's currently broken on MacOS), but updating the package index is still a very manual process. I didn't do it for this beta.

I'm not planning to put much work into the new packages until Arduino fixes issue #769. Yeah, people wanting headless support from Arduino CLI could benefit even if the GUI isn't properly supported. And if #769 doesn't get fixed, I'll do that after 1.57 is released, and maybe also 1 or 2 times as we get closer to 1.57 release. Maybe.

But I do believe we need a patch in the Java code to force use of the libraries from the Teensyduino installer and ignore any other Teensy packages. People can still use the packages with an unpatched copy of Arduino 1.8.19, and of course with Arduino 2.0 beta. But when using a copy of Arduino which has been modified by Teensyduino, the installer's files should always be used no matter what packages exist elsewhere. Not quite sure how to do that, but in a future where the packages are more easily findable, we need this in the 1.57 release.
I2C Slave Mode - Seems to be working. Since I don't seem to do anything easy. I used the sketches from this post https://forum.pjrc.com/threads/6960...wo-Teensys-4-1?p=300929&viewfull=1#post300929 with the Master on a T4.1 and a T4 acting as a slave.

On slave I see:
sending (32 bytes)
sending (32 bytes)
sending (32 bytes)

and on the master I get:
read: done

read: done

read: done
Quick update: I un-installed the teensy IDE package.
So now building with new beta on 1.8.19

Note: I am still building with my fork of github of a few projects like SDFat, USBHost_t36... but are (or at least were ) in sync with the ones in beta.

Right now I am using the main branch of the MTP_Teensy project, which is pretty much in sync with what was my fast_start branch.

Note several of the examples that deal with MSC will not currently build as WIP to migrate the MSC support into USBHost and that is still a WIP.

(Note: I put back in the changes for MTP+Serial)

I have since then tried building and running a few sketches including:

(MTP_Teensy) Simple_mtp_ili9341_picture_view.ino which uses ILI9341_t3, does not use external libraries for some other bitmap formats.
(MTP_Teensy) CircutMicroPython.ino - experiments plugging in a CircuitPython or a MicroPython board to usbhost... Still playing with this one.

mtp_tft_picture_view (own project) - this is what the simple version was split off from. Actually we had this in the mtp_teensy, and then moved it out...
It does like the other one, but also optionally can use JPEGDec to decode jpeg files and PNGdec to handle PNG files, plus can do scalling, plus we have code in it to configure for several
different displays. ILI9341 (either ILI9341_t3 or ILI9341_t3n), ILI9488, ST7735 or ST7789, RA8875 or RA8876. Right now running on 7" RA8876

So far everything still appears to be working
Paul, I have a question about calling yield() from the various "available" functions. These functions don't fit the pattern of calling yield() while waiting for something in hardware to finish, and I think therefore they should not call yield(). For example, for a UART, you might create a task that has a loop like in the first snippet below, where it waits by calling yield(). The second snippet below shows what it would have to look like to get the same behavior. I've looked at a number of Arduino cores and other systems with support for RTOS, and none of them call yield() or otherwise wait within available().

if available() does NOT call yield()
  while (!available()) {

if available() calls yield()
  available();  // calls yield() internally, does not return until data is available
This line appears to be conflicting with the I2C onRecieve
AudioOutputI2S i2s2;
If i comment it out, the I2C works but if I put it in, it prevents the communication.

Teensy as Slave Code
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioPlaySdWav           playSdWav1;
AudioOutputI2S           i2s2; //                    <!-- Comment out this Line to work
AudioConnection          patchCord1(playSdWav1, 0, i2s2, 0); //    <!-- Comment out this Line to work
AudioControlSGTL5000     sgtl5000_1; 
// GUItool: end automatically generated code

int led = LED_BUILTIN;

void setup()
  pinMode(led, OUTPUT);


void loop()

void receiveEvent(int howMany)
  if (!Wire.available()) return;
  digitalWrite(led, HIGH);
  Serial.print("I2C: ");

  int rcIndex = 0;
  char rcArray[31];
  while (Wire.available() > 0)
      //char rc = Wire.read();
    rcArray[rcIndex] = (byte) Wire.read();

  digitalWrite(led, LOW);
Last edited:
Assorted library warnings on first build (only) of TD1.57b1

Installed TD1.57b1 over TD1.56 (without uninstalling). Building with Arduino 1.8.19 under the following conditions:

Arduino IDE Configuration (last built with Arduino 1.8.19 + Teensyduino 1.57b1):
     Tools/Board:           "Teensy 4.1"
     Tools/USB Type:        "Serial + MIDI"
     Tools/CPU Speed:       "600MHz"
     Tools/Optimize:        "Smallest Code"
     Tools/Keyboard Layout: "US English"
     Tools/Port:            "COMx Serial+MIDI (Teensy 4.1)"

First build of my Teensy-RA8875-MIDI-PolySynth reported the following (all library source file warnings):

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\output_pwm.cpp: In static member function 'static void AudioOutputPWM::isr()':
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\output_pwm.cpp:370:29: warning: invalid conversion from 'volatile audio_block_t* {aka volatile audio_block_struct*}' to 'audio_block_t* {aka audio_block_struct*}' [-fpermissive]
In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\output_pwm.h:31:0,
                 from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\output_pwm.cpp:28:
C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4/AudioStream.h:154:14: note:   initializing argument 1 of 'static void AudioStream::release(audio_block_t*)'
  static void release(audio_block_t * block);
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\output_pwm.cpp: In member function 'virtual void AudioOutputPWM::update()':
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio\output_pwm.cpp:402:12: warning: invalid conversion from 'volatile audio_block_t* {aka volatile audio_block_struct*}' to 'audio_block_t* {aka audio_block_struct*}' [-fpermissive]
  old_block = block ;
C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\AudioStream.cpp: In member function 'int AudioConnection::connect(AudioStream&, unsigned char, AudioStream&, unsigned char)':
C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\AudioStream.cpp:339:7: warning: unused variable 'cr' [-Wunused-variable]
   int cr;
Opening Teensy Loader...
Memory Usage on Teensy 4.1:
  FLASH: code:288404, data:51500, headers:8252   free for files:7778308
   RAM1: variables:268544, code:216792, padding:12584   free for local variables:26368
   RAM2: variables:51808  free for malloc/new:472480

Mark J Culross
Installed ok on Mac Catalina 10.15.7
Haven't managed to crash the serial monitor (although this usually happens when the alzheimer's kicks in and I do something stupid)

Can't wait to throw some 'BreadCrumbs', any documentation I missed?

This line appears to be conflicting with the I2C onRecieve
AudioOutputI2S i2s2;
If i comment it out, the I2C works but if I put it in, it prevents the communication.

Committed a fix.


I found I could also create the problem without the audio library, just using this:

  analogWriteFrequency(23, 12000000); // <-- also causes problem
  analogWrite(23, 128);

Turns out the having a nearby pin toggling at several MHz can couple to the I2C pins while the I2C peripheral is monitoring them to detect if the signals change. Turning on hysteresis solves it.