PDA

View Full Version : Teensyduino 1.36 Beta #1 (ARM Toolchain Update)



Paul
01-19-2017, 02:16 AM
Here is a first beta test for Teensyduino 1.36.


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


The only change since 1.35 is switching to the gcc 5.4 toolchain, which was briefly attempted with 1.34-beta1 (https://forum.pjrc.com/threads/40860-Teensyduino-1-34-Beta-1-(ARM-Toolchain-Update)) before an Arduino release forced reverting back to the old toolchain. With any luck we'll have time to throughly test.

The LTO (link time optimization) and the "Fastest" (-O3 optimizaton) may break some program or libraries. Please report anything you find which doesn't work.

defragster
01-19-2017, 04:36 AM
Saw this used elsewhere - does __attribute__((optimize("O1"))) show a way to control local optimizations that would work? On 1.34b1 I saw Zilch had an issue - though it may have been from the LTO rework after the compile. I adorned a couple functions in a simple sketch and it compiles and changes code size and works . . . not tested on a known fail case . . .


__attribute__((optimize("O3"))) void foo( ... )
{
}

PaulStoffregen
01-21-2017, 12:21 AM
Here's a list of the problems discovered from 1.34-beta1.


strncmpi and strcasestr no longer defined (https://forum.pjrc.com/threads/40860-Teensyduino-1-34-Beta-1-(ARM-Toolchain-Update)?p=127583&viewfull=1#post127583)
Audio FFT example doesn't work (https://forum.pjrc.com/threads/40860-Teensyduino-1-34-Beta-1-(ARM-Toolchain-Update)?p=127587&viewfull=1#post127587)
FreeRTOS frBlink example doesn't compile (https://forum.pjrc.com/threads/40860-Teensyduino-1-34-Beta-1-(ARM-Toolchain-Update)?p=127765&viewfull=1#post127765)
delayMicroseconds might be wrong with -O3 & LTO (https://forum.pjrc.com/threads/40860-Teensyduino-1-34-Beta-1-(ARM-Toolchain-Update)?p=127933&viewfull=1#post127933)
Audio library SamplePlayer example probably does not work with -O3 & LTO (https://forum.pjrc.com/threads/40860-Teensyduino-1-34-Beta-1-(ARM-Toolchain-Update)?p=128126&viewfull=1#post128126)


Libraries which might have compile errors:


Adafruit_CC3000 buildtest example
ks0108 error compiling
LowPower fails on all boards, even Teensy 2.0
PS2Keyboard errors
ST7565 error, C++ overload on srandom()

defragster
01-21-2017, 12:30 AM
I'll look at delayMicroseconds() after my 1.8.1 and 1.36 downloads finish and get installed. I'll test it against millis() and the T_3.5/3.6 manitou's RTC isr() and then if needed try the __attribute__((optimize("O1"))) [or "O2"] since that is a single function to test against.

defragster
01-21-2017, 04:14 AM
Quick test shows an elapsedMicros over 10 seconds behavior agrees with 10 sets of delayMicroseconds( 1000000 ) on 1.34 and 1.36.

Under 1.8.0 w/TD_1.34 and 1.8.1 w/TD1.36 - with and without the LTO and FASTEST.

I ran it in a for() so there is 13+ms over head that seems consistent enough.

defragster
01-21-2017, 05:02 PM
For those using TYQT on a Teensy before T_3.5 if you get failures to upload - you may need an updated version of TYQT after the toolchain update. I found this last year with beta of 1.34 and Koromix addressed it and it worked on my T_3.0 last night as noted in this linked post. (https://forum.pjrc.com/threads/27825-Teensy-Qt?p=130948&viewfull=1#post130948)

I didn't get a solid confirmation that the '__attribute__((optimize("O1"))) ' decoration on the delayMicroseconds() was working - since there was nothing to fix - and not looking at the ASM output I could only go by code size which for that single function change didn't seem different, it did compile.

NOTE: I noted before that when editing CORE files - where IDE used to force rebuild on each compile - now never seems to recompile with latest IDE's even when I edited the core_pins.h file, until forcing a full rebuild with a 'Tools' change.

Frank B
01-22-2017, 05:23 PM
I' playing with GCC 6, it has a some nice new features (https://gcc.gnu.org/gcc-6/changes.html) plus additions by ARM (https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads).
It works, but i had not the time to do any benchmarks - i wonder if the new "ARM PURECODE support for ARMv7-M" is helpful (-> faster code?) for the Teensies ?

PaulStoffregen
01-23-2017, 10:04 AM
I' playing with GCC 6, it has a some nice new [URL="https://gcc.gnu.org/gcc-6/changes.html"]i wonder if the new "ARM PURECODE support for ARMv7-M" is helpful (-> faster code?) for the Teensies ?

I'm curious about this too. But my guess is it'll be slower if multiple instructions are needed to create literals.

Wasn't there some option to specify different code generation for fast vs slow program/flash memory? Maybe that would make a difference, especially on 3.2 & 3.5 where there's very little cache for the flash memory.

Frank B
01-23-2017, 10:21 AM
I'm curious about this too. But my guess is it'll be slower if multiple instructions are needed to create literals.

Wasn't there some option to specify different code generation for fast vs slow program/flash memory? Maybe that would make a difference, especially on 3.2 & 3.5 where there's very little cache for the flash memory.

-mslow-flash-data ?

This should work with GCC5, too. I remember i did some tests, but the gain, if any, was very small.

KurtE
01-23-2017, 09:43 PM
Suggestion maybe put a quick summary of what these options are in the optimize menu. Like what is LTO...

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

duff
01-23-2017, 11:42 PM
Suggestion maybe put a quick summary of what these options are in the optimize menu. Like what is LTO...

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
I agree the optimization menu needs to be fixed, it really makes sense to have logical order to this especially when testing the libraries against different options?

Also is this the same toolchain build as 1.34? Now the pargma I was using "#pragma GCC optimize ("no-lto")" to disable LTO for certain code sections won't compile on this update and would for 1.34?

Snooze does not work with this build as of yet with both LTO and NO-LTO, don't know whats going on but there are problems.

Paul, is there any guidance on how you plan to proceed with this toolchain update? Are you planning on having all these optimization build options available to the user, why I ask is I don't want to spend a lot of time fixing things that won't be used anyway in the standard Teensyduino Arduino IDE update.

KurtE
01-25-2017, 02:32 PM
Yesterday in the SHT31 thread I mentioned, that it stopped working properly. I was finding that some of the SPI.endTransmission calls were failing with timeout (4)... Through looking at logic output on SCL/SDA, it appeared like the Stop bit was not done on the previous call to requestFrom... I put a hack into other library if I fail in the endTransmisison I do it again...
More in the thread: https://forum.pjrc.com/threads/41252-Cannot-communicate-with-teensy-3-6-i2c-to-an-adafruit-sht31d?p=131258&viewfull=1#post131258

I am quite sure this worked on previous toolchain...

I found if I went back to the released version of wire it worked... I checked my differences in these functions and the differences had to do with using a pointer to the I2C structure to get to the member variables like C1 and S instead of hard coded.

What was interesting was I then changed a couple of functions that I had as inline to not be inline... Removed #if 0 code here...


uint8_t TwoWire::i2c_status(KINETIS_I2C_t *kinetisk_pi2c)
{
return kinetisk_pi2c->S;
}

void TwoWire::i2c_wait(KINETIS_I2C_t *kinetisk_pi2c)
{
while (1) {
if ((i2c_status(kinetisk_pi2c) & I2C_S_IICIF)) break;
}
kinetisk_pi2c->S = I2C_S_IICIF;
}

And it started working.
I am using this Beta, T3.6 Fast

Will investigate more... Example not sure which of these two may have changed...

Update: No problem inline the i2c_status function, but inline of the wait causes the issue....

Frank B
01-25-2017, 05:58 PM
might be there's a "volatile" missing somewhere(, and the compiler thinks it is enough to read it once, and the "break" will never occur ?) - (inside i2c_status? - i did not read the code)

KurtE
01-25-2017, 07:49 PM
Thanks Frank,
The kinetisk_pi2c pointer is of type KINETIS_I2C_t which is defined in kenetis.h:


typedef struct {
volatile uint8_t A1;
volatile uint8_t F;
volatile uint8_t C1;
volatile uint8_t S;
volatile uint8_t D;
volatile uint8_t C2;
volatile uint8_t FLT;
volatile uint8_t RA;
volatile uint8_t SMB;
volatile uint8_t A2;
volatile uint8_t SLTH;
volatile uint8_t SLTL;
} KINETIS_I2C_t;

And as I mentioned the i2c_status function appears to work inline, which is the one it dereferences the pointer... I will try again and try looking at generated code, to see if I see anything obvious.

jeffreytcash
01-29-2017, 02:43 AM
Just wanted to let you know that when targeting Teensy 3.1/2, Snooze results in the following error only when using "Faster with LTO", "Fastest with LTO" and "Smallest Code with LTO":

mk20dx256.ld:45 cannot move location counter backwards (from 00000000000004a8 to 0000000000000400)
collect2: error: ld returned 1 exit status

It compiles successfully for the remaining 7 options for Teensy 3.1/2. When targeting Teensy 3.6, all 10 optimization options compile successfully. I find it odd that it works for some of the LTO options. To test this, I used the following sketch:


#include <Snooze.h>
SnoozeTimer timer;
SnoozeBlock config(timer);
void setup() {
timer.setTimer(1000);
}
void loop() {
(void)Snooze.sleep( config );
(void)Snooze.deepSleep( config );
(void)Snooze.hibernate( config );
}

duff
01-30-2017, 05:31 AM
Just wanted to let you know that when targeting Teensy 3.1/2, Snooze results in the following error only when using "Faster with LTO", "Fastest with LTO" and "Smallest Code with LTO":

mk20dx256.ld:45 cannot move location counter backwards (from 00000000000004a8 to 0000000000000400)
collect2: error: ld returned 1 exit status

Yes, I know this issue quite well, it's a problem with externed variable in the wake.h file. I wanted fix it but since I haven't heard from paul on the direction of this toolchain update its on the back-burner for now since this error is not consistent through the different compile options and-or Teensies.

Frank B
01-31-2017, 09:21 PM
mk20dx256.ld:45 cannot move location counter backwards (from 00000000000004a8 to 0000000000000400)
collect2: error: ld returned 1 exit status

A way that always works, is to edit the linker-file (attached). My edit moves the startup-code behind the flashconfig.
This wastes some 100 Bytes flash, but we have 1MB.

(just for the case you get this error, and need a quick way to fix it)

PaulStoffregen
01-31-2017, 09:31 PM
Would a noinline attribute fix this?

Frank B
01-31-2017, 09:40 PM
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 ?

defragster
02-01-2017, 06:48 PM
Frank- IIRC you ran your T_3.5's at (OC) speeds and found them to work? Would you suggest Paul might enable one or more T_3.5 OC speeds in this Beta/release?

Frank B
02-01-2017, 07:54 PM
Frank- IIRC you ran your T_3.5's at (OC) speeds and found them to work? Would you suggest Paul might enable one or more T_3.5 OC speeds in this Beta/release?

I think the 3.6 is the better choice than overclocking a 3.5
Next logical step is a CORTEX-M7 with twice the DMIPS/MHz.
I dont'k know, if NXP has a MCU that can be used.

KurtE
02-01-2017, 08:03 PM
Maybe we should a do for the T3.5 like we have for T3.1 and define some of the overclocked options for the T3.5, but leave the menu item entry for them commented out.

Yes T3.6 is nicer for higher speeds, but if you need/want 5v... then maybe should be put in as option, that the user can if desired try out

defragster
02-01-2017, 08:46 PM
Boards.txt already has them under comment - I tried 144 the other day - now gone after installing this beta.

Indeed running the T_3.6 at 240 is way cooler than OC on the T_3.5. But if it works? Maybe it isn't as reliable even for conditional OC support? Most of my time on T_3.5 was in beta when pushing it wasn't desired to assure KS release.

Just bringing it up because of this thread: Teensy-3-5-overclocking-(not-3-6) (https://forum.pjrc.com/threads/41853-Teensy-3-5-overclocking-(not-3-6)?p=132211#post132211)

KurtE
02-01-2017, 09:15 PM
Boards.txt already has them under comment - I tried 144 the other day - now gone after installing this beta.

Indeed running the T_3.6 at 240 is way cooler than OC on the T_3.5. But if it works? Maybe it isn't as reliable even for conditional OC support? Most of my time on T_3.5 was in beta when pushing it wasn't desired to assure KS release.

Just bringing it up because of this thread: Teensy-3-5-overclocking-(not-3-6) (https://forum.pjrc.com/threads/41853-Teensy-3-5-overclocking-(not-3-6)?p=132211#post132211)

I don't see any commented out ones in either my 1.8.0 with current released TD and 1.8.1 with this beta... They both look like:

teensy35.menu.speed.120=120 MHz
teensy35.menu.speed.96=96 MHz
teensy35.menu.speed.72=72 MHz
teensy35.menu.speed.48=48 MHz
teensy35.menu.speed.24=24 MHz
teensy35.menu.speed.16=16 MHz (No USB)
teensy35.menu.speed.8=8 MHz (No USB)
teensy35.menu.speed.4=4 MHz (No USB)
teensy35.menu.speed.2=2 MHz (No USB)
teensy35.menu.speed.120.build.fcpu=120000000
teensy35.menu.speed.96.build.fcpu=96000000
teensy35.menu.speed.72.build.fcpu=72000000
teensy35.menu.speed.48.build.fcpu=48000000
teensy35.menu.speed.24.build.fcpu=24000000
teensy35.menu.speed.16.build.fcpu=16000000
teensy35.menu.speed.8.build.fcpu=8000000
teensy35.menu.speed.4.build.fcpu=4000000
teensy35.menu.speed.2.build.fcpu=2000000

manmoi01
02-01-2017, 09:51 PM
Hello, this version when compiling with the option faster with LTO does not show any error when using the library https://github.com/orangkucing/analogComp/tree/teensy3, however it does not work in the teensy, all the other compile options work.

I am using arduino 1.8.1 for mac os x.

defragster
02-01-2017, 10:07 PM
I don't see any commented out ones in either my 1.8.0 with current released TD and 1.8.1 with this beta... They both look like:

teensy35.menu.speed.120=120 MHz
teensy35.menu.speed.96=96 MHz
...
teensy35.menu.speed.2.build.fcpu=2000000


opps ... TOO right Kurt - I suppose I did manually create one . . . it worked for what I did as I did it.

Commented versions would be a good first step unless there are regular issues where it would cause harm or distraction from undefined behavior.

PaulStoffregen
02-02-2017, 09:23 AM
Just bringing it up because of this thread: Teensy-3-5-overclocking-(not-3-6) (https://forum.pjrc.com/threads/41853-Teensy-3-5-overclocking-(not-3-6)?p=132211#post132211)

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.

PaulStoffregen
02-02-2017, 09:29 AM
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 ?

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.

MichaelMeissner
02-02-2017, 12:14 PM
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.

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.

https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Spec-Files.html#Spec-Files


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:



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

KurtE
02-02-2017, 03:20 PM
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:


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

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.

Frank B
02-02-2017, 03:40 PM
Looks like a TYQT problem

defragster
02-02-2017, 03:47 PM
That is a FIXED TyCommander Problem::

TyTools-0.8.0-100...___... (https://bintray.com/koromix/tytools/tytools/view#files)

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.

KurtE
02-02-2017, 04:00 PM
Thanks, that fixed it... After I unintegrated and reintegrated as exe renamed...

defragster
02-02-2017, 05:18 PM
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.

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.

PaulStoffregen
02-02-2017, 08:07 PM
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

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.

Frank B
02-02-2017, 09:26 PM
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.

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

tni
03-04-2017, 11:30 AM
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.

Frank B
03-05-2017, 10:19 PM
- 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)

tni
03-05-2017, 11:51 PM
- 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.
Chances are it simply exposes more bugs - there is quite a lot of code that relies on undefined behavior. Per the release notes (https://gcc.gnu.org/gcc-6/changes.html):


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

PaulStoffregen
03-06-2017, 05:39 PM
Is there a reason that '-std=gnu++0x' is used?

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.

Frank B
03-06-2017, 06:16 PM
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 :-)

KurtE
03-07-2017, 02:06 AM
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... 9911

defragster
03-07-2017, 02:44 AM
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

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.

ninja2
03-07-2017, 11:42 AM
can I ask .. I know what ARM is about, but what is the meaning or importance of the "ARM Toolchain Update" ?

MichaelMeissner
03-07-2017, 12:04 PM
can I ask .. I know what ARM is about, but what is the meaning or importance of the "ARM Toolchain Update" ?

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
03-07-2017, 08:17 PM
ah OK, and where will teensyduino fit in that evolution (after 1.36)?

Frank B
03-07-2017, 08:33 PM
Teensyduino uses the toolchain.

Frank B
03-07-2017, 09:35 PM
@Michael, the latest release for "our" Teensy is called "6 2017q1" ( https://developer.arm.com/open-source/gnu-toolchain/gnu-rm )

PaulStoffregen
03-08-2017, 11:06 PM
and where will teensyduino fit in that evolution (after 1.36)?

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.

defragster
03-09-2017, 05:51 AM
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...

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!

KurtE
03-10-2017, 03:49 PM
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: :o

ahpuck
05-03-2017, 09:26 PM
I definitely had some issues with the "Fastest" optimize option and a larger code base of ours. We mainly use the OctoWS2811 library but I had significant issues with some fades between LED colors. Once I switched back to the "Fast" or "Smallest Code" option everything performed as expected. I'm happy to help debug it a little more but I wasn't sure where to start and a colleague of mine needed to get our board out the door so I didn't test much after everything was functional.

To note I tried Arduino 1.6.13, 1.8.1, 18.2 using Teensyduino 1.36