Teensyduino 1.44 Beta #1

[Paul]

Here is a first beta test for Teensyduino 1.44.


Linux 32 bit:
https://www.pjrc.com/teensy/td_144-b...nstall.linux32

Linux 64 bit:
https://www.pjrc.com/teensy/td_144-b...nstall.linux64

Linux ARM:
https://www.pjrc.com/teensy/td_144-b...stall.linuxarm

Mac OS-X:
https://www.pjrc.com/teensy/td_144-b...inoInstall.dmg

Windows:
https://www.pjrc.com/teensy/td_144-b...inoInstall.exe


Changes since Teensyduino 1.43

Improve Tools > Ports menu refresh speed
Support Tools > Get Board Info
teensy_ports now sends JSON on stdout

[defragster]

This is in advance of a release of a new IDE 1.8.7?

Installed no issue Win 10 - board info worked, also worked for T_3.6 when made active Port:

BN: Teensy LC
VID: 16C0
PID: 0483
SN: 111396

And JSON:

T:\arduino_1.8.6\hardware\tools>teensy_ports.exe
{
"address": "usb:0/140000/0/2",
"online": true,
"label": "COM11 (Teensy LC) Serial",
"vid": "16C0",
"pid": "0483",
"iserial": "111396",
"boardName": "Teensy LC",
"protocol": "Teensy"
}
{
"address": "usb:0/140000/0/6/1",
"online": true,
"label": "COM8 (Teensy 3.6) Serial",
"vid": "16C0",
"pid": "0483",
"iserial": "205639",
"boardName": "Teensy 3.6",
"protocol": "Teensy"
}

Teensy_Loader not active - Pushed the T_3.6 Button and this added text appeared:

{
"address": "usb:0/140000/0/6/1",
"online": true,
"label": "[no_device] (Teensy 3.6) Bootloader",
"vid": "16C0",
"pid": "0478",
"iserial": "205639",
"boardName": "Teensy 3.6",
"protocol": "Teensy"
}
{
"address": "usb:0/140000/0/6/1",
"online": true,
"label": "hid#vid_16c0&pid_0478 (Teensy 3.6) Bootloader",
"vid": "16C0",
"pid": "0478",
"iserial": "205639",
"boardName": "Teensy 3.6",
"protocol": "Teensy"
}

Pushed the T_LC button and this added text appeared:

{
"address": "usb:0/140000/0/2",
"online": true,
"label": "[no_device] (Teensy LC) Bootloader",
"vid": "16C0",
"pid": "0478",
"iserial": "111396",
"boardName": "Teensy LC",
"protocol": "Teensy"
}
{
"address": "usb:0/140000/0/2",
"online": true,
"label": "[no_device] (Teensy LC) Bootloader",
"vid": "16C0",
"pid": "0478",
"iserial": "111396",
"boardName": "Teensy LC",
"protocol": "Teensy"
}
{
"address": "usb:0/140000/0/2",
"online": true,
"label": "hid#vid_16c0&pid_0478 (Teensy LC) Bootloader",
"vid": "16C0",
"pid": "0478",
"iserial": "111396",
"boardName": "Teensy LC",
"protocol": "Teensy"
}

[defragster]

Left both boards in Bootloader from prior post. Set port back to T_LC, and compiled the last sketch I was using there.

The Sketch was uploaded to the T_LC it seems - as this is in setup() shows new compile time:: Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);

However then I got the "AUTO MODE DISABLED" dialog - from the T_3.6 being left in Bootloader.
> I suppose this is expected and prior behavior - but is just a bit wrong and annoying that TLoader is confused.

JIC - here is the log as I have it:: TLoader_TwoBoots.txt

The teensy_ports.exe window still open shows the T_LC came back online - no added output from the T_3.6.

[PaulStoffregen]

Yes, this is prep for Arduino 1.8.7 which is expected next week. It's also sort-of prep for 1.8.8, where the Arduino devs have said they want to included a "discovery manager" for Teensy (and other future boards) and they wanted to use JSON format. That is one of the major limitations with Arduino that requires Teensy to have a custom installer rather than using their boards manager.

Right now, the Ports menu slowness issue (reported by Diodac and mentioned by others) is at the top of my bug list. I also have a few issues on the list which affect usability for 2 or more boards. I might try to squeeze a fix for one of them into 1.44.

FWIW, this JSON format is likely to change. Cristian (Arduino's lead dev) said he wants to see different field names and the protocol-specific fields handled in a different way. The current format is a result of the code they wrote in BoardPort.java when used with Jackson ObjectMapper. Personally I don't care what the format is (whether it's JSON or anything else)... I just want to fix the Port menu lag!

In 1.42 & 1.43, teensy_ports uses localhost communication to Arduino. It runs in the background, keeping track of USB device changes as they occur. When Arduino starts up, a connection is opened. Then when you click on the Tools menu, Arduino sends a "list" command and teensy_ports replies with the list of all the USB devices it already knows. The idea was keeping the connection open and having the list already in memory would be quick. Indeed it is very quick on Linux. Turns out Windows and especially Macintosh don't work so well with this idea.

In 1.44 I'm abandoning the localhost networking idea. Now teensy_ports just sends everything on stdout as the USB changes occur. There's no "list" command, or any other communication from Arduino to teensy_ports. On the Arduino side, the supporting code is now multithreaded. When teensy_ports sends another chunk of JSON, it's received and parsed by a dedicated Java thread, which hopefully minimizes any impact to the GUI's responsiveness. When you click the Tools menu, a copy of the info this thread has already received is used to update the Ports menu. I did have to use 2 synchronized functions for the parser to update the list and the GUI to read it, but I tried to minimize the time to only copying data that's already in memory - no parsing or other work.

At least that's the idea. The Arduino IDE does *lots* of other stuff to update the Tools menu. So far I've focused only on the part Teensyduino adds.

[defragster]

Among other good stuff for future - That explains no reply from : telnet 127.0.0.1 28542.

Thought seeing the expected output on a 'user' Windows machine might be useful.

Except when I was provoking the fixed before release 6-8 second FAIL on windows - I wouldn't say I saw unexpected slowness on Windows - but as noted recently the IDE failure to follow Windows norms on menu items makes it a royal pain already - so just glad to be done with it when it works. If any behind the scenes delay is reduced - all the better though. You already had solved the orphaned instance issue - hopefully that won't recur.

[PaulStoffregen]

Testing now with 4 windows open on a Macbook Air, I'm seeing the Tools menu seems to be respond rapidly. So do all the others, except File. The first time I bring a window to focus, I get a Mac beachball for about 1-2 seconds when I try to click File.

[defragster]

Yeah for Mac!

On TD 1.43 install with 1.86 and 6 sketches open on Windows just opened I see no FILE delay - and mouse over menus don't show delay - same for the TD 1.44.

[PaulStoffregen]

I tracked the remaining Mac menu slowness to this function in Editor.java.

      public void menuSelected(MenuEvent e) {
        List<Component> components = Arrays.asList(fileMenu.getMenuComponents());
        if (!components.contains(sketchbookMenu)) {
          fileMenu.insert(sketchbookMenu, 3);
        }
        if (!components.contains(examplesMenu)) {
          fileMenu.insert(examplesMenu, 4);
        }
        fileMenu.revalidate();
        validate();
      }

That's the easy part. The hard part is fileMenu.insert() seems to be incredibly slow on recent versions of Java. Same issue the Arduino devs found. I added some code to measure the elapsed time. It's ~3500 ms on my Macbook Air for that 2nd insert with Teensy's Examples menu. With Arduino Uno's Examples menu, it's ~500 ms. Something about JMenu insert() became incredibly slow with recent Java!

The other hard part is *why* this code needs to re-insert those 2 menus. The menu gets created with them and I can't find anything in the IDE which ever removes them. I added *lots* of code to print the number of items in the menu at various places. When first created, the menu has 11 items. But then later when the window gets activated, it only has 9. After that code runs, it has 11 again. Then later as windows activate & deactivate, those 2 get lost again. Obviously that code exists because these 2 items mysteriously drop from the menu. But where? I can't find it. My best guess at this point is it may be some Java problem or limitation where sub-menus can't be retained when the menu is cleared from MacOS's single always-top-of-the-screen menu bar.

I'm afraid this last bit of Mac menu slowness is beyond my ability to fix.

[defragster]

That is ugly and time costly. I suppose that means dropping in a new library is found each time though? No need to restart the IDE?

I dropped a copy of the MusicWithoutDelay and examples not found on Windows - until I changed the board IIRC. That would explain the lengthy time to 'change board' on Windows - about 7 seconds each time - both ways. Does T_3.6 to T_LC board change take a long time on MAC? Where Windows File menu is Zero wait.

[mjs513]

Just as a heads up just saw that Arduino 1.8.7.