Teensyduino 1.55 Released

Status
Not open for further replies.

Paul

Administrator
Staff member
Teensyduino 1.55 has been released

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


Quick summary: 1.54 brings for code security on Teensy 4 and support for Arduino 1.8.16.


Changes since 1.55-beta3:

Consistent pin numbers in LittleFS & SD examples
Reorder MTP & HID interfaces (Kurt E)
Add LittleFS keywords (mjs513)


Complete list of changes since 1.54:

Support for Lockable Teensy 4.0 (beta) kinetis.h comments added for required clock gate config on each peripheral
Fix higher temperature measure on Teensy 4.x (mjs513)
Fix USB serial transmit autoflush race condition on Teensy 4.x (thanks Frank B)
Add IMXRT fuse memory functions

NXPMotionSense add Quaternion access (Ryan Pearl)
USBHost_t36 bluetooth PS4 improvements (KurtE)
USBHost_t36 serial DTR & RTS support (KurtE)
USBHost_t36 serialemu fixes (Frank B)
Update NativeEthernet & FNET
Support for Arduino 1.8.16
Remove Arduino 1.8.14
Fix teensy_size crash with very large programs (Frank B)
Lockable Teensy support on MacOS
Fix Windows 7 communication with locked chips
File base class changed to File & FileImpl
Update SD & LittleFS for FileImpl class
Preliminary work for unusable locked chip to not stall Teensy Loader
Fix startup crash when compiled with gcc version 10 (Frank B)
Fix LittleFS_Program size (mjs513)
Improve LittleFS examples & readme (mjs513)
SdFat use MAINTAIN_FREE_CLUSTER_COUNT on 32 bit Teensy
Do not build .lst file - very slow for large code
Sketch > Export Compiled Binary now saves .ehex, if possible
Consistent startup sequence on Teensy 3 & 4
Add startup_default_middle_hook()
Fix Serial.begin() delay with serial emulation and Teensy 3
String compatibility with Arduino for C++ iterators
Fix DMAChannel triggerContinuously() on Teensy 4 (Kurt E)
Fix CCM_ANALOG_PLL_ENET define (Shawn Silverman)
Improve arm_dcache_delete() documentation
Rename LittleFS example folders
LittleFS_RAM always starts blank
Update ST7735_t3
Update TeensyThreads
Fix Teensy Loader GUI stalls with locked Teensy 4
Show .ehex filename in status bar when automatically using .ehex
Clearer messages about hex vs ehex in Verbose Info
Only show percentage flash used after connecting to real hardware
Avoid fusewrite fuse memory corruption if different key used
Improve error messages in fusewrite sketch
Consistent pin numbers in LittleFS & SD examples
Reorder MTP & HID interfaces (Kurt E)
Add LittleFS keywords (mjs513)
 
Great work Paul!

Just installed on Windows 10 machine and looks like it is working.

Also installed ON OLD mac (Early 2013)MacBook running Catalina 10.15.7... And so far so good...
 
Ditto to what @KurtE just said. Fantastic job especially considering all the moving pieces you had to deal with !!!!!

Ran a couple of things and all seem like they are working on a Windows10x64.
 
Installed TD 155 (over beta 3) on IDE 1.8.16 on Win 11 x64_Pro:: No problems.

Ran first sketch NO REPRO Problem on T_4.1 from : pjrc.com/threads/68199-Teensy-4-1-Lockup

Built from TSET - opened IDE to get SerMon for repro steps.

<EDIT>: For above thread - it just STOPPED in IDE SerMon at:
Code:
41.36°C	593242
40.70°C	593252
41.36°C	593262
41.36°C	593272

Closed IDE SerMon and turned on TyCommander Serial to that T_4.1 and it was running:
Code:
40.70°C	1247819
40.70°C	1247829
40.05°C	1247839
40.05°C	1247849
...
40.05°C	1316653
40.05°C	1316663
40.05°C	1316673
...

Turning off TyComm Serial and re-openeing T_SerMon in IDE ... it picked up running ...
 
Last edited:
Hi.
Install on W7 ok, but obtain one compilation error with teensythreads. All seem ok before with Arduino 1.8.15 and TeesnyDuino 1.54.
Bug Teensyduino 1.55.JPG
 
As @defragster mentioned that depending on the crash crashreport will give you a means to find where the error is but if you are loosing the Serial Port and the T4.1 doesn't restart then it won't help much.

I just ran the same thing on the Locked T4 and it froze the serial monitor as well.
Code:
49.21°C 664169
49.21°C 664179
48.55°C 664189
48.55°C 664199
49.21°C 664209
49.21°C 664219
49.21°C 664229
49.21°C 664239
49.21°C 664249
Opening and closing the Serial monitor, the data continued - as @defragster mentioned TyCommander Serial Monitor works nicely to avoid the issue but not sure whats causing the issue.

@Paul a similar issue was noted in other releases as well where dumping alot of data to the serial monitor would cause it to freeze and opening and closing the serial monitor cleared the problem. Not sure this was ever resolved. Unfortunately I can not find where I posted that issue - alot of beta releases

EDIT: Found it: https://forum.pjrc.com/threads/66357...l=1#post271493 and @defragster confirmed it in following posts
posted this on the other thread (https://forum.pjrc.com/threads/68199-Teensy-4-1-Lockup?p=288611&viewfull=1#post288611) but may be more appropriate here.
 
As proposed by ftrias,removing the offending line from TeensyThreads.cpp:

#include "utils/debug.h"

Slove TeensyThreads compilation issue

I wonder if this has anything to do with which version of Arduino and Teensydunino? Or simply that this line was added in hist last commit to this library on September 7th?
 
I wonder if this has anything to do with which version of Arduino and Teensydunino? Or simply that this line was added in hist last commit to this library on September 7th?

This comes from the last commit of this library and it's a mistake of the library owner.
 
Why are lst files removed?
Actually they are not removed, but simply not generated.

From previous beta cycle: I believe some people complained how long a build was taking in the final stages, especially very very large files.

So the step was commented out in platform.txt:
Code:
#
# objdump to create .lst file is VERY SLOW for huge files
# https://forum.pjrc.com/threads/68121?p=288306&viewfull=1#post288306
#
# recipe.hooks.postbuild.4.pattern="{compiler.path}stdout_redirect" "{build.path}/{build.project_name}.lst" "{compiler.path}{build.toolchain}{build.command.objdump}" -d -S -C "{build.path}/{build.project_name}.elf"
My guess is you can easily reactivate it by uncommenting the receipe.hooks... line
 
Yes, found that.
Not nice to disable that for all users. The opposite would be better: a comment thats says it can be disabled.
 
Yes, found that.
Not nice to disable that for all users. The opposite would be better: a comment thats says it can be disabled.

@Mcu32:

No matter which behavior is made the default, there will be a group of users who will be opposed. If the default is "disabled", then those that want/use the lst files will be offended (as you seem to be). If the default is "enabled", then those that don't want/use the lst files may very well be upset at the extended build time. We (as the Teensy community) must always remember that Paul is very good at controlling all aspects of the "useability" of his Teensy product line. It is easy to appreciate that many of the Teensy users may either not be capable of digging into the deep dark bowels of the Teensy build process (like myself), or may not want to do the same digging (speaking mostly for myself) !! From a "useability" standpoint (my assumption), the decision to disable the generation of the lst files is a very good one. And for those who would like to retain/restore the ability to generate lst files, it's as simple as uncommenting a single line (as KurtE points out). You even indicate that already found the solution . . .

The Teensy line of products have had for a long time, & continue to have, a stellar reputation, primarily as a result of a diligent effort on Paul's part to keep it that way. I trust Paul & his cadre of "core developers" to make decisions that are truly in the best interest of the community as a whole. Accept the fact that it is impossible to satisfy all of the people all of the time !!

My two cents worth, which I certainly acknowledge that you didn't ask for . . . therefore, being my personal opinion, it's worth exactly what you paid for it !!

Mark J Culross
KD5RXT
 
Yup, and now the default is no lst files. The release notes clearly give the reason for the change.

Mark J Culross
KD5RXT

Compare:
About 1 minute to first build a large 'Test Sketch' then over 1.5 minutes before Teensy Loader got a handle to the HEX for upload. There was No console UI or feedback during this wait - it was the .LST file creation for the Test sketch written with cascading calls across 4,000 functions that Paul recognized.
- Build time goes down some on rebuild
- Every rebuild the LST file took 95 seconds

Versus:
LST file is needed and not present
- Turn the LST file creation on
 
How large was the large test and how many % of programs is that large? Never had any issues. The compile is dead slow anyway compared to other systems, and the lst generation never took longer than half a second.
It not important.
Don't want to start such a discussion here.

I know now how to edit that on every new release.
Not very user friendly, but OK.
 
and the lst generation never took longer than half a second.

The word "never" only applies to the programs you have personally compiled.

Turns out for some very large programs, it is painfully slow. On the older (but generates the fastest code) version of the toolchain we're using, objdump also has bugs that result in a worthless .lst file for Cortex M7. It really only gives usable output for Teensy LC & 3.x.


Not very user friendly, but OK.

A difficult decision had to be made:

1: Painfully slow build time for people compiling very large programs
2: An extra step for people who want a .lst file
3: Delay Teensyduino 1.55 release and divert engineering time into optimized .lst creation

I chose option #2.

I'm hopeful a future toolchain update may bring improved objdump.
 
A difficult decision had to be made:

1: Painfully slow build time for people compiling very large programs
2: An extra step for people who want a .lst file
3: Delay Teensyduino 1.55 release and divert engineering time into optimized .lst creation

I chose option #2.

I'm hopeful a future toolchain update may bring improved objdump.

Hello Paul,

Personally don't have issue with this either way. I have never noticed that as the biggest bottleneck, but I don't often build giant programs. I also don't use the .lst files that often....

So maybe the only maybe real issue understanding that the change happened to what the default behavior of a build. Yes there is a quick note in changes, about half way through list:
Code:
Do not build .lst file - very slow for large code

But there is nothing that describes option #2

That is is it:
a) you need to edit Platform.txt and uncomment that line...
b) Is there some menu item that generates it? I don't know of any.
c) Or you can run the command line:
C:\arduino-1.8.16\hardware\tools\arm\arm-none-eabi\bin\objdump
So in my last build case something like:
Code:
C:\Users\kurte\AppData\Local\Temp\arduino_build_549061>C:\arduino-1.8.16\hardware\tools\arm\arm-none-eabi\bin\objdump  -d -S -C JoystickBT.ino.elf >  JoystickBT.ino.lst
edit:
d) Wish for things like this preferences had a way to set if you want it or don't want it...

I am guessing a)
 
Last edited:
As my personal real-life example, the latest version of my TeensyMIDIPolySynth (which now uses the RA8875 display with on-screen sliders & buttons, instead of the original hardware version using pots & buttons & LEDs), I use the following build settings (currently 28000+ lines of source):

Arduino IDE Configuration (last built with Arduino 1.8.16 + Teensyduino 1.55):
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)"


With the generation of lst files enabled, build time is 3:17. With the generation of lst files disabled, the buiild time is 1:08. With the required edit-build-test-repeat_endlessly cycle of development as I continually add capabilities (now that I don't have to add corresponding additional hardware), that extra 2:09 time expended for something that I will never use is painfully expensive & absolutely unnecessary !!

I am a huge fan of the default being disabled, while retaining the ability (using the included comments & references) for those who want/need to easily restore that capability.

Mark J Culross
KD5RXT
 
Last edited:
Sounds like a good wining in your case!

Forgot to mention in my previous post, there is an
a1) version which may be better for some:

That is create the file: platform.local.txt
with the contents like:
Code:
#
# objdump to create .lst file is VERY SLOW for huge files
# https://forum.pjrc.com/threads/68121?p=288306&viewfull=1#post288306
#
recipe.hooks.postbuild.4.pattern="{compiler.path}stdout_redirect" "{build.path}/{build.project_name}.lst" "{compiler.path}{build.toolchain}{build.command.objdump}" -d -S -C "{build.path}/{build.project_name}.elf"
And I don't believe Teensyduino installs will overwrite this file. So if you install new betas or the like it will continue to run this step...
of course if you go to a new Arduino release in a different directory then you have to make/copy/move this file...
Also may want from time to time to verify that recipe name/number still makes sense.
 
Mark, my favorite word (cite) is *censored* for guys answering on this level.
As I already said that I have, and take the time to edit that line each time, everything is OK for me. But not for you, it seems? Seems you prefer to discuss that more?
I'm sure you find some. But, sorry, not me.

Paul, yes I bet the majority is happy. Not me, but that's bad luck.
 
@Mcu32:

I'm sorry if you were offended by my last post. In each of my previous posts, when directly addressing my comments to you, I either chose "Reply With Quote" (to supply the context for my comment), or I opened with "@Mcu32" (like this one), or both to make it perfectly clear that I was addressing you directly. In the case of my most recent post, you were not specifically called out, nor were you specifically addressed, so it appears that you are the one choosing to continue the "discussion" endlessly. There is nothing to discuss here. I was merely providing a concrete example of the benefit of the change to me personally. Some are happy with the change, some are unhappy, and some (as you stated) are satisfied to have the ability to enable a function that you find useful.

My use of "(your favorite word)" was my reference to the general abuse of such words ("never" "always" & such, to which I added my own "ever"). I had initially included the additionally sarcastic comment "Never is a long time, & always almost never occurs", but removed it as overly inappropriate for my intent. My choice of emphasizing the "never" may have also been deemed inappropriate by some, so i have updated my previous post to remove it. I'm sorry that you took it personally.

My real world example of the difference between building with the lst files enable & building with list files disabled is just that: a real-world example for those who may reference this thread sometime down the road. Please just let it stand for what it was intended.

Mark J Culross
KD5RXT
 
Status
Not open for further replies.
Back
Top