Teensy4.1 - reading from Serial Monitor of Arduino IDE

Note: You can still compile, just simply select the appropriate Teensy in the Tools menu as well as the port...
The issue far as I can tell limited to clicking on the drop down list.
 
You can now track this issue: https://github.com/arduino/arduino-ide/issues/1588
nvalid FQBN: not an FQBN: teensy:avr:teensyMM:usb=serial:usb=serial,speed=600,opt=o2std,keys=en-us

Compilation error: Invalid FQBN: not an FQBN: teensy:avr:teensyMM:usb=serial:usb=serial,speed=600,opt=o2std,keys=en-us

@Paul, This issue has as to do with code recently added, in response to some of your earlier comments/requests.
https://github.com/arduino/arduino-cli/issues/1660

Comments from Arduino Forum:
This bug is related to a nice new feature added to Arduino CLI at the request of Paul Stoffregen:

github.com/arduino/arduino-cli
Provide a way to identify board options via pluggable discovery
opened Feb 14, 2022
closed Oct 18, 2022
cmaglie cmaglie
type: enhancement conclusion: resolved topic: code
As per @PaulStoffregen [comment](https://github.com/arduino/tooling-rfcs/pull/2#issuecomment-1029452622):

> How would you feel about extending Board Identification to allow JSON properties to match the menu options, so arduino-cli could know more of the FQBN?
>
> VENDOR:ARCHITECTURE:BOARD_ID[:MENU_ID=OPTION_ID[,MENU2_ID=OPTION_ID ...]]
>
> As I understand Board Identification, today arduino-cli can at best report the "VENDOR:ARCHITECTURE:BOARD_ID" portion of FQBN, because the spec only defines board.txt entries for matching the main part of FQBN.
>
> If the Board Identification part of spec were extended slightly to specify boards.txt entries such as
>
> {boardname}.menu.{menuname}.{menuoption}.upload_port.{identifier}=Value
> {boardname}.menu.{menuname}.{menuoption}.upload_port.#.{identifier}=Value
>
> then a discovery tools capable of detecting which menu options where used could report properties to match those lines. Future arduino-cli could use this property matching to give a more complete FQBN for the detected hardware. Then in an even farther future, the IDE could utilize the more specific FQBN to initialize those menu options when a user clicks the port+board from the toolbar's drop-down list.

I think it could be implemented exactly as described above.

The CLI is able to identify the board definition associated with a port based on properties returned by the pluggable discovery tool. Previously, it could only determine the base board identity (e.g., teensy:avr:teensyMM), and not the custom configuration of the board you make via the additional Tools menu items in the IDE such as Tools > USB Type. It is now possible for these custom board options to be identified as well.

Unfortunately, even though the feature is working correctly in Arduino CLI, we missed that the Arduino IDE code was making an assumption that the FQBN provided by Arduino CLI would always have the simple teensy:avr:teensyMM form.

As you discovered, the workaround is to always select the board from the Tools > Board menu in the Arduino IDE. When you do that, you are setting the board selection manually instead of using the FQBN automatically determined from the port data returned by the discovery tool.
 
In IDE 2.0.1 I saved the new sketch and exited and restarted and same build fail.
Went to Board Mgr and seems I went 1.58b1 then to 1.58b2 and failed the same.
Went back to TD 1.57 and it fails there too. Seems some issue with updated IDE 2.0.1 reading the platform info?

Went to typical build from SublimeText

> It uses the TSET made FQBN string and worked using IDE 2's installed TD 1.57 and then again 1.58b2 when the board was updated in IDE2

Those build work of course - so somehow FQBN string fails with update to 2.0.1 - when presented properly nothing changed where 1.8.x cmd line builder uses installed TD files.

ALSO NOTE - once built the HEX on the T_4.1 runs fine and good using TYCommander and with that closed using IDE 2.0.1 SerMon with TeensyPorts it also works properly?

That shows T_4.1 is good and WIN USB is good - and even TeensyPorts can work?

I never did repro of initial problem as the update to 2.0.1 was installed and then IDE 2 cannot build.
 
Note: You can still compile, just simply select the appropriate Teensy in the Tools menu as well as the port...
The issue far as I can tell limited to clicking on the drop down list.

Correct, picking from drop down menu: T_4.1 allows complete build.

>> Opps - walked away a couple hours before finishing prior post - did refresh and these posts on new page ...

Also: once uploaded this code worked fine with TeensySerial_SerMon - EXCEPT: I had to CLOSE and OPEN SerMon again before it triggered connect to T_4.1 and displayed the first line after while(!serial) waiting.
 
I've uploaded teensy-discovery 1.57.1 (which removes the extra identification properties which trigger issue 1588) and an updated package_teensy_index.json.

I do not know how to tell Arduino 2.0.1 to refresh package_teensy_index.json. Simplest thing might be to wait a day or two. I'm also not sure if it will offer an automatic update, or if you have to uninstall and reinstall the Teensy package from Boards Manager. Also not clear if Arduino 2.0.1 will stop the old discovery and start the new one without restarting the whole IDE (you'd think it should, but....)

Anyway, when Arduino 2.0.1 notices the updated package_teensy_index.json, and you remove and reinstall Teensy 1.57.0, you should see this:

Code:
Downloading packages
teensy:teensy-tools@1.57.0
teensy:teensy-compile@5.4.1
[B][COLOR="#006400"]teensy:teensy-discovery@1.57.1[/COLOR][/B]
teensy:teensy-monitor@1.57.0
teensy:avr@1.57.0
Installing teensy:teensy-tools@1.57.0
teensy:teensy-tools@1.57.0 installed
Installing teensy:teensy-compile@5.4.1
teensy:teensy-compile@5.4.1 installed
[B][COLOR="#006400"]Installing teensy:teensy-discovery@1.57.1[/COLOR][/B]
teensy:teensy-discovery@1.57.1 installed
Installing teensy:teensy-monitor@1.57.0
teensy:teensy-monitor@1.57.0 installed
Installing platform teensy:avr@1.57.0
Configuring platform.
Platform teensy:avr@1.57.0 installed
 
I do not know how to tell Arduino 2.0.1 to refresh package_teensy_index.json.

Arduino IDE downloads the indexes on startup if it has been more than 4 hours since the last index download.

If you would like to manually trigger an index download sooner than than, you can use the "Arduino: Update Package Index" command:

  1. Press the Ctrl+Shift+P keyboard shortcut (Command+Shift+P for macOS users) to open the "Command Palette".
  2. Select the "Arduino: Update Package Index" command from the menu.
  3. Wait for the notification to show the index download process is finished.

I'm also not sure if it will offer an automatic update, or if you have to uninstall and reinstall the Teensy package from Boards Manager.

The IDE only offers an automatic update if the installed Teensy platform version is older than the latest version available from the package index. This means you must make a new platform release in order to distribute a new release of a pluggable discovery or monitor tool via the Boards Manager update mechanism. In the event you don't have any changes to distribute for the platform itself, this is only a matter of copy/pasting the previous packages[*].platforms[*] entry in the package index file and bumping value of its packages[*].platforms[*].version key. From the user standpoint, the update will go quickly because the archive files are cached, so the only download will be teensy:teensy-discovery@1.57.1

not clear if Arduino 2.0.1 will stop the old discovery and start the new one

It will start the new one. It doesn't stop the old one, but it doesn't listen to it either, so the leftover process doesn't affect port discovery.
 
Started IDE 2.0 - prior problem existed {p#28/29} - w/1.58b2
> grabbed PJRC JSON on startup
> Also did the @PerT explicit grab of JSON
Selected 1.57.0:
Code:
Tool teensy:teensy-tools@1.57.0 already installed
[B]Tool teensy:teensy-discovery@1.57.0 already installed[/B]
Tool teensy:teensy-monitor@1.57.0 already installed
Downloading packages
teensy:teensy-compile@5.4.1
teensy:avr@1.57.0
Installing teensy:teensy-compile@5.4.1
teensy:teensy-compile@5.4.1 installed
Replacing platform teensy:avr@1.58.0-beta2 with teensy:avr@1.57.0
Uninstalling teensy:avr@1.58.0-beta2
Platform teensy:avr@1.58.0-beta2 uninstalled
Uninstalling teensy:teensy-tools@1.58.0-beta2, tool is no more required
Tool teensy:teensy-tools@1.58.0-beta2 uninstalled
Uninstalling teensy:teensy-compile@11.3.1-beta1, tool is no more required
Tool teensy:teensy-compile@11.3.1-beta1 uninstalled
[B]Uninstalling teensy:teensy-discovery@1.57.0, tool is no more required[/B]
Uninstalling teensy:teensy-monitor@1.57.0, tool is no more required
Configuring platform.
Platform teensy:avr@1.57.0 installed

Seems to have stuck with the "Tool teensy:teensy-discovery@1.57.0 already installed" - yet Uninstalled?

Same going back to TD 1.58b2:
Code:
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:teensy-compile@11.3.1-beta1
teensy:avr@1.58.0-beta2
Installing teensy:teensy-tools@1.58.0-beta2
teensy:teensy-tools@1.58.0-beta2 installed
Installing teensy:teensy-compile@11.3.1-beta1
teensy:teensy-compile@11.3.1-beta1 installed
Replacing platform teensy:avr@1.57.0 with teensy:avr@1.58.0-beta2
Uninstalling teensy:avr@1.57.0
Platform teensy:avr@1.57.0 uninstalled
Uninstalling teensy:teensy-tools@1.57.0, tool is no more required
Tool teensy:teensy-tools@1.57.0 uninstalled
Uninstalling teensy:teensy-compile@5.4.1, tool is no more required
Tool teensy:teensy-compile@5.4.1 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
 
The IDE only offers an automatic update if the installed Teensy platform version is older than the latest version available from the package index. This means you must make a new platform release in order to distribute a new release of a pluggable discovery or monitor tool via the Boards Manager update mechanism.

Thanks for the explanation.

I've created a 1.57.1 release which just uses copies of everything from 1.57.0, except of course the discover tool. But even new installs of 1.57.0 should use the new discover, at least as I understand how it works, the discovery and monitor tools always install the latest version and can't be set to use a specific version? (why, I have no idea... but that's what the spec seems to say)


It will start the new one. It doesn't stop the old one, but it doesn't listen to it either, so the leftover process doesn't affect port discovery.

Leaving the old one running is probably ok for Teensy. But maybe not such a great design? Especially on Windows, access to many types of system resources is done with exclusive locking access, where keeping the old process running could prevent the new process from gaining access to the Windows system resources it needs to discover connected hardware.
 
Seems to have stuck with the "Tool teensy:teensy-discovery@1.57.0 already installed" - yet Uninstalled?

Same going back to TD 1.58b2:

What is the package index URL you have in the "Additional Boards Manager URLs" preference for Teensy?

I am using the production URL:

https://www.pjrc.com/teensy/package_teensy_index.json

and mine doesn't have a 1.58b2 release. I guess there is probably a different package index for beta testing.
 
Seems to have stuck with the "Tool teensy:teensy-discovery@1.57.0 already installed" - yet Uninstalled?

Same going back to TD 1.58b2:

Use File > Preferences to edit the addition boards manager URLs. Use https://www.pjrc.com/teensy/package_teensy_index.json (without "td_156").

I added 1.58-beta2 as version 0.58.2. Still only has support for Windows and Linux x86-64. Hopefully by using 0.58.2 it won't get offered as a default choice for anyone.

I'm probably going to delete the old "td_156" package index eventually. Keep 2 of them updates is beyond my maintenance threshold.
 
Use File > Preferences to edit the addition boards manager URLs. Use https://www.pjrc.com/teensy/package_teensy_index.json (without "td_156").

I added 1.58-beta2 as version 0.58.2. Still only has support for Windows and Linux x86-64. Hopefully by using 0.58.2 it won't get offered as a default choice for anyone.

I'm probably going to delete the old "td_156" package index eventually. Keep 2 of them updates is beyond my maintenance threshold.

Always interesting tradeoffs... I updated to use the new package with the 0.58.2 and now every time I startup the IDE it tells me that there are outdated boards, would I like to update, and there is the scary part with the option of automatic!

So now two things that I need to double check each time, like updated libraries. As it wants to update my copy of SDFat, which is a junction link to github code base with Teensy version.
(Note there is a wishlist Arduino ide bug on this part.

Will check to see if there is an issue already, for something lik: the ability to say ignore this board update...
 
About the original problem, I can't reproduce it on Linux with Arduino 2.0.1 and Teensyduino 1.57.1.

screenshot.png

I restored a disk image onto my Windows test machine and it's been stuck in a cycle of Windows Updates and reboots for the last couple hours. Going to image it again before installing anything.

Best guess at this point is it's probably a bug in the Windows version of teensy-monitor, since this works on Arduino 1.8.19 (which uses teensy-serialmon, not teensy-monitor) and teensy-monitor seens to work fine on Linux.
 
even new installs of 1.57.0 should use the new discover

That is correct. The new platform release is only necessary to distribute the new discovery tool release to users who already have the platform installed and up to date.

why, I have no idea... but that's what the spec seems to say

The truth is I don't know the reason for certain either. I just looked over the discussions from the Pluggable RFC comment period and didn't find an answer there.

Any platform can specify a dependency on any discovery tool from any package. A user might have multiple platforms that depend on the same discovery tool (which is already the case with the "builtin" serial-discovery and mdns-discovery, but also could happen for custom discoveries as well). All discovery tool dependencies of all installed platforms run as processes at the same time, and all the ports discovered by all the discoveries of all the platforms are always listed. If specific versions of these tools could be specified by the platforms, then you could have a situation where multiple processes for different versions of the same tool had to run simultaneously. It might be challenging to determine how to process the overlapping port lists in this case. This could result in the problem you pointed out with the multiple processes of the same tool interfering with each other's discovery capabilities.

Leaving the old one running is probably ok for Teensy. But maybe not such a great design? Especially on Windows, access to many types of system resources is done with exclusive locking access, where keeping the old process running could prevent the new process from gaining access to the Windows system resources it needs to discover connected hardware.

You make a good point. I actually wasn't aware of this behavior before I did an experiment earlier today in order to answer your question about what happens when the tool is updated. I was surprised to see two processes.

I submitted a formal bug report about this here:

https://github.com/arduino/arduino-cli/issues/1960

Thanks!


Thanks. I have noted that down. I remember that URL, but had switched to the production one once it became available and didn't realize the previous one was still maintained.

I'm considering adding the betas to the main index with version numbers like 0.58.1, 0.58.2, etc. That way everyone can easily access them and hopefully we won't see IDE 2.0.x pushing users to install those versions.

It defaults to the latest version and also only offers updates when the installed version is lower (according to the Semantic Versioning Specification) than the latest version available from the package index. So this strategy will indeed not result in users of production versions being offered the beta version. As KurtE pointed out, you would experience the opposite, where users of the beta versions are offered "updates" to the release version, even though the release version is older from a development perspective.
 
Always interesting tradeoffs... I updated to use the new package with the 0.58.2 and now every time I startup the IDE it tells me that there are outdated boards, would I like to update, and there is the scary part with the option of automatic!

So now two things that I need to double check each time, like updated libraries. As it wants to update my copy of SDFat, which is a junction link to github code base with Teensy version.
(Note there is a wishlist Arduino ide bug on this part.

Will check to see if there is an issue already, for something lik: the ability to say ignore this board update...

Updated my link in preferences (forgot that originally) and reinstalled 1.57.1 and the FQBN message went away. Reinstalled 0.58.2 - no issues.

Yep you are right every time I start 2.0.1 I get the message about updating libraries and boards - I always select later or install manually.

Didn;t see any library updates for SDFat though but that could be me.

The one thing I noticed is if I try to install board updates manually it does give me the option to install the updates individually:
Capture.PNG

Notice the blue line - I tried to select one board but they all highlighted and the install showed at the botton of the screen and is cut off - almost missed it.
 
the install showed at the botton of the screen and is cut off - almost missed it.

It looks like this bug:

https://github.com/arduino/arduino-ide/issues/1591

I suspected that it would also occur with Boards Manager, but didn't manage to reproduce it there, so I only mentioned Library Manager in the bug report. But both use the same GUI code, so the fix for the Library Manager bug will fix the Boards Manager bug regardless.

The workaround is to increase the width of the side panel a little bit.
 
It looks like this bug:

https://github.com/arduino/arduino-ide/issues/1591

I suspected that it would also occur with Boards Manager, but didn't manage to reproduce it there, so I only mentioned Library Manager in the bug report. But both use the same GUI code, so the fix for the Library Manager bug will fix the Boards Manager bug regardless.

The workaround is to increase the width of the side panel a little bit.

Thanks for response. Could very well be. Funny though when I go to library manager, I am not seeing that same issue:
Capture.PNG

oopps wrong image:
Capture.PNG
 
On the original lost data, I was able to reproduce the problem on Windows 10, but only after unplugging and reconnecting the cable a couple times. I couldn't get it to happen immediately after an upload.

capture.jpg

I'm pretty sure this is my fault in teensy-monitor.exe (Windows only), not a bug in Arduino 2.0.1, (probably) not an issue on the Teensy side. Will dig into the code soon...
 
Installed teensy-discovery 1.57.1

Untitled.jpg

and ran the tests 1 <CNTR + ENTER>, 2 <CNTR + ENTER>,3 <CNTR + ENTER>, 4 <CNTR + ENTER>, 5 <CNTR + ENTER>, then disconnect and reconnect.
It started off well but after a few disconnect/reconnects, the missing responses showed up again. On the screenshot above you can see that the responses on 1, 2, 4, 5 & 6 are missing.

Paul
 
Upgraded this afternoon to Arduino IDE 2.0.2, but the problem persists. Sort of expected this after PaulStoffregen's remark above.
Using Process Explorer > teensy-monitor.exe > Properties, I see the following for I/O when I entered 0 <ENTER>, 1 <ENTER>,....8 <ENTER>, 9 <ENTER> to be send out by Serial.printf():

teensy-monitor-exe.png

The 4 out of 11 received messages correlate with the Process Explorer I/O graph.

IDE2.0.2.png


Paul
 
Looking at this issue again today. Can confirm, reproducible with Arduino 2.0.2 on Windows. Can't reproduce it on Linux. Haven't tried MacOS yet.

capture.jpg
 
Ok, I believe I have a fix for this problem on Windows. If anyone is still watching this thread, please give this teensy-monitor.exe a try. Does it fully solve the problem on your machine?

On my Windows install, the location was C:\Users\{username}\AppData\Local\Arduino15\packages\teensy\tools\teensy-monitor\1.57.0.
 

Attachments

  • teensy-monitor.zip
    26.2 KB · Views: 35
I believe I have a fix for this problem on Windows
After testing, I believe you fixed it!
Did about 10 disconnects-reconnects, sent a lot of short and long strings and it never missed a single reply in the serial monitor window.

Thanks,
Paul
 
Ok, I believe I have a fix for this problem on Windows. If anyone is still watching this thread, please give this teensy-monitor.exe a try. Does it fully solve the problem on your machine?

On my Windows install, the location was C:\Users\{username}\AppData\Local\Arduino15\packages\teensy\tools\teensy-monitor\1.57.0.

Gave it a try using 1.58-beta2 as well and seems to be working as @PaulS mentioned. Used Arduino 2.0.2.
 
Back
Top