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

[Paul]

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.


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

[mjs513]

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.

[mjs513]

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:

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.

[mjs513]

Did a little more digging and think the errors is in there utility classes for vector, quaternion, math and imumath files.

[PaulStoffregen]

To keep it simple I ran the sensorapi.ino example for the BNO055

Confirmed, I'm seeing the same compile error here....

[PaulStoffregen]

Please give this change a try.

https://github.com/PaulStoffregen/co...da07fe0edefbf5

[tni]

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.

[mjs513]

@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?

[mjs513]

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

[mjs513]

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

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.

[Theremingenieur]

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

[Frank B]

@Paul,
would it be possible to add -mpure-code and to use adjusted linker-files ?

. . .
    .text : {
        . = 0;
        KEEP(*(.vectors))               
        . = 0x400;        
        KEEP(*(.flashconfig*))
        *(.startup*)
. . .

[tni]

@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

[Frank B]

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...

[tni]

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.

[PaulStoffregen]

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.

[PaulStoffregen]

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.