Teensyduino 1.19 Release Candidate #2 Available

Status
Not open for further replies.

Paul

Administrator
Staff member
Here is a second release candidate for Teensyduino 1.19:


Old beta download links removed. Please use the latest version:
https://www.pjrc.com/teensy/td_download.html


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:

  • 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
 
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.
 
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.
 
Here are bugs I found...

1: Minor bug, should be easy to fix

Arduino/hardware/tools/arm-none-eabi/arm-none-eabi/bin
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.
 
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.
 
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.
:)
 
Isn't the perf.txt on github.. is a mix of CPUs with / without FPUs, and mix of floats and doubles?
 
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.
 
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.
 
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
 
Just a harmless warning:
Code:
C:\Program Files (x86)\Arduino\hardware\teensy\cores\teensy3\mk20dx128.c: In function 'ResetHandler':
C:\Program Files (x86)\Arduino\hardware\teensy\cores\teensy3\mk20dx128.c:366:15: warning: unused variable 'n' [-Wunused-variable]
 
Status
Not open for further replies.
Back
Top