Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 5 1 2 3 ... LastLast
Results 1 to 25 of 108

Thread: Teensyduino 1.58 Beta #2

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

    Teensyduino 1.58 Beta #2

    Here is a second beta test for Teensyduino 1.58.

    Continuing to test gcc toolchain 11.3.1. Many libraries updated for compile errors, but lots of new compiler warnings remains. The addr2line issue remains unresolved. Arduino CLI issue #1782 needs investigation.

    Automatic creation of a .lst file has been restored. Testing needed to determine if it has acceptable speed on huge output, like Defragster's large test.

    teensy_secure has some openssl fat trimmed. Hopefully malwarebytes will be happier?


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

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

    IDE 2.0: Windows & Linux64 updated for boards manager


    Changes since Teensyduino 1.58-beta1:

    TODO...
    Last edited by KurtE; 09-11-2022 at 07:23 PM. Reason: 157->158

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    11,121
    Looks like wrong links ... 157 instead of 158, will edit.

    Edit: Done

  3. #3
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,470
    Windows IDE 2-rc 9.4
    2 tiny sketches built and uploaded - and big Code4Code - having to use Button?
    Code:
    Tool teensy:teensy-compile@11.3.1-beta1 already installed
    Tool teensy:teensy-discovery@1.57.0 already installed
    Tool teensy:teensy-monitor@1.57.0 already installed
    Downloading packages
    teensy:teensy-tools@1.58.0-beta2
    teensy:avr@1.58.0-beta2
    Installing teensy:teensy-tools@1.58.0-beta2
    teensy:teensy-tools@1.58.0-beta2 installed
    Replacing platform teensy:avr@1.58.0-beta1 with teensy:avr@1.58.0-beta2
    Uninstalling teensy:avr@1.58.0-beta1
    Platform teensy:avr@1.58.0-beta1 uninstalled
    Uninstalling teensy:teensy-compile@11.3.1-beta1, tool is no more required
    Uninstalling teensy:teensy-tools@1.58.0-beta1, tool is no more required
    Tool teensy:teensy-tools@1.58.0-beta1 uninstalled
    Uninstalling teensy:teensy-discovery@1.57.0, tool is no more required
    Uninstalling teensy:teensy-monitor@1.57.0, tool is no more required
    Configuring platform.
    Platform teensy:avr@1.58.0-beta2 installed

  4. #4
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,465
    Install for both IDE2 and IDE1.8.19 on a windows PC went fine.

    Ran a couple of test cases including one of my TeensyOpenGL examples, latest MTP changes and keyboard_viewer with no errors or warning for the new compiler.

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,470
    @Paul: it 'seems' that with multiple IDE 2 sketch windows open - in Windows:
    > Having SerMon open on sketch #1, that building on sketch #2 results in:
    Code:
    Unable to open COM22 for reboot request
      Windows Error Info: Access is denied.
      more ideas... https://forum.pjrc.com/threads/40632?p=126667&viewfull=1#post126667
    Teensy did not respond to a USB-based request to enter program mode.
    Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.
    This is why the Button has been needed?

    It seems the these copies/instances are not in touch with each other regarding the Serial device?

    PROBLEM WAS: One sketch had Teensy on "Serial ports: Com22" and the other on "Teensy ports: Com22"

    Can this be detected across 'instances' polling all the 'serial' users?

    Note: With sketch #2 using Tports:22 same problem in sketch one using Sports:22 > Button needed

    Ref notes:
    > alternate SerMon 'ports' owners was not on purpose
    > multiple 'instances' WAS on purpose: Allows IDE code window full size and second instance to have SerMon also full size.
    Last edited by defragster; 09-11-2022 at 09:32 PM.

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,470
    Quote Originally Posted by Paul View Post
    Here is a second beta test for Teensyduino 1.58.
    ...
    Automatic creation of a .lst file has been restored. Testing needed to determine if it has acceptable speed on huge output, like Defragster's large test.
    ...
    Building the github.com/Defragster/T4LockBeta/tree/main/Code4Code no longer seems to hang build for LONG time - in fact just seconds seem to pass on the .lst line.

    Code:
    teensy_size: Memory Usage on Teensy 4.1:
    teensy_size:   FLASH: code:1213928, data:328064, headers:8340   free for files:6576132
    teensy_size:    RAM1: variables:83360, code:45416, padding:20120   free for local variables:375392
    teensy_size:    RAM2: variables:12384  free for malloc/new:511904
    "C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta2/stdout_redirect" "R:\\temp\\arduino_build_Code4Code.ino/Code4Code.ino.lst" "C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-compile\\11.3.1-beta1/arm/bin/arm-none-eabi-objdump" -d -S -C "R:\\temp\\arduino_build_Code4Code.ino/Code4Code.ino.elf"
    Odd thing is the long compile of the unchanged sketch sources always repeats - but same on 1.8.19 and ide 2? Doesn't rebuild the rest?

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,470
    Beta 1.58b2 install on Win10 laptop - will post on ide2 thread too

    Started OLD IDE 2 - offered 9.4RC update - done and restarted
    Saw and offered Teensy 1.58b1 update - Done, no restart

    Teensy Ports not available with T_4.1 plugged in, hit Button and still no Teensy ports

    Restarted IDE and then T_4.1 on Teensy ports as Button HID
    > build and upload completed

    Tports SerMon worked online
    > Rebuild and SerMon does not restart. Requires SerMon Toggle Off/On to get Serial Output connected

  8. #8
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    11,121
    WARNING: there were a couple of updates to the USBHost code with this beta.

    One was to make the keyboard objects no longer top level objects, but more like Mouse where it always goes through a HIDParser for it's inputs and outputs.
    The code was extended to support more N-key rollover keyboards, like the Gigabyte from before.

    This removed the need for this keyboard and hopefully others to not need to be forced into BOOT keyboard format.

    However, I screwed up some and had the Keyboard HID Claim code in the USBHost code and it was grabbing reports meant for Joysticks and Mice. So they are not working very well
    if your sketch also has one or more Keyboard objects in it.

    I have fix for it, that appears to be working better: I have tried it with a few devices now:
    Gigabyte K83 - the original problem child (still causes other issues)
    ReDragon K552 - newer N key rollover keyboard
    Logitech wireless combination K350 M705
    Logitech Pro G wireless mouse
    Sony PS3 controller (plugged in)
    Did not test the Bluetooth stuff yet, as none of that changed.

    Pull Request: https://github.com/PaulStoffregen/USBHost_t36/pull/98
    From new branch: https://github.com/KurtE/USBHost_t36...nt_claim_mouse

  9. #9
    I compiled my largest program for the Teensy (GEVCU7) with the new beta and it compiles and seems to run fine. There are a whole boatload of warnings, many of which I had before and just haven't gotten all patched up yet. But, I don't entirely understand this one:

    Code:
    In file included from /home/collin/Desktop/ArduinoTestTeensyBeta/arduino-1.8.19/hardware/tools/arm/arm-none-eabi/include/c++/11.3.1/vector:67,
                     from /home/collin/projects/GEVCU7/src/DeviceManager.h:29,
                     from /home/collin/projects/GEVCU7/src/DeviceManager.cpp:38:
    /home/collin/Desktop/ArduinoTestTeensyBeta/arduino-1.8.19/hardware/tools/arm/arm-none-eabi/include/c++/11.3.1/bits/stl_vector.h: In member function 'void DeviceManager::addStatusEntry(StatusEntry)':
    /home/collin/Desktop/ArduinoTestTeensyBeta/arduino-1.8.19/hardware/tools/arm/arm-none-eabi/include/c++/11.3.1/bits/stl_vector.h:1198:28: note: parameter passing for argument of type '__gnu_cxx::__normal_iterator<StatusEntry*, std::vector<StatusEntry> >' changed in GCC 7.1
     1198 |           _M_realloc_insert(end(), __x);
          |           ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
    It's merely a warning but seems to be about how parameter passing changed in GCC 7.1. Searching on the internet says that this warning is because there was a subtle change between GCC6 and 7 and if you mix code compiled with GCC prior to 7.1 with code compiled with a newer compiler it could cause weird things to happen. If all code is compiled >= 7.1 then you can set this warning to not show with -Wno-psabi

    So, it's probably OK to make that the default for Teensy code from now on. Otherwise people using standard library container stuff might run into this as I did.

  10. #10
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,470
    Quote Originally Posted by CollinK View Post
    I compiled my largest program for the Teensy (GEVCU7) with the new beta and it compiles and seems to run fine. There are a whole boatload of warnings, many of which I had before and just haven't gotten all patched up yet. But, I don't entirely understand this one:
    ...
    Not sure this adds anything - but found this example showing a 'similar' usage example with the value_type as used: krshrimali.github.io/posts/2020/04/understanding-how-vectors-work-in-c-part-1-how-does-push_back-work/

    Code:
    // Note that value_type is defined as: typedef _Tp value_type as a public type
    void push_back(const value_type& __x)
    {
        if (this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
        { ...  }
        else
            _M_realloc_insert(end(), __x);
    }

  11. #11
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,465
    @Paul = @brtaylor

    Was running the example sketch from @brtaylor Eigen library: https://github.com/bolderflight/eigen. Looking at errors all are related to wiring.h which defines abs and round instead of using the defines in std lib. Turns out this is the same thing identified in the Compile issue with different ARM Cortex-M0+ boards. Commenting out all the abs lines as well round allows Eigen to compile without any issue.

    Can issue a PR for T4 and T3 libraries.

    NOTE: this change would fix all the errors in the @brtaylor's ublox library as well.

  12. #12
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Santa Fe, NM
    Posts
    800
    Thanks for tagging me on GitHub Mike, normally don't follow the beta releases posts. What's the issue with the uBlox library?

  13. #13
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,465
    Quote Originally Posted by brtaylor View Post
    Thanks for tagging me on GitHub Mike, normally don't follow the beta releases posts. What's the issue with the uBlox library?
    Not a problem on the github tag.

    Oh - it had the same issue as the Eigen library with having abs and round defined in wiring.h with the new toolchain. Once abs and round were commented out in wiring.h the Ublox errors get cleared as well. Guess no one ran across that with an updated toolchain yet.

    EDIT: Forgot to mention not sure if other libraries will have issues only tested those 2 so far.

  14. #14
    This may be slightly off topic but I don't remember seeing this warning until these betas of 1.58 so I suspect this warning is due to the newer compiler. Problem is, it makes no sense at all.

    Here is the code in question:
    Code:
    void DeviceManager::handleTick()
    {
        double currVal = 0.0;
        for (std::vector<StatusEntry>::iterator it = statusEntries.begin(); it != statusEntries.end(); ++it) 
        {
            currVal = it->getValueAsDouble();
            if ( fabs(currVal - it->lastValue) > 0.001) //has the value changed?
            {
                Logger::avalanche("Value of %s has changed", it->statusName.c_str());
                dispatchToObservers(*it);
                it->lastValue = currVal;
            }
        }
    }
    So, basically I'm just using an iterator to go through a bunch of entries and seeing if they have changed since the last update cycle. The warning I get is:
    Code:
    /home/collin/projects/GEVCU7/src/DeviceManager.cpp:239:27: warning: 'out' may be used uninitialized in this function [-Wmaybe-uninitialized]
      239 |         if ( fabs(currVal - it->lastValue) > 0.001) //has the value changed?
          |                   ~~~~~~~~^~~~~~~~~~~~~~~
    In this case, you can see that line 239 is the line with fabs. The problem is, as you can see, there IS NO VARIABLE NAMED "out". There isn't a variable named out in the entire source file. I don't think there is a variable named out anywhere in the entire code base. Am I blind? Is this a compiler bug? Is there some valid explanation for this behavior? I really don't think that turning off this warning is appropriate. It's certainly a useful warning to have. But, I don't understand how this makes any sense.

  15. #15
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,470
    Quote Originally Posted by CollinK View Post
    ...
    In this case, you can see that line 239 is the line with fabs. The problem is, as you can see, there IS NO VARIABLE NAMED "out". There isn't a variable named out in the entire source file. I don't think there is a variable named out anywhere in the entire code base. Am I blind? Is this a compiler bug? Is there some valid explanation for this behavior? I really don't think that turning off this warning is appropriate. It's certainly a useful warning to have. But, I don't understand how this makes any sense.
    If it is a new warning it is interesting to see what pops up.

    It seems 'out' - in single quotes - is meaning generic ref to a return value? Perhaps it is not trusting "it->lastValue" to be known/valid?

  16. #16
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    11,121
    Maybe where is fabs defined? Maybe a macro and or inline function?

  17. #17
    Senior Member
    Join Date
    Sep 2021
    Posts
    160

  18. #18
    Senior Member
    Join Date
    Sep 2021
    Posts
    160
    For sure this is not the version used by the compiler - but it is unlikeley that the code changed and that they changed a variable (or whatever) name: https://sourceware.org/git/?p=newlib...eb0c35;hb=HEAD
    (and the compiler uses a compiled lib *.a, not the sourcecode)

    I'd say the displayed line number is just wrong. Has nothing to do with fabs().
    Well, or fabs get overwritten somewhere. If that's the case, it's bad programming.

  19. #19
    1.58 Beta #2 has no issues on anything I am working on, (using 2.0.0 now) although that is not exhaustive regression analysis.
    I am trying to understand why, when I do a verify/compile the programmer window pops open at the end of compilation?
    Is this related to the Teensyduino coding, or something in the IDE itself?
    I know this seems like a small thing, but being the A-R type that I am, I keep closing it instead of it "cluttering" my workspace.

    - Wes, W5ZZO

  20. #20
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,465
    Quote Originally Posted by CollinK View Post
    This may be slightly off topic but I don't remember seeing this warning until these betas of 1.58 so I suspect this warning is due to the newer compiler. Problem is, it makes no sense at all.

    Here is the code in question:
    ....

    So, basically I'm just using an iterator to go through a bunch of entries and seeing if they have changed since the last update cycle. The warning I get is:
    Code:
    /home/collin/projects/GEVCU7/src/DeviceManager.cpp:239:27: warning: 'out' may be used uninitialized in this function [-Wmaybe-uninitialized]
      239 |         if ( fabs(currVal - it->lastValue) > 0.001) //has the value changed?
          |                   ~~~~~~~~^~~~~~~~~~~~~~~
    In this case, you can see that line 239 is the line with fabs. The problem is, as you can see, there IS NO VARIABLE NAMED "out". There isn't a variable named out in the entire source file. I don't think there is a variable named out anywhere in the entire code base. Am I blind? Is this a compiler bug? Is there some valid explanation for this behavior? I really don't think that turning off this warning is appropriate. It's certainly a useful warning to have. But, I don't understand how this makes any sense.
    Rough guess is maybe it->lastValue isn't initialized - maybe defalut set it up to
    Code:
    it->getValueAsDouble();
    on code begin someplace.

  21. #21
    Quote Originally Posted by mjs513 View Post
    Rough guess is maybe it->lastValue isn't initialized - maybe defalut set it up to
    Code:
    it->getValueAsDouble();
    on code begin someplace.
    First of all, I was wrong. The 1.57 version of Teensyduino gives the same warning so this isn't new... Whoops.

    I tried many things to fix it. It doesn't go away. It works perfectly fine so I guess I'm just going to ignore the warning and forget about it. I know for a fact that the struct is initialized when I'm using it so that's really what counts.

  22. #22
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,465
    Quote Originally Posted by CollinK View Post
    First of all, I was wrong. The 1.57 version of Teensyduino gives the same warning so this isn't new... Whoops.

    I tried many things to fix it. It doesn't go away. It works perfectly fine so I guess I'm just going to ignore the warning and forget about it. I know for a fact that the struct is initialized when I'm using it so that's really what counts.
    It was worth a shot -- you got me on what that warning is then. But still curious.

  23. #23
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,042
    Quote Originally Posted by W5ZZO View Post
    I am trying to understand why, when I do a verify/compile the programmer window pops open at the end of compilation?
    Teensy has long supported 2 ways of uploading. Automatic upload where your PC sends a USB message to Teensy asking it to go into programming mode, and manual upload where you press the pushbutton on Teensy. The Teensy Loader window has to be running and set to Auto mode for the manual pushbutton method to work.

    The automatic way is only 100% reliable with boards like Arduino Uno which have a dedicate USB-Serial chip. Even then, it depends on your PC's drivers working properly and no software issues like multiple programs attempting to access the same device. Teensy is native USB. The ability to receive and respond to the request to enter programming mode depends on whether your code is still running properly. Shutting off interrupts or lingering in a low power mode or any number of other software problem with your program can interfere.

    This is the reason why every Teensy has a pushbutton dedicated to entering programming mode, and Teensy Loader runs and it placed in Auto mode when you use Verify. If something has gone wrong with the code on Teensy, this is the only 100% reliable way to recover.

  24. #24
    Hey everyone,

    after installing the IDE 2.0 ive seen that the sketch now takes a bit more space in the program storage space, than in the last version 1.8.19.
    you can find my code at https://github.com/steven-law/Teensy...stepTeensyDAW3
    the only lib that comes not from Paul is the 15steplibrary found here: https://github.com/adafruit/FifteenStep
    other libs: #include <Audio.h>
    #include <Wire.h>
    #include <SerialFlash.h>
    #include <ILI9341_t3.h>
    #include <font_Arial.h> // from ILI9341_t3
    #include <XPT2046_Touchscreen.h>
    #include <SPI.h>
    #include <SD.h>


    Ive used version 1.58 beta 2.
    Paul mentioned to switch to 1.57, which more or less gave me the same storage amount needed like in IDE 1.8.19.

    IDE 1.8.19
    141 296 bytes program storage space
    42476 bytes dynamic memory


    IDE 2.0 + 1.57
    140 848 bytes
    42476 bytes

    IDE 2.0 + 1.58 beta 2
    151 376 bytes
    42552 bytes

    If you need any further details just let me know

  25. #25
    Quote Originally Posted by degu234 View Post
    after installing the IDE 2.0 ive seen that the sketch now takes a bit more space in the program storage space, than in the last version 1.8.19. If you need any further details just let me know
    What version of TeensyDuino are you using with IDE 1.8.19? So far in my own testing (only with 1.57), I get identical hex files with IDE 1.8.19 and IDE 2.0.0.

Posting Permissions

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