View Full Version : Teensyduino 1.19 Release Candidate #2 Available

05-30-2014, 11:45 PM
Here is a second release candidate for Teensyduino 1.19:

Old beta download links removed. Please use the latest version:

Please give this a try and report any bugs. Try to include a sample program that reproduces the problem!

Here's a list of the changes since Teensyduino 1.19-rc1 (http://forum.pjrc.com/threads/25888-Teensyduino-1-19-Release-Candidate-1-Available):

Fix USB MIDI at new clock speeds
Add slow clock options, 2, 4, 8 & 16 MHz... thanks for all the help Duff :)
Increase flash overclocking when CPU is overclocked to 168 MHz
Add DMA priority register definitions
Minor Makefile improvement (Matthias Lohr)
Aesthetic source code cleanup

06-01-2014, 04:52 PM
I don't use the IDE, but I do use the tools and headers, and I'll let you know how well it works out for me. Thanks Paul.

06-01-2014, 06:37 PM
Installed without issue over the top of 1.19rc1.
Tried a couple of MIDI-generating sketches on Teensy 3.1 at 96 and 72MHz, did not see any problems monitoring with MIDI-OX.

06-02-2014, 07:12 AM
Here are bugs I found...

1: Minor bug, should be easy to fix

README.txt is set to executable, it should be mode 0644, not mode 0755

2: Minor bug, bloat, duplicate files
Arduino/hardware/tools/arm-none-eabi/arm-none-eabi/bin -and- Arduino/hardware/tools/arm-none-eabi/bin
Should use symlinks to files in hardware/tools/arm-none-eabi/bin or the other way around instead of two copies of the same file.
g++ and c++ are also the same file, just symlink c++ to g++.

3: Major annoyance with libz and toolchain
/opt/Arduino/hardware/tools/arm-none-eabi/bin/arm-none-eabi-ld: /usr/lib/libz.so.1: no version information available (required by /opt/Arduino/hardware/tools/arm-none-eabi/bin/arm-none-eabi-ld)
/opt/Arduino/hardware/tools/arm-none-eabi/bin/arm-none-eabi-c++filt: /usr/lib/libz.so.1: no version information available (required by /opt/Arduino/hardware/tools/arm-none-eabi/bin/arm-none-eabi-c++filt)
... etc etc...

As stated months before, please don't compile the toolchain with libz, it isn't needed, or required, and only causes problems.
A built-in libz exists for the toolchain, and it is always best to use it, since it does not depend on the system libraries.
By using the built-in, it will slightly bloat some the binaries, but that is the cost to get compatibility across all Linux distributions.
However, you won't miss the extra space if you use symbolic links as above. So overall you will use less space.

Stuff compiles, but...
For now, I'll replace the toolchain with my self-built one, but I would do that anyway since I use the newer ld anyway and it removes the annoying libz complaints.

06-02-2014, 11:37 AM
I'm planning to update the toolchain in 1.20, mainly to fix the linker issue that results in larger-than-necessary compiled code (based on your earlier, very helpful work on those issues, which I greatly appreciate). That update should also solve minor issues with permissions and libz, but to be honest, these types of issues are pretty much at the absolute bottom of my priority list.

Unless there's a bug that results in wrong executable code, I'm simply not touching the toolchain for 1.19. In fact, a toolchain update might get delayed until 1.21, 1.22 or later. I see these are very minor, low priority issues. The only one I actually care about solving is the linker issue which results in extra (harmless) stuff compiled into all programs on Teensy 3.x. I have a long list of much higher priority issues (like the SPI sharing troubles) and feature requests.

I do not intend to ever address the duplicate files.

Linux already takes 2 of the 4 builds, which both require the extra step of using a virtual machine to compile against an older version of Ubuntu for compatibility with many older Linux systems. Linux support also results in a vastly disproportionate number of platform specific feature requests... for a platform with only a tiny faction of all users. I intend to continue supporting Linux, but I simply can't allow Linux support to divert my attention away from much higher priority development.

06-02-2014, 12:18 PM
Understood. You wanted a report, and that is what I have to report. Everything else is working fine, including I/O at the highest F_CPU.
Too bad I can't push I/O faster (or is that actually possible??)
Current test result from my project shows minimal gains, on the order of a few hundred milliseconds.
1MB write timing test 2048 writes, (0), (0), 7783 ms (8 sec)
1MB read timing test 2048 reads, (20), 2165 ms (2 sec)
Directory of '/'
-rw--a 1048576 2042-10-01 00:00:24 1MB.bin
123455232 bytes available on disk.

Also looks like either there is an RTC issue, or my RTC library is goofed up. Other than that, all is working OK.

06-02-2014, 04:14 PM
Various tests on 3.0 and 3.1 using 1.19rc2 look good. Here are numbers for MD5 data rate (KBytes/sec) for 1024 bytes.

teensy 3.0 @ 96mhz 2048 KBs
teensy 3.1 @ 96mhz 3657 KBs
@ 168mhz 5688 KBs (rc1 was 4654 KBs)

Other MCU performance numbers at

06-02-2014, 05:47 PM
Isn't the perf.txt on github.. is a mix of CPUs with / without FPUs, and mix of floats and doubles?

06-02-2014, 06:35 PM
Also looks like either there is an RTC issue, or my RTC library is goofed up. Other than that, all is working OK.

Can you give me any more details on the RTC issue?

I'll also test the RTC on a board here. Should I try something other than the Time library example?

My hope is to wrap up 1.19 today or tomorrow, or at least sometime this week if more work is needed.

06-02-2014, 08:17 PM
I tested the RTC on a Teensy 3.1 here. It seems to be working fine.

The initialization code could be more aggressive about setting the clock, but so far I'm not 100% confident of a way to detect the first reboot after programming the flash with new code.

06-02-2014, 08:33 PM
example-time-timeteensy3 seemed to work OK for me on 3.1 with rc2. i also tested some lower level RTC sketches (alarms, ppm calculations) with 32khz crystal, and they looked OK

06-02-2014, 08:36 PM
Isn't the perf.txt on github.. is a mix of CPUs with / without FPUs, and mix of floats and doubles?

yep, a delightful basket of apples and oranges. (fixed the raspberry/beagle sin numbers)

06-03-2014, 06:20 PM
Just a harmless warning:

C:\Program Files (x86)\Arduino\hardware\teensy\cores\teensy3\mk20dx 128.c: In function 'ResetHandler':
C:\Program Files (x86)\Arduino\hardware\teensy\cores\teensy3\mk20dx 128.c:366:15: warning: unused variable 'n' [-Wunused-variable]