Teensyduino 1.53 Released

Status
Not open for further replies.

Paul

Administrator
Staff member
Teensyduino 1.53 has been released.

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

1.53 brings support for Arduino 1.8.13, which greatly improves stability on MacOS Catalina. NativeEthernet library was added for Teensy 4.1 ethernet. Support for C++ STL is improved. A digitalToggle(pin) function can now be used alongside digitalWrite(pin, state). Old libraries were removed. The installer now checks udev rules are up to date on Linux systems. Many minor issues were fixed.


Changes since Teensyduino 1.53-beta3:

Fix audio library on Teensy LC
Fix ST7735_t3 spitftbitmap example (KurtE)


The full list of changes since Teensyduino 1.52:

Support for Arduino 1.8.13
Reduce EventResponder and yield() overhead (KurtE)
Audio design tool checks I/O compatibility (thanks to Frank's JavaScript work)
Update audio design tool documentation
Speed up ILI9341_t3 and add setClock (Larry Bank)
USBHost_t36 add Keyboard attachRawPress & attachRawRelease (David "plugz")
Fix DmxSimple on Teensy 4.0 (Adam Demuri)
add pgmspace.h (not avr folder) compatability for Teensy 4.0
minor updates to SD and Wire examples
Improve C++ STL support
Fix compiler warnings in several library examples
Update libraries: FastLED, MIDI, RA8875, Adafruit_NeoPixel, FlexCAN, FlexCAN_T4, ILI9488_t3
Entropy library support for Teensy 4.x random number hardware
ILI9341_t3 proportional font rendering speedup (Larry Bank)
Audio: add rectifier effect and vocoder example by Bradley Sanders
Fix serialEventUSB1 & serialEventUSB2 on Teensy 4.x (KurtE)
Add MIDIUSB.h compatibility on Teensy 4.x
Check hardware serial FIFO in avalable and peek (KurtE)
Remove libraries: Adafruit_GFX, Adafruit_CC3000, Adafruit_RA8875, openGLCD, ST7565
Add SPI.end() on Teensy 4.x (KurtE)
Fix PT8211 output on Teensy 4.x
Fix USB BDT clear at startup on Teensy 3.x (Memotech-Bill)
Add digitalToggle(pin)
Fix numerical overflow in Audio CPU usage on Teensy 4.x
Remane addStorage to addMemory
Add Teensy 3.5/3.6 hardware random to Entropy (Manitou)
Fix ILI9341_r4 readcommand() & add readScanLine() on Teensy 4.x
Installer will delete old/stale libraries
Linux installer checks udev rules
Libraries updated: ADC, ILI9488_t3, RA8875
Fix audio library on Teensy LC
Fix ST7735_t3 spitftbitmap example (KurtE)
 
tested teensyduino with arduino 1.8.13 this am - all ok w compile/run/serial monitor using codes
containing adc functions for tlc, t36, t4. install 153 on top of 153b3, win7pro64

do not know whether it is new arduino or teensyduino 1.53 (i noticed this with 153b3 also) but
having the serial monitor connect successfully w any given teensy on the first try seems to be
much more reliable than with 1.52 and 1.48 and 1.41
 
Last edited:
I thought I would mention, I have done a diversion today, and
With a new RPI4 with 8GB memory,

I downloaded the released Raspberry PI OS (32 bits) and installed, then updated the firmware to allow to boot from SSD, then cloned the SDCard to SSD and now booting off of it.
I then instelled Arduino 1.8.13 plus this released Teensyduino.

I had already had installed the udev rules, but was nice that it checked this for me. I then built the spitftbitmap for st7735_t3/89 and build and ran on LC. Verified that it ran and had the color problems mentioned. I then cloned down my github fork and switched to my branch with PR in it and slected the right display card and it shows with the right colors.

Note: the currently one will not compile on a blank system like this as it includes the Adafruit_GFX.h file. My updated version does not require it as we don't use it in this sketch.

But so far everything is working fine :D

But now back to my normal diversions.
 
@Paul Request for small change.

Any chance to make _reboot_Teensyduino_() a weak definition so that code can do graceful shutdown of external devices before jumping to the bootloader?

Currently I just add
Code:
__attribute__((weak))
manually so I can override it with shutdown code such as the following...

Code:
void _reboot_Teensyduino_(void) {
        turn_off_motors();
        turn_off_heaters();
        turn_off_air();
        engage_safety_interlock();
        __asm__ volatile("bkpt");
        __builtin_unreachable();
}

This would be just convenient, and others may find it useful, for use in CNC/3D printers, etc.
Hope you will consider it. Than ks fo all your awesome work.
 
@Paul Request for small change.

Any chance to make _reboot_Teensyduino_() a weak definition so that code can do graceful shutdown of external devices before jumping to the bootloader?
...

Something like that seems a good idea.

Perhaps add a call to a shutdown_hook() similar to :
Code:
void startup_late_hook(void)		__attribute__ ((weak, alias("startup_default_late_hook")));
 
No, the idea is to catch the firmware upload, and shutdown external devices when we _know_ we are going to reboot, which is different than not knowing.
The startup hook isn't going to work, that's too late, and would be no different than using setup.
The extrenal devices are on SPI, serial, and all sorts of different interfaces that don't get regular communications, thus making a watchdog unusable as well.
The only time everything "knows" nothing else is running is when the power switch is off.
 
I think @defragster was suggesting maybe add a new hook like the startup_late_hook,
something like maybe reboot_teensy_hook that would also be weak and probably called by _reboot_teensyduino_
 
I think @defragster was suggesting maybe add a new hook like the startup_late_hook,
something like maybe reboot_teensy_hook that would also be weak and probably called by _reboot_teensyduino_

Yes - understood as KurtE notes - exactly that - except early/late didn't seem helpful as it would be a single weak call like :: shutdown_hook()

shutdown_default_hook() would be called - by default to no effect in _reboot_Teensyduino() before the reboot would happen.

When a user had overriding code for shutdown_hook() - it would have a chance to perform a 'clean shutdown'

Note sure if it might apply to both :
Code:
 void _reboot_Teensyduino_(void) __attribute__((noreturn));
 void _restart_Teensyduino_(void) __attribute__((noreturn));

Actually the reboot seems delayed by usb_reboot_timer - so maybe an _early hook there and a _late hook in the _reboot_Teensyduino - but that would be more involved - unless it was to be allowed to IGNORE the reboot request in _early by not setting the timer.
 
Just adding weak attribute adds zero code though, if unused, and it is a one-liner.
Not worried on the reboot case, that's OK. It's the case of where new firmware upload could be faulty...
I'm also thinking another use case as well, like UHS-3, where if you have open files on a USB storage device, and writing is going on, that you could close the file gracefully... e.g. logfile. Would be useful as well with SDcard too.
I can think of dozens of reasons to do this.
 
Hi,
I already found that in Teensyduino 1.52, but it's still here :
In teensy4 core, file usb_rawhid.c, line 139, SEREMU_TX_SIZE should rather be RAWHID_TX_SIZE ...
 
Hi Guys,

Is there a fix somewhere for the Aduino Gui running really slow on OSX?

For instance 10 seconds of spinning beach ball when I click on a menu.

Cheers

Andy
 
There’s not really a fix for it from what I can tell it’s based on your disk performance, now that I’m running from an NVME instead of a SATA SSD the freezing seems to be less noticeable or that could just be because I’m running a better laptop now overall.
 
Thanks for the reply, I have a 12 core, 32gb Ram, NVME drive. It’s a pretty fast machine.

Arduino without the teensy software installed runs fine, with the teensy software installed I get very slow menu handling, the more windows open the slower it gets.

Everything else on this machine runs super fast.
 
@AndyCap - sounds like the latest integrated TeensyDuino w/IDE installer code not in use? Single mac download has IDE 1.8.13 and TD 1.53 bundled together.

Not sure if that might fix the IDE itself - or allow the computer to better trust the Teensy software with secure install?
 
Status
Not open for further replies.
Back
Top