Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 13 of 13

Thread: Teensyduino 1.19 Release Candidate #2 Available

  1. #1
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    338

    Teensyduino 1.19 Release Candidate #2 Available

    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

  2. #2
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    528
    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.

  3. #3
    Senior Member
    Join Date
    Nov 2012
    Location
    Boston, MA, USA
    Posts
    1,108
    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.

  4. #4
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    528
    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.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,684
    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.

  6. #6
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    528
    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.
    :-)

  7. #7
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,232
    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.

    Code:
    teensy 3.0 @ 96mhz  2048 KBs
    teensy 3.1 @ 96mhz  3657 KBs 
               @ 168mhz 5688 KBs  (rc1 was 4654 KBs)
    Other MCU performance numbers at
    https://github.com/manitou48/DUEZoo/...aster/perf.txt

  8. #8
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    Isn't the perf.txt on github.. is a mix of CPUs with / without FPUs, and mix of floats and doubles?

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,684
    Quote Originally Posted by xxxajk View Post
    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.

  10. #10
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,684
    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.

  11. #11
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,232
    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

  12. #12
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,232
    Quote Originally Posted by stevech View Post
    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)

  13. #13
    Senior Member
    Join Date
    Jul 2013
    Posts
    272
    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]

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •