Teensyduino 1.36 Beta #1 (ARM Toolchain Update)

Status
Not open for further replies.
Frank B said:
Paul, to prevent this error - it can occur any time with different libs with lto - would it be feasable to use the alternate startup-address (linker-file from above) if "lto" is enabled ?
Click to expand...

Maybe. Probably. How, I'm not entirely sure.

I'd prefer to do this with the compiler. Maybe there's some way to detect at compile time if LTO is used, and we could just #ifdef check and use a different section name in the attribute? Or perhaps even some want to disable inlining could make LTO do what we want? But if necessary it could happen in the Arduino platform layer, to actually run the compiler command with a different linker script.
 
PaulStoffregen said:
Maybe. Probably. How, I'm not entirely sure.

I'd prefer to do this with the compiler. Maybe there's some way to detect at compile time if LTO is used, and we could just #ifdef check and use a different section name in the attribute? Or perhaps even some want to disable inlining could make LTO do what we want? But if necessary it could happen in the Arduino platform layer, to actually run the compiler command with a different linker script.
Click to expand...

Well, there is the -specs=file option. The specs are a mini-language that the gcc driver uses in setting up the various programs, etc. Warning, it is overly complicated, and when I'm doing complex specs, I always have to go back and re-read the specs information in gcc.c and in the documentation.

So for example, rather than specifying the LD file via:
  • -T{build.core.path}/mk66fx1m0.ld

you might use:
  • -specs={build.core.path}/mk66fx1m0.specs

And mk66fx1m0.specs might look something like:

Code: 
{flto:-Tmk66fx1m0-lto.ld}
{!flto:-Tmk66fx1m0.ld}

What this does is if -flto is used, it will use the linker file mk66fx1m0-lto.ld, otherwise it will use mk66fx1m0.ld. You would probably have to have the Teensy installer expand the pathname of the ld files, since you wouldn't have access to {build.core.path}.
 
Today I was curious about other thread: talking about digitalWriteFast speed, so I tried a variant of the program. I then thought maybe I should get closer to what their program was:
Code: 
void setup() {
  // put your setup code here, to run once:
  pinMode(2, OUTPUT);
  pinMode(3, INPUT);
  digitalWrite(2, LOW);
}

void loop() {
  while(1) {
    digitalWriteFast(2, !digitalReadFast(3));
  }
}
I decided to try it on one of my T3.2 boards. So I changed to board type Teensy 3.2/3.1 and built Serial.
Tried compiling Faster with LTO.

The program compiles, but neither Teensy or TyqT will upload it to the board.
TyQt says
Code: 
Sketch uses 13144 bytes (5%) of program storage space. Maximum is 262144 bytes.
Global variables use 3396 bytes (5%) of dynamic memory, leaving 62140 bytes for local variables. Maximum is 65536 bytes.
        upload@267800-Teensy  Firmware 'zzz.ino.TEENSY31.hex' is not compatible with '267800-Teensy'
An error occurred while uploading the sketch
Teensy.exe - shows zzz.ino.hex(unreadable)

Compiling with option "fast" and the program compiles and loads.
 
That is a FIXED TyCommander Problem::

TyTools-0.8.0-100...___...

I saw that and Koromix fixed it IIRC - 'he gets MCU ID from the HEX and his scheme was failing and patched'
Also - some weeks back the T_3.6 HID_ID got swapped and it won't upload at all in prior recent versions.

<edit> :: the EXE was renamed - so if "Integrated to Arduino" it requires 'Restore' and 'Integrate' to point to the renamed program.
 
Last edited:
PaulStoffregen said:
I'll put these into the next beta. Here's the boards.txt file I've got staged for the next beta, if you want to check if it really works.... Only use this with 1.36-beta1.
Click to expand...

Swapped my boards.txt and the 144 and 168 options are present and both compile and result in running T_3.5 to USB - only tested a simple 'PrintTest' sketch from 'somewhere'.

<edit>: And other that echoes USB text back and that works of course.
 
Last edited:
KurtE said:
Also by the ordering in menu, is faster faster than fast?

That is the order of the items in the menu (disregard LTO) are:
Faster, Fast, Fastest, Debug, Smallest
Click to expand...

Arduino will default to the first item in the menu, so I'm most concerned with putting the best default choice in that first place. Right now, it's looking like Faster (02) seems to be the best default for Teensy 3.x, and Smallest (Os) is best for Teensy LC.

LTO seems to be breaking some things. It's probably bugs in libraries like missing volatile, but until all those get fixed LTO probably can't be in the default location, except for these early betas.
 
PaulStoffregen said:
LTO seems to be breaking some things. It's probably bugs in libraries like missing volatile, but until all those get fixed LTO probably can't be in the default location, except for these early betas.
Click to expand...

Yup; but i'd say LTO ist working good, the code is the problem.. :)
My latest experience from today is: I re-activated my old project "C64 Emulation" wich is very much work in progress. In an intermediate step during development, i added a static array - but only wrote to it, never read. normally, gcc emits a warning in this case but produces working code-output.
This time not, and instead the code crashed, only because a "*sp++=0;".. i guess, the array got optimized out, but there were (still) the writes (?) - or something like that (code works without LTO). With LTO, code-development must be done much more carefull..
I doubt that this is good for Arduino. But it would be GREAT if there was a way, for advanced users, to activate it in Teensyduino.

On the other hand, are there really cases where LTO ist faster on the Teensy ? In my experience, it is slower..
The (small) gain of "-mpure-code" is more impressive, at the moment :) (Edit: Around 0.5%..1% faster.)
 
Last edited:
Is there a reason that '-std=gnu++0x' is used? It would be nice if that was changed to '-std=gnu++14'. GCC has no pragma for that, so the only option is to edit boards.txt.
 
- I tested GCC 6 (had mentioned it) during the past weeks. Currently, i can not recomend it. It produces wrong code with -O3 and -OS and is unreliable for large programs. BUT: When it works, it produces smaller and faster code than GCC 5.

When switching back to GCC5, I noticed that GCC5 supports -mpure-code, too.

Paul, "-mpure-code" works good so far - how about adding this to the default GCC-Switches ? (Perhaps others can test & benchmark this with GCC 5)
 
Last edited:
Frank B said:
- I tested GCC 6 (had mentioned it) during the past weeks. Currently, i can not recomend it. It produces wrong code with -O3 and -OS and is unreliable for large programs.
Click to expand...
Chances are it simply exposes more bugs - there is quite a lot of code that relies on undefined behavior. Per the release notes:

  • Type-based alias analysis now disambiguates accesses to different pointers. This improves precision of the alias oracle by about 20-30% on higher-level C++ programs. Programs doing invalid type punning of pointer types may now need -fno-strict-aliasing to work correctly.
  • Value range propagation now assumes that the this pointer in C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases ...
 
tni said:
Is there a reason that '-std=gnu++0x' is used?
Click to expand...

At the time this was done, with gcc 4.3, it was the best option to get rvalue refs.

For the 1.36 release, we're pretty solidly locked into gcc 5.4 and the settings 1.36-beta1 has been using. Except LTO, which is going to remain in the menu but will not be the default.

Within the next few days I'm going to call USB Host "beta" and change my focus to investigating a huge pile of issues that have been reported while I've been so obsessed with the host library. My goal is to roll most of those into 1.36-beta2 in a week or two, and ultimately get to a final stable 1.36 release before the end of March. I could *really* use all the help possible with testing. We really, really must get to another stable release soon.

After 1.36, I'm very willing to consider another toolchain update. Perhaps even 1.37-beta1 starting only days after a stable 1.36 release.

At this moment, we're about to start the run up to a stable release, so toolchain updates or different compile flags are off the table until after 1.36 releases.
 
I did not test libraries and so on , but i can say that GCC 5.4 is pretty good. My project wirh several 1000 lines of code and 300KB compiled code is a pretty good test. it has all.audio, dma, usb host, i2c, sd... and managed to crash the GCC 6 linker (not GCC5) with LTO :)
 
Thought I would mention. This last week I purchased a new main Windows 10 64bit machine... So I used some tools to move things around.

But I have a new install of Arduino 1.8.1 with Teensyduino 1.36beta1...
When I am doing builds example of the simple test program for shiftpwm, sometimes it gives the error message about problem rebooting the Teensy... It usually always does reboot and reprogram, but a certain percentage of the time I see the error message. Note: maybe it was happening as well on other machine, but I have been using Tycommander there... TeensynotReboot.jpg
 
1.36b1 working as much as I've used it here. Other thread test gives a 1804 byte Blink sketch with smallest LTO. I just acquired an AMD Win 10 machine I wiped and will replace this laptop as my daily driver. 8 core SSD machine with 16GB a moderately nice and free improvement - .

Kurt: I saw earlier doing the No USB on another thread - without USB on restart it (of course) can't see it and TyCommander gives this after a good upload/restart:
upload@2056390-Teensy Failed to reset board '2056390-Teensy'
An error occurred while uploading the sketch
Click to expand...

You'd have to try with that to see if you can get the same result - does that text seem like anything you saw on old machine? Anything interesting in the TeensyLoader LOG?

You could do a Ctrl+Alt+S build and Ctrl+K to get the sketch dir and close TeensyLoader and do repeated uploads with TyCommander of that HEX and see if it repeats without integrating it. Then close TyComm and repeat with TeensyLoader. If that never fails then the unchanging HEX might suggest a build or upload handoff issue? If that is intermittent then that's a different problem.
 
can I ask .. I know what ARM is about, but what is the meaning or importance of the "ARM Toolchain Update" ?
 
ninja2 said:
can I ask .. I know what ARM is about, but what is the meaning or importance of the "ARM Toolchain Update" ?
Click to expand...

The toolchain is the GCC compiler, GAS assembler, linker, and assorted other binary utilities.

The GCC compiler that normally ships with Teensydunio is 4.8.4. GCC 4.8.0 was released 4 years ago (2013-03-22). The 4.8.4 bug fixes to 4.8.0 was released 2+ years ago (2014-12-19). The GCC 4.8.x and 4.9.x releases are no longer maintained by the GCC developers.

After the 4.9.x version, GCC went to just using the major number to indicate the release. The current GCC 5.x release is 5.4 (2016-06-03). The current GCC 6.x release is 6.3 (2016-12-21). GCC 7.x is in stage4 right now, which means only bug fixes are being accepted.

So basically, it is putting in a newer compiler.
 
ninja2 said:
and where will teensyduino fit in that evolution (after 1.36)?
Click to expand...

No final decisions, and really not even much in the way of preliminary decisions, have been made beyond the 1.36 release.

I try to balance the need for a stable & consistent Teensy experience with the always-present desire to update to the latest software. For years we've been staying with gcc 4.8, mainly because so much else was in development.

Now it's time to update to 5.4.

Whether it will soon be time to upgrade beyond 5.4 remains to be seen. Sometimes newer releases only work well on x86 and the ARM chips used on certain Linux boards.

There is also a good chance the Teensy core library and many Arduino libraries have minor bugs which have never manifested under 4.8, but could cause cause problems under 5.4 or 6.x. We're already seeing several libs that fail with LTO enabled. My hope is to fix some or all of these before 1.36 releases, but either way, LTO will be available in the menu but not be the default.

Again, I'm trying to balance the need for a stable platform with occasionally updating so we can access newer compiler features and (maybe) better optimizations.
 
KurtE said:
Thought I would mention. This last week I purchased a new main Windows 10 64bit machine...

But I have a new install of Arduino 1.8.1 with Teensyduino 1.36beta1...
When I am doing builds example of the simple test program for shiftpwm, sometimes it gives the error message about problem rebooting the Teensy...
Click to expand...

KurtE: My repurposed AMD Win10 home box upgraded to Win10 PRO after 'resetting' off the prior owner twice. New First install of Arduino (1.8.1) and TD_1.36b1 using a Dell Monitor HUB to T_3.6. :: No Problem

I did maybe 60 Uploads of that ShiftPWM sketch - added a Serial.print and changed the text out line for about half.
Poor old 2011 8GB laptop won't die, 16GB and SSD 4*2 core AMD compiles much faster!
 
defragster: Yes this newer machine is working a lot nicer. My maybe 6 year old first generation i7 machine was acting real strange and the drive was having problems. I had already repleaced the USB 3 adapter as it had a .9 version which did not work well (especially on Logic Pro)... The CDRom drive would randomly open and close, and Arduino compiles were taking probably longer than when I compiled using a RPI3.... So it was time! But still figuring out this new machine.

Updated and removed...
The difference with LTO appears to be a problem in my test program that was overwriting an array. How this effected things was different depending on how compiled but was still just a simple memory corruption bug: :eek:
 
Last edited:
Status
Not open for further replies.
Back
Top