Teensyduino 1.58 Beta #2

Paul

Paul

Administrator
Staff member
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-beta2/TeensyduinoInstall.linux64

Windows:
https://www.pjrc.com/teensy/td_158-beta2/TeensyduinoInstall.exe

IDE 2.0: Windows & Linux64 updated for boards manager


Changes since Teensyduino 1.58-beta1:

automatically create .lst file after linking
include time.h with Arduino.h
fix FNET on gcc 11
update MFRC522
fix Snooze errors with gcc 11
update TeensyThreads
USBHost_t36 bluetooth and HID improvements (KurtE)
 
Last edited by a moderator:
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
 
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.
 
@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:
Paul said:
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.
...
Click to expand...

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/[B]Code4Code.ino.lst"[/B] "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?
 
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
 
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/tree/keyboard_dont_claim_mouse
 
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.
 
CollinK said:
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:
...
Click to expand...

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);
}
 
@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.
 
Thanks for tagging me on GitHub Mike, normally don't follow the beta releases posts. What's the issue with the uBlox library?
 
brtaylor said:
Thanks for tagging me on GitHub Mike, normally don't follow the beta releases posts. What's the issue with the uBlox library?
Click to expand...

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.
 
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.
 
CollinK said:
...
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.
Click to expand...

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?
 
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=newli...89ef06962a9615ef65fa3c6a77dcf96eb0c35;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.
 
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
 
CollinK said:
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.
Click to expand...

Rough guess is maybe it->lastValue isn't initialized - maybe defalut set it up to
Code: 
it->getValueAsDouble();

on code begin someplace.
 
mjs513 said:
Rough guess is maybe it->lastValue isn't initialized - maybe defalut set it up to
Code: 
it->getValueAsDouble();

on code begin someplace.
Click to expand...

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.
 
CollinK said:
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.
Click to expand...

It was worth a shot -- you got me on what that warning is then. But still curious.
 
W5ZZO said:
I am trying to understand why, when I do a verify/compile the programmer window pops open at the end of compilation?
Click to expand...

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.
 
Hey everyone,

after installing the IDE 2.0 i´ve 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-DAW/tree/main/15stepTeensyDAW3
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>


I´ve 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 :)
 
degu234 said:
after installing the IDE 2.0 i´ve 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
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top