Teensyduino 1.49 Released

Status
Not open for further replies.

Paul

Administrator
Staff member
Teensyduino 1.49 has been released.

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

1.49 brings support for USB MIDI, Keyboard, Mouse, Joystick on Teensy 4.0, support for MacOS Catalina, improved USB Serial speed on Teensy 4.0, Wire library improvements on Teensy 4.0, and libraries WS2812Serial, ADC, PulsePosition, TimerThree, RA8875, QuadTimer, FlexCAN_T4, ILI9488_t3, ssd1351, SoftPWM ported to Teensy 4.0, and many small fixes and improvements.

No significant changes were made since 1.49-beta5.

This is a detailed list of the changes since 1.48:


  • Support for MacOS Catalina Optimize USB serial on Teensy 4.0
  • Add Teensy 4.0 USB MIDI, Keyboard, Mouse, Joystick
  • Port WS2812Serial to Teensy 4.0 (KurtE)
  • Move USB serial buffers from ITCM to OCRAM on Teensy 4.0
  • Fix stalled USB serial transmit if multiple of 64 bytes on Teensy 4.0
  • Support different USB descriptors for 12 vs 480 speed on Teensy 4.0
  • Add FLASHMEM keyword
  • Arduino memory usage for Teensy 4.0 shows only RAM1 (512K) bank usage
  • Fix Audio lib delay effect maximum (2.4 sec) on Teensy 4.0
  • Fix missing ITCM padding from Teensy 4.0 memory usage
  • Fix empty code on Teensy 3.x if yield() overridden and no core lib functions used
  • Reduce DTCM memory usage by USB descriptors on Teensy 4.0
  • Fix USB transfer complete callbacks on Teensy 4.0
  • Fix Audio lib memory limit on Teensy 4.0
  • WS2812Serial add functions for better compatibility with Adafruit_NeoPixel
  • Windows teensy_serialmon (hopefully) doesn't lock up (but still too much buffering!)
  • AVR register emulation on Teensy 4.0 (KurtE)
  • Fix serial DMA def on Teensy 4.0 (KurtE)
  • Improve ADC & XBAR defs on Teensy 4.0 (KurtE)
  • Improve quadrature encoder defs on Teensy 4.0 (mjs513)
  • Add Teensy 4.0 USB Touchscreen, not finished... work in progress
  • Remove serial monitor debug messages on Arduino 1.8.9
  • Fix delay() and micros() on Teensy 4.0 at 24 MHz
  • Fix USB touchscreen
  • Fix serial receive at very high baud rates on Teensy 4.0
  • Fix MIDI+Serial on Teensy 4.0
  • Fix USB Keyboard sending "garbage" in long strings on Teensy 4.0
  • Fix analogWrite for values >= 2^res on certain Teensy 4.0 pins
  • Wire only clear FIFO with bus is idle on Teensy 4.0 (KurtE)
  • Wire use open drain pin config on Teensy 4.0
  • Update ST7735_t3 library
  • SPI optimize usingInterrupt() on Teensy 4.0 (FrankB)
  • SPI allow faster clock speeds on Teensy 4.0 (KurtE)
  • Fix daylight saving time issue with automatic RTC set on Teensy 4.0
  • Add Makefile for Teensy 4.0
  • Add main.cpp for Teensy 4.0 (KurtE)
  • Fix compiler warnings on Teensy 2.0
  • Audio fix simultaneous input & output on I2S2
  • Audio allow larger queue & delay effect on Teensy 4.0
  • FastLED updated to allow WS2812Serial driver on Teensy 4.0 (KurtE)
  • PulsePosition support for Teensy 4.0 (mjs513)
  • TimerOne & TimerThree updates & fixes for Teensy 4.0 timers
  • Update ADC library (pedvide)
  • Update RA8875 for Teensy 4.0 (mjs513)
  • Add QuadTimer library (mjs513)
  • Add FlexCAN_T4 (tonton81)
  • Add ILI9488_t3 (mjs513)
  • Port ssd1351 to Teensy 4.0 (KurtE)
  • Port SoftPWM to Teensy 4.0
  • Add ADC_ETC definitions to imxrt.h (KurtE)
  • Adjust Wire library pin drive strenth on Teensy 4.0
  • Optimize Ethernet CS on Teensy 4.0 (Remo Jongeneelen)
  • Include stdbool.h - needed by Temboo library
  • Fix micros() non-monotonic output on Teensy 4.0 with slow CPU speeds
  • Optimize micros() on Teensy 4.0
  • ST7735_t3 & WS2812Serial minor cleanup
  • Improve Wire library FIFO handling for Teensy 4.0
  • ADC library updated for Teensy 4.0 (Pedvide)
  • Fix priority on 3rd & 4th IntervalTimer on Teensy 4.0 (KurtE)
  • Audio library I2S slave mode support on Teensy 4.0
  • Fix unused USB interface string descriptors
 
Just installed on a Windows10x64 with no issues. Ran a few sketches that I was just working on: RA8875 and ILI9488 and both uploaded and worked with no problems.

Also checked the BNO080 and ICM-20948 I2C. Both loaded up and ran without issues. No hangs or stalls - just based on quick tests.
 
I downloaded the OS X Catalina version (which is the full Arduino IDE application, with the Teensyduino mods applied), and that seems to work fine. Thanks.

What is the situation on libraries, since it doesn't provide a list of which libraries to install? From first glance, it looks like it installs all of them, in a location where there are only used for Teensy processors. Is that correct?

Bill Pugh
 
I am not a big MAC user, but have a several year old MAC notebook which I use from time to time.

I downloaded it, and I am pretty sure it is the whole thing. That is you don't run any installers.

And yes all of the files are there: If you go to where you have it, (in my case I moved it to applications). and use the command (something like view package contents),
you will find all of the Teensy libraries in a place like: Contents/Java/Hardware/teensy/avr/libraries

Edit: I might mention that I installed it on MAC (Macbook Pro Early 2013 version) Catalina 10.15.2 and appears to run .

Also installed on Windows 10 and again so far so good.
 
Mac Catalina, installed great, super easy, however, for newbies the instructions for Catalina on the download page will be very confusing.

Tried many T4 with ILI9341_t3 programs, T2,3,4 all worked great. T4 with ILI9341_t3 with sound was much improved over earlier (which?) versions.

thanks
 
Generally you can install over an old version. The one gotcha is when a file existed in the old version but was removed or renamed in the new version. The installer knows how to deal with this and safely delete old files from the core lib, but not in the many other libraries. So if there is a problem, you can expect to see it turn up as duplicate code in some library. Thankfully, most libs tend to only add new files over time, so those sorts of problems are pretty rare.
 
...the OS X Catalina version
....
What is the situation on libraries, since it doesn't provide a list of which libraries to install? From first glance, it looks like it installs all of them, in a location where there are only used for Teensy processors. Is that correct?

Yup, that's correct. We have to submit a set of files to Apple for notarization. No changes can be made after signing and notarization.

Until Catalina, I always found ways to work around these limitations. But Apple notarization is designed to strictly enforce all of Apple's requirements. I'm done with MacOS workarounds. We're following Apple's rules now, to the letter, which means nothing can be changed.
 
Generally you can install over an old version. The one gotcha is when a file existed in the old version but was removed or renamed in the new version. The installer knows how to deal with this and safely delete old files from the core lib, but not in the many other libraries. So if there is a problem, you can expect to see it turn up as duplicate code in some library. Thankfully, most libs tend to only add new files over time, so those sorts of problems are pretty rare.

Good info. Didn't know the upgrade cleanup was limited to core files.

I was going to note that personal edits of added files will not be touched, and that library adds/edits should be done in 'sketchbook\libraries' and is why the IDE looks there first for 'newer'/user copies.


Didn't know '...\hardware\teensy\avr\libraries' wasn't cleaned up - that would be more unknowable. I tried to downgrade and that was a fail with the note indicating the old installer wouldn't know what changes might leave spare files - so it was clear it did some cleanup … for '...\hardware\teensy\avr\cores' when reinstalling same or newer TeensyDuino.
 
Just installed on a Mac with Catalina. All is well except I have a question. An empty sketch consumes 41660 bytes of global memory. This is the same as for Beta 5. Have debugging tools been left enabled? It seems quite high to me.
 
Just installed on a Mac with Catalina. All is well except I have a question. An empty sketch consumes 41660 bytes of global memory. This is the same as for Beta 5. Have debugging tools been left enabled? It seems quite high to me.

Which Teensy?
 
Sorry, Teensy 4.0
CPU speed and compiler optimization do not matter.
Compilation on an empty sketch is always "Global variables use 41660 bytes (7%) of dynamic memory, leaving 482628 bytes for local variables. Maximum is 524288 bytes."
All of my projects tested, so far, compile and run as expected; and the Global variable byte count changes as expected, but always from the 41660 baseline.
 
An empty sketch consumes 41660 bytes of global memory.
...
It seems quite high to me.

This is normal, though the complexity of Cortex-M7 memory doesn't fit well into Arduino's very simple summary.

The lion's share of this 41K is ITCM memory used for code. The hardware has 32K granularity for assigning RAM to ITCM use, so even 1 instruction of fast code means a 32K block gets used.

Most of the rest is buffered used by USB. To you it looks like an empty sketch. But it has a powerful 480 Mbit/sec speed USB stack. If you compare to boards like Arduino Uno, consider that Uno has a 2nd chip with its own memory doing all the USB work. On Teensy and most of Arduino's newer boards, the USB is native in the chip and requires code and memory just to cause it to be seen by your PC. USB 480 Mbit/sec speed, much larger buffering is needed than 12 Mbit/sec.
 
If I'm only using Teensy 3.2 or Teensy LC parts, (not Teensy 4, as yet!) with Arduino 1.8.10, is there any reason to upgrade from TD 1.48?
 
If you're using the pre-4.0 boards and not using MacOS Catalina, 1.49 only bring very minor improvements, like a few harmless compiler warnings fixed.

Likewise, Arduino 1.8.9 may run faster than 1.8.10 which has some harmless bugs that cause some libs to be unnecessarily recompiled in some cases, especially on Windows.
 
Hello, observed the following with 1.49:

USB serial crashes
On reads or shortly after, USB serial inputs randomly crash the T40. This was not happening using the same code compiled to hex with 1.48.
Now reverted to 1.48, seems to work fine again @ 2M baud (need that to keep up with sensor performance, outputs are 20-50B each @ up to 1kHz, inputs are ad hoc, used as a command interface only).
This is really worrying, could someone comment please?

I2C behaviour
Some i2c sensors' 1st output is always zero, sure, but 1.49 increased this to the 1st 2-3 readings, only occurring shortly after bootup / bus init, seems OK after. Reverting to 1.48 resolves this, too.
I have not tested cutting power to the i2c sensor again, forgot, sorry (was an issue in 1.48beta, resolved in 1.48, was well happy then, as master compliance with slave failure is a major one).

HW serial crashes
This is more of a question I'd ask, as this occurs on 1.48, too, with 1.49 just making it worse (higher freq. of occurrence): intermittently, hw serial queries to a serial peripherial device (over Serial2) can hang the T40.
Cutting power to the serial peripherial eliminates these crashes (just getting nothing back out of the currently mere 5 queries in a loop, of course), using the same code that outputs each 1by1 via USB serial thereafter.
Again, compliance with peripherial failure is important, but this seems to work the other way around, T40 crashes if the peripherial is doing what it is supposed to...
Anyone have any idea what might cause this?
 
Hello, observed the following with 1.49:

USB serial crashes
On reads or shortly after, USB serial inputs randomly crash the T40. This was not happening using the same code compiled to hex with 1.48.
Now reverted to 1.48, seems to work fine again @ 2M baud (need that to keep up with sensor performance, outputs are 20-50B each @ up to 1kHz, inputs are ad hoc, used as a command interface only).
This is really worrying, could someone comment please?
Can you post a simple repro example/steps? Not sure how '@ 2M baud' relates as USB Serial is always at USB max throughput - and that was stepped up between TD 1.48 and 1.49.

I2C behaviour
Some i2c sensors' 1st output is always zero, sure, but 1.49 increased this to the 1st 2-3 readings, only occurring shortly after bootup / bus init, seems OK after. Reverting to 1.48 resolves this, too.
I have not tested cutting power to the i2c sensor again, forgot, sorry (was an issue in 1.48beta, resolved in 1.48, was well happy then, as master compliance with slave failure is a major one).
Does this change with a delay in setup before .begin() on the i2c device? Teensy enters setup very quickly and changes in 1.49 i2c Wire code - working with other tested devices - may present faster to this device.
What is the device and Can you post a simple repro example/steps?

HW serial crashes
This is more of a question I'd ask, as this occurs on 1.48, too, with 1.49 just making it worse (higher freq. of occurrence): intermittently, hw serial queries to a serial peripherial device (over Serial2) can hang the T40.
Cutting power to the serial peripherial eliminates these crashes (just getting nothing back out of the currently mere 5 queries in a loop, of course), using the same code that outputs each 1by1 via USB serial thereafter.
Again, compliance with peripherial failure is important, but this seems to work the other way around, T40 crashes if the peripherial is doing what it is supposed to...
Anyone have any idea what might cause this?
For simple repro example: Can using Serial1 Tx/Rx wired into Serial2 Rx/Tx recreate this issue in some context where the peripheral device behavior is emulated?
 
Last edited:
@dataplow - Sorry it is hard to maybe diagnose some of this without more specifics...

First with Which version of Arduino? What type of computer? Windows? Linux? MAC? version of OS?

Like: I2C behavior - What devices, what libraries? There were some major issues with Wire library with several devices, that Paul did some fixes within the last few days of this release that helped out several of them. But as for yours? Not sure.

USB Serial crash? Again hard to know without more details, like is it The T4 that is crashing or is it that the device on your PC that can not handle the data? i.e. the T4 can now output a lot more throughput to the pc.

HW Serial crash? Again no details on what device? What Baud rate? Library? Code that is running? What do you mean by crash? Is it simply your code is hung waiting for reply? Or does something crash? Or ???

Again several of us might try to help you diagnose the issues, but without a description of the setup and what code you are running, we can only take take shots in the dark.
 
Defrag, Kurt, apologies guys for not dropping code in -got reasons.
Sorted in the meantime in a largely intuitive manner, but, in a (coco)nutshell:

I haven't designed targeted tests to repro the observed pain, sorry, needed to get on with both a tool and the device code I referred to.
Device code is about 8k lines now, and it's not even written by a human operator directly (it's a, well, autocoder tool if you like, in dev in paralllel with the actual device code).
Want machines to code machines, Skynet and all that - oh come on, most of you must have been children at some point, too.

Both intermittent USB and HW serial crashes seem to have been caused by the method used for serial read bytes.
This was riddled with pointers and arrays were handled in an unnecessarily convoluted way, something I have not written (but deleted now, or rather, the mechanism generating serial port handling code for an ino, I have now rewritten from scratch).
I guess it shouldn't have worked with 1.48 in the first place, and Paul's apparently major updgrade in 1.49 probably merely caused my underlying juju to surface in a much more prominent fashion.

As for i2c, I am going to go back to 1.49 again and see if forcing simple delay before i2c bus init (currently an arbitrary 100ms in the subject device code at bootup) helps, as Defrag suggested.
 
I just downloaded v1.49 from the PJRC website. Ran the file but all it did was open an instance of Arduino marked at Teensyduino.
Shouldn't it have prompted the installer?
Screen Shot 2020-01-19 at 16.40.57.png

I'm running Catalina 10.15.2 on a late 2016 Macbook Pro (non touch bar)
 
@rezo - Nope, The new MAC OS will not allow the old style of installer to update an Arduino Install. There have been several threads on this.

Sorry I don't remember all of the appropriate MAC like terms, but basically to install the whole logical package must be built with a set of MAC utilities/libraries that are newer than some date/version and then once the package is sort of certified, nothing can change in it... From what I read some of this will get worse and it sounded like soon there will need to be a new version of Arduino to be able to work...

But again I am only paraphrasing this.
 
Status
Not open for further replies.
Back
Top