Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 26 to 50 of 52

Thread: Teensyduino 1.36 Beta #1 (ARM Toolchain Update)

  1. #26
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,086
    Quote Originally Posted by KurtE View Post
    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:
    Code:
    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.

  2. #27
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,022
    Quote Originally Posted by defragster View Post
    Just bringing it up because of this thread: Teensy-3-5-overclocking-(not-3-6)
    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.
    Attached Files Attached Files

  3. #28
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,022
    Quote Originally Posted by Frank B View Post
    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.

  4. #29
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,628

    Cool

    Quote Originally Posted by PaulStoffregen View Post
    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.


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

  5. #30
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,426
    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.

  6. #31
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,392
    Looks like a TYQT problem

  7. #32
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,086
    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 by defragster; 02-02-2017 at 04:45 PM.

  8. #33
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,426
    Thanks, that fixed it... After I unintegrated and reintegrated as exe renamed...

  9. #34
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,086
    Quote Originally Posted by PaulStoffregen View Post
    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.
    Last edited by defragster; 02-02-2017 at 05:25 PM.

  10. #35
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,022
    Quote Originally Posted by KurtE View Post
    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.

  11. #36
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,392
    Quote Originally Posted by PaulStoffregen View Post
    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.)
    Last edited by Frank B; 02-02-2017 at 10:01 PM.

  12. #37
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    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.

  13. #38
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,392
    - 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 by Frank B; 03-05-2017 at 10:23 PM.

  14. #39
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    Quote Originally Posted by Frank B View Post
    - 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:

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

  15. #40
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,022
    Quote Originally Posted by tni View Post
    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.

  16. #41
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,392
    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 :-)

  17. #42
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,426
    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... Click image for larger version. 

Name:	TeensynotReboot.jpg 
Views:	133 
Size:	63.6 KB 
ID:	9911

  18. #43
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,086
    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.

  19. #44
    Senior Member ninja2's Avatar
    Join Date
    Aug 2016
    Location
    Adelaide, Australia
    Posts
    151
    can I ask .. I know what ARM is about, but what is the meaning or importance of the "ARM Toolchain Update" ?

  20. #45
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,628
    Quote Originally Posted by ninja2 View Post
    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.

  21. #46
    Senior Member ninja2's Avatar
    Join Date
    Aug 2016
    Location
    Adelaide, Australia
    Posts
    151
    ah OK, and where will teensyduino fit in that evolution (after 1.36)?

  22. #47
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,392
    Teensyduino uses the toolchain.

  23. #48
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,392
    @Michael, the latest release for "our" Teensy is called "6 2017q1" ( https://developer.arm.com/open-sourc...olchain/gnu-rm )

  24. #49
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,022
    Quote Originally Posted by ninja2 View Post
    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.

  25. #50
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,086
    Quote Originally Posted by KurtE View Post
    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!

Posting Permissions

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