Teensyduino 1.62 Beta #5 - Release Candidate

Paul

Paul

Administrator
Staff member
This fifth beta test for Teensyduino 1.62 is meant to be a release candidate.

Arduino 2.3.x: Copy this URL to Arduino IDE File > Preferences (Arduino IDE > Settings on MacOS).


Use Boards Manager to install Teensy version 0.62.5
(to refresh versions, Shift-Ctrl-P and click "Arduino: Update Package Index")


Arduino 1.8.x, Linux 64 bit:

Arduino 1.8.x, Linux ARM:

Arduino 1.8.x, Linux ARM64:

Arduino 1.8.x, Windows:


Changes since 1.62-beta4:

Fix lag between compile and upload on Arduino IDE 2.3.x when serial monitor open
Workaround for Serial+MTP serial monitor reconnect after upload on Windows
 
I especially need community help testing Arduino IDE 2.3.10 serial monitor on Windows.

I personally use Linux for most work. I'm not familiar with subtle Windows behaviors. My Windows 11 laptop I use for testing has almost no other software or special drivers installed, because I don't actually use it for anything else. This beta makes multiple improvements in teensy_monitor.exe. I tested as much as I can, but my ability with Windows is limited. I'm really depending on community feedback for Windows!
 
PaulStoffregen said:
I especially need community help testing Arduino IDE 2.3.10 serial monitor on Windows.

I personally use Linux for most work. I'm not familiar with subtle Windows behaviors. My Windows 11 laptop I use for testing has almost no other software or special drivers installed, because I don't actually use it for anything else. This beta makes multiple improvements in teensy_monitor.exe. I tested as much as I can, but my ability with Windows is limited. I'm really depending on community feedback for Windows!
Click to expand...
1.62 beta 5, Arduino IDE 2.3.10 and Windows 10 Professional. Serial Monitor works fine. Programming works fine. No issues so far.

Thanks!
 
Any reason building MTP + Serial on non MTP sketches would fail IDE 2.3.10 SerMon with TD 0.62.5 : Beta 5 installed?

Tried with the recent MJS WiFi example as edited and working without MTP added, same with the Code4CODE example.

won't begin without SerMon closed and opened and then startup is not always normal - it may start and stall. CODE4CODE spits out some and stalls before inital test complete, and the WiFi example doesn't complete startup and go to function.
 
No change for me when running the code from this post; the serial monitor still does not reconnect properly, Teensy is blocked waiting for the serial connection.
 
RE p#4: Simple three line edit to EXAMPLE:BLINK (the ones with 'Serial.')

Win 11 Build for a T_4.1 with "Serial + MTP"
Blink Starts - but no IDE 2 SerMon output
Close SerMon
Open Sermon and output displays and starts as expected
>> Build and Upload again and any prior SerMon output is displayed
> repeat above: Blink starts, 'Close SerMon' and output starts

<EDIT>: Confirm build as :: USB:Serial and execution runs as expected
<EDIT #2> revert to 0.62.4 and behavior is the same, so not new to Beta 5

Code: 
// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(1);
  Serial.print("\nstart\n");
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);  // change state of the LED by setting the pin to the HIGH voltage level
  delay(1000);                      // wait for a second
  digitalWrite(LED_BUILTIN, LOW);   // change state of the LED by setting the pin to the LOW voltage level
  delay(1000);                      // wait for a second
  Serial.print(".");
}
 
Last edited:
p#6 code when run using TyCommander as SerMon misses the early setup() print code - but does then connect and print the repeat '.' in loop()

So, Windows 11 is failing the normal quick connect of Teensy Serial when MTP is included. But this is unlike IDE 2 SerMon that switches to SerMon window just after build and never connects without a Close/Open. Though when it does that the initial 'start' text is presented
 
PaulStoffregen said:
Just to repeat, beta5 has new code in teensy_monitor.exe which keeps trying to open the port for about 8 seconds. So even if you do wait indefinitely in a while (!Serial) loop on Teensy, when Windows MTP driver gives lets the COM port become accessible after ~5 sec of not getting the info it wanted, teensy_monitor.exe is supposed to be able to connect and the while (!Serial) loop will see Arduino Serial Monitor is connected.
Click to expand...

Ok for full ref here is the sketch I am attaching my test sketch.

1. Using `while(!Serial)` :
​
a. MTP never opens up a Teensy drive on my Win 11 machine until I open the Serial Monitor.​
b sketch runs and shows:​
Code: 
Ram Drive of size: 65536 initialized

Setup done

Media inserted "USB Disk1"(1) "USB DISK"
mediaPresent = Yes No  No  No  No
mediaPresent = Yes No  No  No  No
mediaPresent = Yes No  No  No  No
mediaPresent = Yes No  No  No  No

2. Using `while(!Serial) with Serial Mon already open: Teensy drive opens but nothing is printed to the Serial Monitor until I close it and open it again. Think @defragster mentioned this in a previous post

3. Using `while(!Serial && millis() < 5000)`
Teensy Drive Window shows immediately after loading and when I finally open the Serial monitor its printing status.
 

Attachments

  • New_MTP_TEST-260615a.zip
    981 bytes · Views: 15
  • log.txt
    135 KB · Views: 25
Morning all,
I installed it last night and tried my main MTP sketch (picture viewer) and it did not show any of the issues.
But again it times out:

Code: 
void setup(void) {
// mandatory to begin the MTP session.
#ifdef MTP_TEENSY_H
    MTP.begin();
#endif
    // Keep the SD card inactive while working the display.
#if SD_CS != BUILTIN_SDCARD
    pinMode(SD_CS, INPUT_PULLUP);
#endif
    delay(20);
#if defined(USE_SPI_LITTLEFS)
    for (uint8_t i = 0; i < (sizeof(lfs_spi_list) / sizeof(lfs_spi_list[0])); i++) {
        pinMode(lfs_spi_list.csPin_, OUTPUT);
        digitalWrite(lfs_spi_list.csPin_, HIGH);
    }
#endif
    while (!Serial && millis() < 3000) {}
    Serial.printf("TFT CS:%u DC:%u RST:%d\n", TFT_CS, TFT_DC, TFT_RST);
...

As the main thing of this sketch is to display pictures...

Some of the symptoms don't sound, don't sound that different from earlier builds.
I remember there were times where it was finnicky on the order of when the MTP begin is versus Serial stuff.

You might verify if this is a regression and if not, not sure it is worth holding up the release...
After all, it is still marked as Experimental.
1781527676798.png
 
KurtE said:
a regression
Click to expand...
test above got the same in Beta 4 - so the change to Beta 5 SerMon didn't cause that.

Compared to TyComm - Windows clearly takes some time to get SerMon online and output missed without appropriate !Serial wait. But TyComm does connect when Windows is ready, and never displays any preceding 'missed' early output.

PJRC SerMon does have some early connect fail immediately after build completes - and doesn't wait/retry/resolve without Close/Open
>> ODD thing is after Close/Open ALL expected output is then displayed! And then it continues.
--> On reOpen output starts as:: start<NewLine>...
That suggests loop() was entered and ~six seconds passed, and it was buffered and waiting.

On switch to earliest IDE 2 SerMon this behavior was common and why TyComm use was required for best use.

Using this edit of the above BLINK variant with wait for Serial - the issue persists and PJRC SerMon has to Close/Open, even with no .print before (Serial). If the print before the while() in setup is uncommented that "NO Serial" is buffered and presented by PJRC SerMon. TyComm works in both cases, but doesn't catch the "NO Serial" in that case.
Code: 
void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(1);
  // if (!Serial) Serial.print("\nNO Serial\n");
  while (!Serial) delay(1);
  Serial.print("\nstart\n");
  Serial.println(millis());
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);  // change state of the LED by setting the pin to the HIGH voltage level
  delay(1000);                      // wait for a second
  digitalWrite(LED_BUILTIN, LOW);   // change state of the LED by setting the pin to the LOW voltage level
  delay(1000);                      // wait for a second
  Serial.print(".");
}
 
macOS26.5.1,Arduino 2.3.10, with large program with a bunch of libraries in my documents/Arduino/Library

FYI
Got lazy and didn't follow my personal procedure for major updates. Every thing compiled without errors or warnings awesome! However buttons that used gpio_expander didn't respond.

After trying just clearing cache at: myHD/Users/myname/Library/Caches/arduino/sketches without quiting Arduino still no buttons.
So did what I should have done:
1 Quit Arduino and Teensy
2 Change dir to: myHD/Users/myname/Library/Caches/arduino
3 Delete both the folders sketches & cores
4 Open Arduino ..

Recently I hadn't had to do all that. But whatever it seems to work now.
 
By the way, the initial compilation seems to compile much faster, almost faster than previous version re-compiles. Guess this has something to do with the also observed no 'Intel' in Activity Monitor when running Arduino.
 
Yes, the gcc 15.2 toolchain for MacOS has both arm64 and x86_64 versions, so you should see a nice speedup when running on an Apple Silicon Mac.
 
defragster said:
p#6 code when run using TyCommander as SerMon misses the early setup() print code - but does then connect and print the repeat '.' in loop()

So, Windows 11 is failing the normal quick connect of Teensy Serial when MTP is included.
Click to expand...

Confirm, more work to be done on Serial+MTP in future.

I'm pretty sure the issues you're seeing with TyCommander and using Serial.begin() rather than "while (!Serial)" are the same 5 second USB Serial blocking issue if MTP.loop() isn't being run. Serial.begin() waits only 2 seconds, not long enough for this MTP issue.

Future MTP will need to do more from the interrupt so we keep the Windows MTP driver from blocking the usbser.sys driver for 5 seconds. But I'm not going to hold up 1.62 for that work.
 
I'm going to run my list of 19 tests late tonight. If all pass (they all passed on beta3) and if nobody replies with a serious problem, I'm planning to release 1.62 tomorrow.

There's always a lot more to do. I want to get this toolchain update wrapped up, so that future work can be built on the new toolchain.
 
PaulStoffregen said:
shift key while you click Verify.
Click to expand...
The 'Verify' popup text even changes to 'Verify (Clean)' when SHIFT is held!

RE: p#15 - Indeed MTP Build makes Windows act funny - even when the sketch code doesn't have any direct calls to it.
TyComm somehow catches the proper arrival of Teensy Device, whenever it appears - and waits until then. Something about the PJRC SerMon gloms onto the old connect and without Close/Open doesn't transition to the 'new' linkage Windows establishes - but when it can find prior data waiting.
And sometimes if the IDE 2 SerMon is used and closed it fails to release the device and TyCommander cannot connect until IDE closed.

RE: p#16 - Good

IDE 2 is building faster for sure now.
SPEED NOTE: Building Code4Code as USB: Serial
1 min 19 sec :: IDE 2.3.10 with TD 0.62.5 // FASTER
1 min 32 sec :: IDE 1.8.19 with TD 0.62.5

SPEED NOTE: Building AI_Tetris as USB: Serial
1 min 10 sec :: IDE 2.3.10 with TD 0.62.5 // FASTER
1 min 36 sec :: IDE 1.8.19 with TD 0.62.5
Code: 
Using library SPI at version 1.0 in folder: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SPI 
Using library ST7735_t3 at version 1.1.0 in folder: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\ST7735_t3 
Using library Wire at version 1.0 in folder: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\Wire 
Using library Adafruit_FT6206_Library at version 1.1.0 in folder: T:\T_Drive\tCode\libraries\Adafruit_FT6206_Library 
Using library Adafruit_BusIO at version 1.17.1 in folder: T:\T_Drive\tCode\libraries\Adafruit_BusIO 
Using library Audio at version 1.3 in folder: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\Audio 
Using library SD at version 2.0.0 in folder: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SD 
Using library SdFat at version 2.1.2 in folder: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SdFat 
Using library SerialFlash at version 0.5 in folder: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SerialFlash 
Using library EEPROM at version 2.0 in folder: T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\EEPROM 

Memory Usage on Teensy 4.1:
  FLASH: code:81148, data:9828, headers:8348   free for files:8027140
   RAM1: variables:14240, code:77720, padding:20584   free for local variables:411744
   RAM2: variables:16064  free for malloc/new:508224
 
Fluxanode said:
I use and rely on MTP. In this version is MTP stable enough to depend on? I am currently using 1.60.
Click to expand...
This is 1.62 and there was a recent 1.61. - Quick glance at release change notes ...
1.61 notes some MTP update to help USB?
1.62 is primarily an update to the toolchain.

So MTP should be as good as it was - this issue just relates to how Windows OS lags a bit for MTP getting USB Serial online that does well with a wait of ~5 seconds for that to complete in setup() to expect usable USB Serial if using Windows.

Paul may have future MTP work on his notes - but looking at the imminent release of 1.62 and checking it out would be good for going forward.
 
Paul: thanks for your answer. I guess the release candidate part tripped me up and the MTP comments left me wondering. I am in the middle of making a industrial OPC module that the stakeholder has asked for, to replace Siemens PLC interface modules with a product that reads from Micromotion Modbus flow sensors, analog (4-20) pressure and temperature sensors and digital pulse flow meters. Then communicates the data with the Siemens PLC. MTP is an integral part of the data storage and file uploading to the customers system that the operators will be monitoring. I'm just a user I guess and don't have the luxury to beta test on this project, thus have not changed version since I started. At his time 1.60 MTP has been stable for me but I don't want to stay stagnant on older versions forever for obvious reasons, Thanks again.
 
Fluxanode said:
I guess the release candidate part tripped me up
Click to expand...

Release candidate is pretty commonly used software jargon meaning the likely last beta test version before a proper release.


Fluxanode said:
I'm just a user I guess and don't have the luxury to beta test on this project
Click to expand...

Reality is relatively few people participate in beta tests. Everyone is busy with limited time that tends to get allocated to only their most important tasks.

But there are some good reasons to spend at least a little time. Participating early in beta testing is the time to give feedback that has the best chance of influencing decisions made in the software's development.

Participating late in beta testing, especially with the release candidates, gives you the opportunity to check whether the new version really works with your specific application and (probably) get any problems fixed quickly. Release candidates are the perfect time to do this sort of final check, as we're not planning to make any more feature changes before the release.

If you don't want to participate in the software testing process at all, maybe other threads on this forum are a better place to ask questions. We're pretty casual on this forum, without the sort of strict rules and active moderators so many others use. But we are a community. Everyone participating in the beta testing and software development wants to see the best software that ultimately benefits everyone.

I hope you'll consider at least joining in quick testing next time (as 1.62 has now officially released). Arduino IDE makes this really easy. Just change the URL in File > Prefs and use Boards Manager to install the new version. When you want any of the official releases, it's just as easy to put the URL back and use Boards Manager to remove the beta and reinstall any of the stable releases. Including steps to compile and upload your program and see whether it really works in your project, you're looking at maybe 10-15 minutes time commitment. In the grand scheme of making a real project, that's a pretty small amount of time which gives you the best opportunity to avoid any future problems and (probably) get them fixed before we finalize the release.
 
You must log in or register to reply here.
Back
Top