Teensyduino 1.58 Beta #4

Paul

Paul

Administrator
Staff member
Here is a fourth beta test for Teensyduino 1.58. This one is meant to be a quick final test before 1.58 release.

Arduino 2.0.x, all systems platforms:
use Boards Manager to install Teensy version 0.58.4
(to refresh versions, Shift-Ctrl-P and click "Arduino: Update Package Index")

Arduino 1.8.x, Linux 32 bit:
https://www.pjrc.com/teensy/td_158-beta4/TeensyduinoInstall.linux32

Arduino 1.8.x, Linux 64 bit:
https://www.pjrc.com/teensy/td_158-beta4/TeensyduinoInstall.linux64

Arduino 1.8.x, Linux ARM:
https://www.pjrc.com/teensy/td_158-beta4/TeensyduinoInstall.linuxarm

Arduino 1.8.x, Linux ARM64:
https://www.pjrc.com/teensy/td_158-beta4/TeensyduinoInstall.linuxaarch64

Arduino 1.8.x, MacOS (Catalina to Ventura)
https://www.pjrc.com/teensy/td_158-beta4/Teensyduino_MacOS_Catalina.zip

Arduino 1.8.x, Old MacOS (Mojave)
https://www.pjrc.com/teensy/td_158-beta4/TeensyduinoInstall.dmg

Arduino 1.8.x, Windows:
https://www.pjrc.com/teensy/td_158-beta4/TeensyduinoInstall.exe

PlatformIO, DIY beta support:
https://forum.pjrc.com/threads/71730


Changes since Teensyduino 1.58-beta3:

Improve String support for 64 bit integers
Allow programs to override gettimeofday (Shawn Silverman)
Improve bare (without Serial, Serial1, File) printf() support
Handle null pointer gracefully in Serial.write(string)
Fix Serial.write() return value (Shawn Silverman)
Fix IntervalTimer end() when timer interrupt pending
Speed up HardwareSerial FIFO size calculation (Shawn Silverman)
Fix startup with -Os and -Og optimization
Allow programs to override sbrk (Timo Sandmann)
Stream String readStringUntil() default to allow unlimited length
Define WIRE_INTERFACES_COUNT for Arduino compatibility
Fix TIMSEL field width in FlexIO SHIFTCTL register (squidcc)
Allow SdVolume to access card, but with deprecated warning
Fix compiler warnings with -Wextra (Shawn Silverman)
Change Print::write_error for Arduino compatibility (Shawn Silverman)
Call yield() from second/third USB serial bool (Geert Uytterhoeven)
Audio design tool fix import with AudioEffectDelayExternal (Jonathan Oakley)
Audio design tool import space objects for better visibility (Jonathan Oakley)
Audio tutorial examples updated for Teensy 4.0
Aduio examples updated with comments for Teensy 4 hardware
USBHost_t36 fix compiler warnings
USBHost_t36 improve startup on USB disks (Warren Watson)
USBHost_t36 fix USB disks endpoint issue (jmarsh)
USBHost_t36 fix Ant+ infinite loop (Gbertaz)
USBHost_t36 fix compiler warning (Jonathan Oakley)
USBHost_t36 support more Xbox One controllers (Dave Madison)
USBHost_t36 support CP2105 USB serial (jammerx19)
ILI9488_t3 support multiple displays (mjs513)
ILI9488_t3 update Digitizer4 example (KurtE)
LittleFS fix FRAM on alternate SPI ports (mjs513)
RA8875 fix fft_example2 example
WS2812Serial Remove 400 Hz refresh rate limit
XPT2046_Touchscreen further document alternate SPI ports
Linux warning if 00-teensy.rules missing
 
Last edited:
Windows 11:
Ran installer on 1.8.19 and all went well.
Built COREMARK to a T_4.1 no issue: "CoreMark 1.0 : 2407.90 / GCC11.3.1 20220712 (flags unknown) / STACK"

Opened IDE 2.0.4 and did Board update to 0.58.4 no problem.
Built COREMARK to a T_4.1 no issue: "CoreMark 1.0 : 2401.54 / GCC11.3.1 20220712 (flags unknown) / STACK"

For this test the IDE's SerMon worked well enough to build / upload / view. {with known exception of IDE 2.0.4 not scrolling to last new text}

Still shows some speed disparity loading the HEX files on the same T_4.1 in turn. Seems number off a few ticks on both since last report.

RE Tick count> from Teensyduino-1-58-Beta-3
"#2a: IDE 1.8.19 Build on 1062's always reports coremark #==2408.09
#2b: IDE 2.0.3 Build on 1062's always reports coremark #== 2406.93"
 
Also from b3 notes {near here}

Plug in a T_4.0 - in addition to T_4.1:
As p#2 build coremark for T_4.1 selected in IDE 1.8.19: Upload no problem.

As p#2 build coremark for T_4.1 selected in IDE 2.0.4:
Teensy.exe Loader presents error: CoreMark.ino.hex is not compiled for this board
The T_4.0 RED LED is lit in bootloader and noted as 'This board'
The T_4.1 appears to be powered and unaffected.
>> IDE 2 seems to have a logic error getting to the USB for T_4.1 and confuses to the T_4.0 port
 
Installed on windows 10 x64 no issue with IDE
Code: 
Version: 2.0.5-nightly-20230311
Date: 2023-03-11T03:07:12.638Z
CLI Version: 0.31.0

Install output
Code: 
Tool teensy:teensy-discovery@1.57.2 already installed
Tool teensy:teensy-monitor@1.57.2 already installed
Downloading packages
teensy:teensy-tools@0.58.4
teensy:teensy-compile@11.3.1
teensy:avr@0.58.4
Installing teensy:teensy-tools@0.58.4
Configuring tool.
teensy:teensy-tools@0.58.4 installed
Installing teensy:teensy-compile@11.3.1
Configuring tool.
teensy:teensy-compile@11.3.1 installed
Replacing platform teensy:avr@0.58.3 with teensy:avr@0.58.4
Uninstalling teensy:avr@0.58.3
Platform teensy:avr@0.58.3 uninstalled
Uninstalling teensy:teensy-compile@11.3.1, tool is no more required
Uninstalling teensy:teensy-tools@0.58.3, tool is no more required
Tool teensy:teensy-tools@0.58.3 uninstalled
Uninstalling teensy:teensy-discovery@1.57.2, tool is no more required
Uninstalling teensy:teensy-monitor@1.57.2, tool is no more required
Configuring platform.
Platform teensy:avr@0.58.4 installed
 
Installed W11 using IDE 2 todays nightly build.

Ran a couple of tests. So far so good!

Will try on Ubuntu although I think my hard on that machine is toast and/or the install is.
 
Installed 0.58.4 fine on M2 MacBook Air with Ventura and IDE 2.0.4.

On MacOS Catalina with IDE 2.0.4 can't get 0.58.4 to show up. Did the shift-apple-P and can see the new date modified on 'package_teensy_index.json' in finder but looking at file it's not updated. File is 874 lines, not 954.
 
bicycleguy said:
Installed 0.58.4 fine on M2 MacBook Air with Ventura and IDE 2.0.4.

On MacOS Catalina with IDE 2.0.4 can't get 0.58.4 to show up. Did the shift-apple-P and can see the new date modified on 'package_teensy_index.json' in finder but looking at file it's not updated. File is 874 lines, not 954.
Click to expand...

(on Windows) IDE 2 was already open here and didn't see it at first glance so closed IDE 2.0.4 and then looking at Teensy boards after restart it was there near the bottom over 0.58.2 as 0.58.3 was missing from list - perhaps as it was currently installed.
 
Please forgive me for being a broken record, and I acknowledge you've likely seen this PR and are likely still deciding what to do, but I think this particular fix is important to restore `yield()` to its behaviour before my LTO "fix". (It was actually an attempt that I didn't get right because of certain GCC behaviour I was unaware of.)

First, the PR: https://github.com/PaulStoffregen/cores/pull/682
Basically, it marks the `_serialEvent_default` variable definition as `extern` because without it, there's more than one copy. I've tested this fact and confirmed that `yield()` (yield.cpp) is using one copy and the definition (serialEvent.cpp) is using another. (Thanks to @tsandmann for pointing this out.)

The original LTO "fix" is here: https://github.com/PaulStoffregen/cores/pull/672
The issue is here: https://github.com/PaulStoffregen/cores/issues/681

I'd hate for my so-called LTO "fix" to be responsible for any `yield()` behaviour changes. I don't think there's a big problem, _in theory_, with that change (PR 672) because it just changes some variables to `const` and adds `extern`, but the compiler makes two copies of the variable unless both are marked as `extern`. I suppose a second option is to revert PR 672, and then deal with LTO later, as you pointed out in this Teensy 4.1 optimization thread.

Anyways... feel free to disagree, but I felt it was important to mention. Apologies for the hassle.

Thank you for the new beta release!
 
shawn said:
...
LTO "fix" ...
Anyways... feel free to disagree, but I felt it was important to mention. Apologies for the hassle.

Thank you for the new beta release!
Click to expand...

Noticed that LTO not returned to installed list of 'Tool / Optimize:' options for T_4.1. Would need that restored to actively use.
 
defragster said:
(on Windows) IDE 2 was already open here and didn't see it at first glance so closed IDE 2.0.4 and then looking at Teensy boards after restart it was there near the bottom over 0.58.2 as 0.58.3 was missing from list - perhaps as it was currently installed.
Click to expand...
Yah, that was not the problem. As stated the 'package_teensy_index.json' file is not the latest on old macs for some reason. It updated fine from 0.58.1 to 0.58.2 to 0.58.3. If I remove the file from /Users/me/Library/Arduino15 and do the 'Arduino update package index' I will get a new 'package_teensy_index.json' file identical to the one removed and text searching it has six places with 0.58.3 and no 0.58.4 as my M2 machine has. Maybe some security issue since I have messed with making my machines more secure.
 
I have no idea why Arduino 2.0.4 isn't updating the package index on those old macs, but I'm pretty sure there's nothing I can do about it. Recommend giving it overnight to maybe right itself automatically... before reporting it to the Arduino developers.
 
defragster said:
Noticed that LTO not returned to installed list of 'Tool / Optimize:' options for T_4.1. Would need that restored to actively use.
Click to expand...

The fix in PR 682 doesn't address LTO builds. It addresses an issue that was introduced by PR 672 for _all_ builds, including for non-LTO builds. This is the important detail. Right now, even without building with LTO, the `yield()` behaviour has changed because there's now two copies of `_serialEvent_default` and `yield()` does not reference the correct one defined in serialEvent.cpp. In other words, even though `_serialEvent_default` is defined as '1' in serialEvent.cpp, `yield()` sees a value of `0` (actually, technically a value of "undefined").

This is because of a GCC issue.

Summary: `yield()` behaviour technically changed with PR 672 for all builds, including non-LTO builds.
 
I spent some time fiddling with LTO last night. It's far too broken to enable in the Arduino menu for a stable release.

Also looked at the serialevent and yield optimization. It is indeed confusing. Long term, we probably shouldn't be making so much use of weak symbols. The yield optimization should (probably) be simpler. But right now, what matters is a stable release with serialevent working. Unless there's a serious bug impacting functionality (not performance) of yield or serialevent, the less than ideal code we have now is going into 1.58 as-is.

Shortly after 1.58 release, we'll start 1.59 beta with C++17 dialect and LTO in the menu.

Also early in 1.59 betas, I want to get a lamba-friendly function pointer (non owning) callback class into EventResponder and attachInterrupt, and then look at merging Jonathan Oakley's EventResponder-based SD card WAV file playing.

But right now, stable 1.58 release is the goal. Minor internal changes that don't actually break yield or serialevent aren't getting reworked at the 11th hour. At this point, anything that isn't a bug normal users could encounter will get addressed in 1.59.
 
PaulStoffregen said:
Also looked at the serialevent and yield optimization. It is indeed confusing. Long term, we probably shouldn't be making so much use of weak symbols. The yield optimization should (probably) be simpler. But right now, what matters is a stable release with serialevent working. Unless there's a serious bug impacting functionality (not performance) of yield or serialevent, the less than ideal code we have now is going into 1.58 as-is.
Click to expand...

Ok, it sounds like `_serialEvent_default` being zero inside `yield()` isn't a problem, then? To confirm, this line of code, as it stands right now, won't execute (without adding `extern` to the `_serialEvent_default` definition in serialEvent.cpp, per what broke in PR 672) (PR 682 fixes this):
Code: 
if (_serialEvent_default) yield_active_check_flags &= ~YIELD_CHECK_USB_SERIAL;

If that isn't a problem and this doesn't break serialevent, then cool. :)
(But it feels like serialevent functionality is impacted. I'd love to be told this isn't correct.)
(See this comment: https://github.com/PaulStoffregen/cores/pull/682#issuecomment-1403095131)

Note: `_serialEvent_default` isn't defined as weak in serialEvent.cpp.
 
Last edited:
I tested serialEvent. I also checked the value from Arduino sketch code and it was 1, not 0.

But I didn't try the hardware ones like serialEvent1. Will do that this evening.
 
I've updated the list of changes since 1.58-beta3. It's a *lot* of small stuff. If I missed anything important or didn't credit the right people, please let me know.
 
Okay, I'm relieved. Thanks for double-checking. I was concerned because my tests, printing the value from inside `yield()`, showed that it was zero. Maybe it was because I was using GCC 11.3.1-beta2 (from Teensyduino 1.58-beta3) and not 11.3.1 (from 1.58-beta4)? Dunno...
 
PaulStoffregen said:
I tested serialEvent. I also checked the value from Arduino sketch code and it was 1, not 0.

But I didn't try the hardware ones like serialEvent1. Will do that this evening.
Click to expand...

Forgot to add in my previous post (so you don't have to go hunting for the information): PR 672 just affects _serialEvent_default and not the others. I had only added `extern` to that variable.
(See also: https://github.com/PaulStoffregen/cores/issues/681)
 
I ran more tests with serialEvent and _serialEvent_default. Here's a simple test program.

Code: 
extern const uint8_t _serialEvent_default;

elapsedMillis timeout;

void setup() {
  pinMode(13, OUTPUT);
  Serial.begin(9600);
  Serial1.begin(115200);
  Serial.println("serialEvent and yield test");
  Serial.print("_serialEvent_default = ");
  Serial.println(_serialEvent_default);
  timeout = 0;
}

void loop() {
  static unsigned int loopcount = 0;
  loopcount++;
  digitalToggleFast(13); // measure pin 13 frequency
  if (timeout >= 3000) {
    timeout = 0;
    Serial.print("loop runs per second = ");
    Serial.println(loopcount / 3);
    loopcount = 0;
  }
}

void serialEvent() {
  int n = Serial.read();
  Serial.print("Serial = ");
  Serial.println(n);
}

void serialEvent1() {
  int n = Serial1.read();
  Serial.print("Serial1 = ");
  Serial.println(n);
}

Tested on 1.57 and this beta. Both print "_serialEvent_default = 0". (not sure why I remembered seeing 1... might have mixed this up with testing 64 bit integer support in String)

Most important, both USB Serial and hardware Serail1 run the event functions to print incoming bytes, on 1.57 and 1.58-beta4.

Speed measures 2.5% slower.

1.57: "loop runs per second = 3845997", frequency counter = 1922968.8

1.58-beta4: "loop runs per second = 3749830", frequency counter = 1874886.3

freq.jpg

I can live with a 2.5% performance hit on this specific case. Reality seems to be this yield optimization probably hasn't been quite right for a long time. I don't recall exactly where it came from, but I do remember when I merged it I only tested whether serialEvent still worked.

For 1.59, hopefully we can find a simpler way that works with LTO.
 
Good Morning Paul (and all),

If you are following the MassStorage... thread, you probably have noticed a few comments about corruptions of lists. Yesterday I did find a very possible set of conditions that maybe that would happen. Along the lines that was mentioned earlier in that thread by some others. The issue was queueing a new transfer from the user code space, like RAWHID send a packet, and some cases in MassStorage without them disabling the USB interrupt. Then in the middle of the allocating a transfer or mucking with the transfer data, a USB interrupt comes in that will queue another transfer or remove the previous transfer that the code was in the middle of adding it to the end of the list... Note: we have previously pulled our hair out a few times where we ended up with circular lists...

So you might want to tak a look at new PR: https://github.com/PaulStoffregen/USBHost_t36/pull/115
That the queue... will always disable that interrupt and only re-enable it if it was not disabled coming into it. (Some places protected it externally that also might update other things like timers before they want the interrupt to be allowed to happen).

Side notes: Trying it out on todays nightly build, which should now include the fix for the old issue, of the magic text cursor movement. And some others. And also has the earlier fix for showing the last lines of text that were output in Serial monitor, which again went in after 2.0.4

Been trying some different USB Host tests as well. Like the tablet library (https://github.com/KurtE/WacomController) that @mjs513 and myself worked on a while ago. Tried it on Huion tablet and still works. Did not notice any new compiler warnings. (Works a lot better than the Tablet code currently in USBHost).

Will continue to test some random things
 
I've put the tentative 1.58 release files on the server. If you want to give them a try with Arduino 2.0.4 or nightly, use this URL in File > Prefs

Code: 
https://www.pjrc.com/teensy/td_158/package_teensy_index.json
 
@PaulStoffregen
Code: 
https://www.pjrc.com/teensy/package_teensy_index.json

worked for me for both 0.58.4 and 1.58.0 to allow these versions to show in the boards manager. It auto updated the index after I changed it.
Note Deleted the td_158 from link. With that in couldn't find server.

However, the 1.58 said missing file(or something like that, sorry)

I was able to install the 0.58.4 and now the 1.58 doesn't show up in the drop down list anymore!

Well, at least I can run the latest.
 
The update req'd a dog walk:D. Just got back and opened 2.0.4 and the board list showed 1.58.0. Installed with no problems. Various issues with String and time_t appear fixed!
Awesome, thanks.

FYI, probably obvious but...
in Arduino 2.0.4 when looking at the 'Boards Manager' it's easiest to put 'tee' into the nearly invisible search box below 'Boards Manager' and make sure the Type is set to 'All'. If set to 'Updatable' nothing shows up if your up to date and if your using beta's it may get confused(or you may be confused) on which versions to hide.
 
Added above URL to open IDE 2 and it found it not - after indicating is updated.

Accidentally closed the open sketch.

Opened RECENT and then after the open delay BOARD MGR showed the 1.58.0 to install, did not need to restart the whole IDE - just open a new sketch window.

Then COREMARK built and uploaded fine
 
You must log in or register to reply here.
Back
Top