Teensyduino 1.42 Beta #6

Status
Not open for further replies.
I just did something that welcomed fail - but worked. During compile - with open Tsermon I clicked 'Serial Monitor' icon in IDE - it closed one and opened a second offline that came active on restart after Upload - but that did not cause a 2nd SerMon. I just did the same on the 2nd IDE and again - one closed and one opened with no extras created. Disk Activity shows 0% and each IDE's Tsermon shows 0% CPU.

Wow, thanks for this! I was finally able to get two instances of teensy_serialmon. Neither is hogging CPU, but there really shouldn't be 2 instances.

capture.png

Will start now investigating why this is happening....
 
On Windows 7 we had those strange USB enumeration delays with almost all the USB types having more than 1 HID interface. I was *really* glad to see Microsoft finally fixed the delays on Window 10. But maybe not completely?

Any chance you could try on a Mac or Linux? If it's something on the Teensy side (happening with all 3 systems), I could try to investigate.

If it's only Windows, I'm sad to say I've already spent an incredible amount of (fruitless) effort investigating USB enumeration delays. It seems to be a favorite kludge of Microsoft's developers. So far I've never found any way to improve the situation, as it's entire on the Windows side (easy to see with a USB protocol analyzer).

I don't have a Mac or Linux (might get a Mac in a month or so) but I think I might have found a cause after spending some time debugging this (I am using Microsoft's USB Device Viewer utility to view the detailed Teensy USB device info).

Basically it seems that long enumeration times on my Win PC occur when the Teensy's USB device iSerialNumber is not set. From my debugging, I have narrowed the scenarios where iSerialNumber is missing down to the following:

  • all default USB types that come with Teensyduino have the iSerialNumber set after compiling / flashing => enumeration happens fast (< 1sec)
  • if I use my OWN USB type definition (USB_SERIAL + MIDI + KEYBOARD + MOUSE ) and MIDI_NUM_CABLES = 1, iSerialNumber is set => enumeration happens fast (< 1sec)
  • as soon as I use my OWN USB type definition AND I set MIDI_NUM_CABLES > 1, iSerialNumber is not set => enumeration takes a long time (ca. 9sec)
  • however, if I use my OWN USB type definition AND I set MIDI_NUM_CABLES > 1 AND then add an adidtional HID device such as the FLIGHTSIM_INTERFACE, iSerialNumber is set again => enumeration happens fast

Does that help?


USB device debug info:

custom USB device info with MIDI_NUM_CABLES = 1
View attachment [Port6] - USB Composite Device_MIDI_NUM_CABLES_1.txt

custom USB device info with MIDI_NUM_CABLES = 2
View attachment [Port6] - USB Composite Device_MIDI_NUM_CABLES_2.txt

custom USB device info with MIDI_NUM_CABLES = 2 + FLIGHTSIM_INTERFACE
View attachment [Port6] - USB Composite Device_MIDI_NUM_CABLES_2_PLUS_HID.txt
 
I'm seeing the duplicate teensy_serialmon happen if the serial monitor windows is not opened, then I click Upload, then click the open the serial monitor while the compiler is working. The serial monitor window appears. Sometimes it doesn't manage to open the port, other times it does. When it does open the port, then teensy_reboot can't send the reboot command and times out after ~5 seconds. Then after that timeout, the duplicate teensy_serialmon appears and one of them end up burning CPU time.
 
I'm seeing the duplicate teensy_serialmon happen if the serial monitor windows is not opened, then I click Upload, then click the open the serial monitor while the compiler is working. The serial monitor window appears. Sometimes it doesn't manage to open the port, other times it does. When it does open the port, then teensy_reboot can't send the reboot command and times out after ~5 seconds. Then after that timeout, the duplicate teensy_serialmon appears and one of them end up burning CPU time.

Good - That seems like a behavior I noted in early testing … but at times it would work fine. Hopefully that "Sometimes it doesn't manage to open the port" is behind it all.
 
Ok, I found the place where teensy_serialmon.exe was getting stuck. Actually, 2 possible places. Adding code to both to detect the condition and gracefully quit, rather than sitting there infinitely burning CPU time.

Now working on the Arduino side, to avoid the problem from happening....
 
Here's the fix for the Arduino side.

https://github.com/PaulStoffregen/A...mmit/1cc263db0e88176c930c68cb9bc55d756549821c

If the port is already open, and if it's correct one, and if teensy_serialmon is stuff running and appears to be connected to the IDE by the anonymous pipes, then we just use the one already running. If anything doesn't check out, then we close it before attempting to open a new one.

I'm going to package all this up for beta7. About 30 min...
 
Status
Not open for further replies.
Back
Top