PDA

View Full Version : Teensyduino 1.49 Released



Paul
01-14-2020, 06:50 AM
Teensyduino 1.49 has been released.

(https://www.pjrc.com/teensy/td_download.html)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 (https://forum.pjrc.com/threads/59030-Teensyduino-1-49-Beta-5).

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

mjs513
01-14-2020, 10:58 AM
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.

skpang
01-14-2020, 11:36 AM
Works fine on MacOS Catalina with Teensy 3.2, 3.6, 4.0

bill.pugh
01-14-2020, 04:02 PM
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

KurtE
01-14-2020, 04:32 PM
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.

3Domse3
01-14-2020, 05:07 PM
Can I just install it over an old version or should I remove 1.48 first?

bicycleguy
01-14-2020, 05:10 PM
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

defragster
01-14-2020, 07:24 PM
Can I just install it over an old version or should I remove 1.48 first?

Yes, A newer installer will properly overwrite prior versions with all the new code and utilities.

PaulStoffregen
01-14-2020, 07:38 PM
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.

PaulStoffregen
01-14-2020, 07:44 PM
...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.

defragster
01-14-2020, 07:51 PM
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.

quadrupel
01-14-2020, 08:53 PM
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.

Avenue33
01-15-2020, 07:51 PM
Great work!

Are you considering designing a specific icon for Teensyduino?

KurtE
01-15-2020, 07:56 PM
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?

quadrupel
01-15-2020, 08:26 PM
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.

PaulStoffregen
01-15-2020, 08:49 PM
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.

quadrupel
01-15-2020, 08:58 PM
Paul, thanks for the explanation.

vk4ghz
01-16-2020, 04:15 AM
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?

PaulStoffregen
01-16-2020, 07:15 AM
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.

dataplow
01-16-2020, 08:28 PM
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?

defragster
01-16-2020, 08:38 PM
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?

KurtE
01-16-2020, 10:33 PM
@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.

dataplow
01-17-2020, 12:59 PM
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.

Rezo
01-19-2020, 01:41 PM
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?
18788

I'm running Catalina 10.15.2 on a late 2016 Macbook Pro (non touch bar)

KurtE
01-19-2020, 02:13 PM
@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.

bicycleguy
01-20-2020, 02:50 AM
...
Shouldn't it have prompted the installer?
..


Rezo, you don't need to do anything else. It's all pre-installed in the Teensyduino.app when you unzip it. The instructions haven't been updated for the super easy Catalina install. The main odd
thing, but doesn't really matter is the Application is called Teensyduino in the finder and info but Arduino in it's menu bar. Probably should move it to the Application folder, but it doesn't matter.

bfinney
01-21-2020, 11:45 PM
Just downloaded 1.49 and installed over 1.48 in arduino-1.8.10, os is Ubuntu-64 18.04.3 LTS
I can not find the QuadTimer library, there is no library with this name and doing a search of the teensy library directory for IRQ_QTIMER only returns uses in the PulsePosition library.
Is this library there and I just can't see it or is it missing from the latest install?

KurtE
01-22-2020, 01:27 AM
Which Quad Timer Library?

The user @luni has their own library that includes Quad Timer... Mentioned in a current thread:
https://forum.pjrc.com/threads/59112-TeensyTimerTool

PWM uses it for some IO pins...

The ADC Library - current stuff the @pedvide just pulled in Pull request optionally uses a couple of Quad timers (i.e. those not used for IO pins on T4).

bfinney
01-22-2020, 05:49 AM
Which Quad Timer Library?

The user @luni has their own library that includes Quad Timer... Mentioned in a current thread:
https://forum.pjrc.com/threads/59112-TeensyTimerTool

PWM uses it for some IO pins...

The ADC Library - current stuff the @pedvide just pulled in Pull request optionally uses a couple of Quad timers (i.e. those not used for IO pins on T4).

The one that is mentioned in the 1.49 release notes in the first post of this thread, I assume that it should be included with the 1.49 install.

defragster
01-22-2020, 07:15 AM
it is in : ...\hardware\teensy\avr\cores\teensy4\pwm.c

Part of PWM code for analogWrite and analogWriteFrequency

// ...
void quadtimerWrite(IMXRT_TMR_t *p, unsigned int submodule, uint16_t val)
void quadtimerFrequency(IMXRT_TMR_t *p, unsigned int submodule, float frequency)
// ...

Frank2
01-22-2020, 09:34 AM
Maybe it should be "QuadEncoder" instead of "QuadTimer" ? I think the encoder library is new in 1.49 and not in the news list.

KurtE
01-22-2020, 12:07 PM
Maybe it should be "QuadEncoder" instead of "QuadTimer" ? I think the encoder library is new in 1.49 and not in the news list.
Yes I believe the update list meant to say QuadEncoder as it was attributed to @mjs513...

bfinney
01-23-2020, 12:03 AM
Yes I believe the update list meant to say QuadEncoder as it was attributed to @mjs513...

OK, so I'm not going crazy. I see that the QuadEncoder library is new and from some of the above comments I now have some examples on using the QuadTimers on Teensy4.0
Thanks,

Back to lurking mode.

defragster
01-23-2020, 12:14 AM
Yes I believe the update list meant to say QuadEncoder as it was attributed to @mjs513...

I wondered about that when I visited the first post ...

HallMark
01-27-2020, 03:27 PM
Looks like with Teensyduino 1.49 deafult SD library is having issues. Basic example ReadWrite is now failed to Init SDCard function. I am using Teensy 4.0

Hardware connection is SPI. Pins 11,12,13 and 4 as CS


18887

mjs513
01-27-2020, 03:33 PM
Hard to help debug since we do not know what your hook up is for a sd card reader. Are you hooked up to SPI or using SPI1 etc. Or what your wiring looks like. Did you remember to change the CS pin for the pin you are using?

HallMark
01-27-2020, 03:48 PM
Hard to help debug since we do not know what your hook up is for a sd card reader. Are you hooked up to SPI or using SPI1 etc. Or what your wiring looks like. Did you remember to change the CS pin for the pin you are using?

Sorry, I missed that out. Post Updated. Hardware connection is SPI. Pins 11,12,13 and 4 as CS.
If I am not wrong I was having this setup working with previous version 1.48. I am going to try that out tomorrow as I also have to downgrade Arduino.

HallMark
01-28-2020, 09:43 AM
Sorry, I missed that out. Post Updated. Hardware connection is SPI. Pins 11,12,13 and 4 as CS.
If I am not wrong I was having this setup working with previous version 1.48. I am going to try that out tomorrow as I also have to downgrade Arduino.

I just downgrade to Teensyduino 1.48 and SD Card ReadWrite example is working fine. And Same Example same hardware setup it gets SD Card Init failed with Teensyduino 1.49.
Teensy 4.0
Hardware connection is SPI. Pins 11,12,13 and 4 as CS.