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

Thread: Teensyduino 1.37 Released, and 1.38-beta1 (C++14 support)

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

    Teensyduino 1.37 Released, and 1.38-beta1 (C++14 support)

    Teensyduino 1.37 has been released. There were no substantial changes since 1.37-beta4.


    Here is a first beta test for Teensyduino 1.38. This is identical to 1.37, except C++14 dialect is used for compiling on Teensy LC, 3.0, 3.2, 3.5 & 3.6. The old 8 bit boards still use C++11.

    Linux 32 bit:
    https://www.pjrc.com/teensy/td_138-b...nstall.linux32

    Linux 64 bit:
    https://www.pjrc.com/teensy/td_138-b...nstall.linux64

    Linux ARM:
    https://www.pjrc.com/teensy/td_138-b...stall.linuxarm

    Mac OS-X:
    https://www.pjrc.com/teensy/td_138-b...inoInstall.dmg

    Windows:
    https://www.pjrc.com/teensy/td_138-b...inoInstall.exe

  2. #2
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,682
    I ran several of the sketches that I used to test as before some had no issues but there were issues with three libraries, 1 Adafruit and 1 from Eigen. Here we go:

    Defragster's Serial Speed Test: no issues
    USB Host Shield Board_QC: No compile errors and ran fine
    SerialHelloWorld (MTP): No compile errors and ran fine
    FreeIMU (a bunch of legacy Libs included): no compile errors
    FreeIMUEKF: 1 error in quarternion.h (Eigen): undefined reference to `operator delete(void*, unsigned int)'
    TeensyRoverThreaded: Adafruit_BNO055-master/Adafruit_BNO055.h:61: undefined reference to `operator delete(void*, unsigned int)'
    TeensyRoverOpenMV: Adafruit_BNO055-master/Adafruit_BNO055.h:61: undefined reference to `operator delete(void*, unsigned int)'
    Adafruit Motor Shield DC Motor Sketch: Compiled no issues
    NXPMotionSense Orientation: No Issues.

    Not sure if there will be other errors once the operator delete if fixed. Have to figure that one out.

    PS: Configure Arduino 1.8.3, 1.38beta1, Windows 10 64 bit.

  3. #3
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,682
    To keep it simple I ran the sensorapi.ino example for the BNO055 and get the same error but I copied a little more of the error:

    Code:
    Archiving built core (caching) in: C:\Users\CYBERP~1\AppData\Local\Temp\arduino_cache_676287\core\core_teensy_avr_teensy35_usb_serial,speed_120,opt_o2std,keys_en-us_bbc7c6806654ab36443e271befb1ac3c.a
    
    Linking everything together...
    
    "C:\Local Programs\arduino-1.8.3-c14\hardware\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax,--defsym=__rtc_localtime=1497941483 "-TC:\Local Programs\arduino-1.8.3-c14\hardware\teensy\avr\cores\teensy3/mk64fx512.ld"  -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -o "C:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_104757/sensorapi.ino.elf" "C:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_104757\sketch\sensorapi.ino.cpp.o" "C:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_104757\libraries\Wire\Wire.cpp.o" "C:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_104757\libraries\Wire\WireKinetis.cpp.o" "C:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_104757\libraries\Wire\utility\twi.c.o" "C:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_104757\libraries\Adafruit_BNO055-master\Adafruit_BNO055.cpp.o" "C:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_104757/core\core.a" "-LC:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_104757" -larm_cortexM4lf_math -lm
    C:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_104757\sketch\sensorapi.ino.cpp.o: In function `Adafruit_BNO055::~Adafruit_BNO055()':
    
    C:\Users\CyberPalin\Documents\Arduino\libraries\Adafruit_BNO055-master/Adafruit_BNO055.h:61: undefined reference to `operator delete(void*, unsigned int)'
    
    collect2.exe: error: ld returned 1 exit status
    
    
    Using library Wire at version 1.0 in folder: C:\Local Programs\arduino-1.8.3-c14\hardware\teensy\avr\libraries\Wire 
    Using library Adafruit_Sensor-master at version 1.0.2 in folder: C:\Users\CyberPalin\Documents\Arduino\libraries\Adafruit_Sensor-master 
    Using library Adafruit_BNO055-master at version 1.1.3 in folder: C:\Users\CyberPalin\Documents\Arduino\libraries\Adafruit_BNO055-master 
    Error compiling for board Teensy 3.5.

  4. #4
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,682
    Did a little more digging and think the errors is in there utility classes for vector, quaternion, math and imumath files.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,624
    Quote Originally Posted by mjs513 View Post
    To keep it simple I ran the sensorapi.ino example for the BNO055
    Confirmed, I'm seeing the same compile error here....

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,624

  7. #7
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    You could just link against the C++ standard library (add '-lstdc++' to the link flags).

    Sample sketch built with C++11, no standard C++ lib:

    Sketch uses 20696 bytes (1%) of program storage space. Maximum is 1048576 bytes.
    Global variables use 5264 bytes (2%) of dynamic memory, leaving 256880 bytes for local variables. Maximum is 262144 bytes.

    Built with C++14, '-lstdc++':
    Sketch uses 20700 bytes (1%) of program storage space. Maximum is 1048576 bytes.
    Global variables use 5264 bytes (2%) of dynamic memory, leaving 256880 bytes for local variables. Maximum is 262144 bytes.

  8. #8
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,682
    @Paul. That looks like it did the trick. Everything compiles now that threw the operator delete error.

    UPDATE: Would @tni's suggestion be a better way to go in case there are any gotcha's in libraries that we haven't been tested yet?
    Last edited by mjs513; 06-20-2017 at 12:56 PM.

  9. #9
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,682
    just a quick update on testing. I am using a teensy 3.5 and a prop shield and tested the nxpsensorfusion madgwick filter, serialflash rawhardware test and teensytransfer command -I. All work no issue.

    Loaded and ran Manitou's text-2-speech and talkie libraries and no issues with c++14. Going through things slowly.

    EDIT1 (622): Been playing around with propshield and playing audio files, using the wave, mpg and raw examples. Other than not knowing the correct format for the files the examples work from serialflash and sd card using 1.38beta1. Going to test fastLED soon.

    EDIT2: Ok. went through the some of the FastLED examples and all worked on the propshield. My problem was config control on the libraries

    One suggestion on the propshield is to create a series of examples with the modifications already made to work with the propshield. If you want I can use a couple that I worked on and post them someplace. Maybe it will help someone as thick headed as me. Took me awhile to go through about 12 pages of the prop shield thread. A lot of good info that should be consolidated as well as some good sketches.

    Respectfully
    Mike
    Last edited by mjs513; 06-23-2017 at 12:31 AM.

  10. #10
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,682

    Flac codec error compiling with c++14

    Using @Frank B's teensy-codec-lib for the flac codec (didn't see it in the Audio library) I received the following error:

    Code:
    C:\Users\CYBERP~1\AppData\Local\Temp\arduino_build_953402\libraries\Arduino-Teensy-Codec-lib-master\play_sd_flac.cpp.o: In function `AudioPlaySdFlac::stop()':
    
    C:\Users\CyberPalin\Documents\Arduino\libraries\Arduino-Teensy-Codec-lib-master/play_sd_flac.cpp:63: undefined reference to `operator delete(void*, unsigned int)'
    
    collect2.exe: error: ld returned 1 exit status
    I am attaching the sketch that I am using. It compiles and runs fine with c+11.

    EDIT: Instead of sleeping a did a double check on the new.h and new.cpp files. The changes you made earlier to new.* were not on my machine anymore. I must of did something that changed the files back to the original. I apologize for not checking first. Didn't register that this was the same issue.. Again my apologies.


    Edit: been giving the sd and parts of the audio lib a work out and this is the only conflict I have seen so far. I am using a prop-shield with a T3.5 using the 1.37 with c++14.
    Attached Files Attached Files
    Last edited by mjs513; 06-28-2017 at 04:45 AM. Reason: Update

  11. #11
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    1,626
    Just tried to compile my actual project (intense use of two FTMs, one PDB, 2 DACs and the FPU on Teensy 3.6, only using own proprietary libraries) in TD1.38beta 1 => No problems

  12. #12
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,438
    @Paul,
    would it be possible to add -mpure-code and to use adjusted linker-files ?
    Code:
    . . .
        .text : {
            . = 0;
            KEEP(*(.vectors))               
            . = 0x400;        
            KEEP(*(.flashconfig*))
            *(.startup*)
    . . .

  13. #13
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    Quote Originally Posted by Frank B View Post
    @Paul,
    would it be possible to add -mpure-code and to use adjusted linker-files ?
    One vote against. I don't see a benefit, it tends to produce larger, slower and less readable (the disassembly) code.

    E.g. from:
    https://forum.pjrc.com/threads/43811...l=1#post142818

    Teensy 3.6 @ 180MHz, no pure code, optimize faster, TD1.38b1:
    Sketch uses 33780 bytes (3%) of program storage space. Maximum is 1048576 bytes.
    Global variables use 6236 bytes (2%) of dynamic memory, leaving 255908 bytes for local variables. Maximum is 262144 bytes.

    Duration [int, no fastrun ]: 234
    Duration [int, fastrun ]: 235
    Duration [int, no fastrun, no cache]: 276
    Duration [int, fastrun, no cache ]: 235

    Duration [double, no fastrun ]: 835
    Duration [double, fastrun ]: 890
    Duration [double, no fastrun, no cache]: 1690
    Duration [double, fastrun, no cache ]: 891

    mpure-code:
    Sketch uses 35292 bytes (3%) of program storage space. Maximum is 1048576 bytes.
    Global variables use 6340 bytes (2%) of dynamic memory, leaving 255804 bytes for local variables. Maximum is 262144 bytes.

    Duration [int, no fastrun ]: 254
    Duration [int, fastrun ]: 255
    Duration [int, no fastrun, no cache]: 350
    Duration [int, fastrun, no cache ]: 254

    Duration [double, no fastrun ]: 861
    Duration [double, fastrun ]: 916
    Duration [double, no fastrun, no cache]: 1889
    Duration [double, fastrun, no cache ]: 918

  14. #14
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,438
    Larger, yes - Just don't use it for the LC ? All other teensy 3.x -models have way more flash-mem than 99.999% of all users ever need. That's not a valid argument. You can't buy anything with a few 100 bytes savings.

    Readable ? not important -

    slower: No, not for the sketches I tested it with. It's faster. These simple, small, very synthetic benchmarks say nothing. (I've mentioned that several times.. use a _real_ application. I get 3% more speed in my C64 emulation (-O2) )
    (In contrast, LTO is slower than -mpure-code for me .. and LTO is in Teensyduino already)
    And I guess, ARM did not implementt & publish it to have disadvantages only...
    Last edited by Frank B; 06-28-2017 at 08:08 PM.

  15. #15
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    The performance degradation I have seen in several cases may very well not reflect the average behavior. However, it's clear that mpure-code at least sometimes causes a performance degradation (along with the code size increase).

    I don't mind if it's added as an additional option (like LTO), but IMO it's not clear that it should simply be included in the default compiler settings (without a lot more testing).

    If it was ready for prime time and a performance win on average, I would expect that ARM included it in O3.

    \\

    One additional optimization setting (maybe with O2), would be probably be good enough to get some testing.

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,624
    Indeed this belongs in the optimize menu. Currently there are 10 choices in the menu. I'm not looking to expand to 20, but several could be added.

    I'm looking for specific suggestions on which combinations to add to the menu.

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,624
    I'm preparing to publish 1.38-beta2. Now's the time to remind me of any fixes or issues it should address.

    I've added tni's suggestion to use -lstdc++ with the linker command. I've also added two options to use -mpure-code together with -O3 in the optimize menu.

    Click image for larger version. 

Name:	sc.png 
Views:	162 
Size:	192.7 KB 
ID:	10944

Posting Permissions

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