Teensyduino 1.42 Beta #6

Status
Not open for further replies.

Paul

Administrator
Staff member
Here is a sixth beta test for Teensyduino 1.42.

The main new feature is a "Teensy" section in the Tools > Ports menu
which tries to show Teensy in all modes, not just Serial. New native
(no Java serial library) serial monitor code is also with these ports.


Old beta download links removed. Please use the latest version:
https://www.pjrc.com/teensy/td_download.html


Changes since Teensyduino 1.42-beta5

Improve multiple instance check in teensy_ports
Add -L option to teensy_ports (intended for PlatformIO)
Treat "narrowing conversion" as compiler warnings, not errors
Fix product ID for Flightsim+Joystick USB type
Audio: allow WAV files with extra/junk sections before "fmt" info
Ethernet: document Ethernet.init(cspin) in all examples
OctoWS2811: Fix timing problem on Teensy 3.5
USBHost_t36: Fix clobbering of pipe config on endpoint size change
USBHost_t36: Improve enumeration of Multi-TT hubs
 
Installed and testing Beta 6 on 1.85 - so far not seeing any problem - starting with new sketch : ADC::readAllPins.ino - still two instances and T_3.6 and T_LC. Much more Serial output and not buried in fault_isr() code.

Switched back to posted debug_t3/DebugTest and so far following the same steps has not had prior signs of untimely 'Tools' and failed Ports_Teensy, or multiple instances of Tports.


… I still have to change TaskMan tabs away and back to 'Processes' to get an up to date list - that I think I can trust. Just now rather than missing one Java entry - there was a 3rd entry for Java - showing the sketch names and 'Offline T_3.6' that was now online. On return to 'Processes' tab the 3rd JAVA is gone but JAVA #1/#2 have no entries for the named sketch windows. Seems this is something with JAVA registering with TaskMan? Perhaps that somehow relates to the new Tports spawned from Java … but not of Java? - and not stand alone like Teensy.exe?
 
Really hoping this keeps up and the multiple instance bug on Windows is fixed. If so, feeling like it's probably time to wrap up and release 1.42.

Now's the time to remind me of any bugs or issues that ought to get fixed for 1.42. At this point, bug fixes only. New features can go into 1.43.
 
@Defragster - How's the multiple-instances situation looking? Seeing any lag in the Ports menu?

Maybe give it 'til next week? Hard to know how long to go before concluding a bug that was only intermittent is now solved....
 
For anyone who's interested in ARM 64 bit systems, yesterday Martino (one of the Arduino devs) wrote "I'm starting to add the builds artefacts to downloads server later today or tomorrow, so hang tight".

I booted up a Jetson TX2 for the first time yesterday as well, running Ubuntu 16.04. It's going to become my ARM64 build & test system. At the moment I'm waiting for a M.2 SSD and PCIe4 card to add (really don't want to have another slow ARM board like Raspberry Pi3 to deal with....) It should be here by the weekend. Going to start building the toolchain and adding support in my code, so when/if Martino gets Arduino build for ARM64, we'll be ready to have an ARM64 Teensyduino installer.
 
Following the prior steps I was seeing it be hard to not repro - even with Beta5++ version. Did anything else change from that posted Beta5++ version of the .jar update?

I just was doing it again … in the wait phase … Now I'm not able to see it after trying a couple of times. It is certainly not the easy case it was - and doing the same sketches, same actions { start Ide#1 and wait before start #2 } , same Teensy pair on same machine [ latest Win 10 update 1803.x.81 and a new version of Malwarebytes ].

Just shut both IDE#'s down clean, and Teensy.exe. The pair were running the recent 'MaxUSB' not the 'faulting' DebugTest on startup. Now re-ran with that as before and not seeing any issues. Only ONE Tports.exe and Tools is fast/normal.

At the point of 'Slow' Tools - 'Teensy' was gone from Ports menu - and I was seeing that as soon as IDE #2 was opened in order to change the Teensy! Not subtle and not after any machinations! But added Tports.exe with new on each Tools drop down.


I'd say it is good enough if no issues found in coming days. If 1.8.6 is really pending there will be room to test and fix with a Beta there. And the original IDE_Sermon is unchanged for use worst case so nobody will be locked out.
 
Did anything else change from that posted Beta5++ version of the .jar update?

Yes, teensy_ports.exe changed. If you copy that 1 file from the hardware/tools folder of beta6 into a beta5 install, beta5+jar probably have the same behavior you're seeing with beta6.

Nothing changed in arduino-core.jar from beta5 to beta6, so you could also copy that custom jar file into the lib folder on beta6 if you want to see the debug printing related to the Port menu.


Now I'm not able to see it after trying a couple of times. It is certainly not the easy case it was - and doing the same sketches, same actions { start Ide#1 and wait before start #2 } , same Teensy pair on same machine

Hmmm... not ideal. :(

I really want to know where it's lagging. The whole idea was to make everything faster. Windows programming can be so very frustrating!


If 1.8.6 is really pending there will be room to test and fix with a Beta there.

I don't know what's up with Arduino right now. For the last couple years there were releasing every couple months. They never bothered to import new language translation string except right before each release. When Cristian did this 9 days ago, and a number of other non-code updates, it seemed as if a release was imminent. But now, not so clear. There's been no update to revisions.txt. Activity has died down since then, so looks like they're not preparing a release afterall.

My best guess is the 1.9 beta is starting to look a lot like the 1.5 beta and the long run up to Arduino 1.0.... a lengthy period where they don't manage to make any official releases.

Turns out they did only just recently fully regain access to all the business, only sometime around 2017 Q3, after buying/booting out Musto (where the buyout investment came from ARM, Ltd... which I was recently told in kinda vague language by people I won't mention by name that was meant to prevent certain types of boards from being made). With suddenly having to run all the business side that has previously been the domain of Gianluca Martino and then Federico Musto, and with development of their cloud-based software, and now a FPGA product, maybe they're spread a bit thin lately? Or maybe 1.8.6 is just days away? I just can't tell. The signs from following their github commits & issue tracker just aren't as clear as they were in 2016-2017.
 
May rebuild the Beta5++ setup to confirm it comes back - more later …

>Left both Teensy/IDE's open since last post - both now compiled and Tsermon working - no issues. Closed IDE#2 and re-opened - no problem: Just 1 tports.exe and menu system runs right.
>Closed IDE #1: its associated Tports.exe survived as a 'Background process' when 'Java App' left. IDE #2 uses that single copy and IDE #1 restarted and uses it as well.
>Closed IDE #2: waited … re-opens and plays well - all seems better/good.

but for now …
...
Hmmm... not ideal. :(

I really want to know where it's lagging. The whole idea was to make everything faster. Windows programming can be so very frustrating!
...

This from above post ??? It is working well - I cannot see bad behavior or lagging !!! I'm missing what is not 'ideal' about that ….
Other than the behavior just going away without knowing why?

Just opened TLoader/Verbose - I see the callback is still running. As noted for some Beta's, that 'callback' would stop at the same time the multi-Tports confusion came about.
 
Xubuntu 18.04 64bit Arduino 1.8.5
just installed teensyduino 1.42 beta 6 on fresh 18.04 install worked perfect with teensy++
no error message but work anyway as it did on 1.41 Ubuntu 16.04 NICE :-D <(")
 
This from above post ??? It is working well - I cannot see bad behavior or lagging !!! I'm missing what is not 'ideal' about that ….

Oh, reading your message again, I guess I interpreted this was talking about beta6. Maybe it was about the slowness in beta5?

At the point of 'Slow' Tools - 'Teensy' was gone from Ports menu - and I was seeing that as soon as IDE #2 was opened in order to change the Teensy! Not subtle and not after any machinations!

Sometimes I have a difficult time parsing your messages....
 
Oh, reading your message again, I guess I interpreted this was talking about beta6. Maybe it was about the slowness in beta5?
That message was about Beta 6 - ran the repro { which involves a WAIT PHASE between starting IDE#1 and #2 } and the 'it' was any sign of trouble … "I'm not able to see it after trying a couple of times"
> what I had been seeing starting IDE #1 - then waiting a few minutes { wait phase of the repro } - IDE #2 would start and be broken that instant with failed 'Tools'.


Sometimes I have a difficult time parsing your messages....
I've noticed that … :) :confused:
 
Teensy_serialmon.exe persists

Paul … I put TD1.42b5 on an Arduino Directory - dropped on that posted b5++ jar.

Started IDE #1 compiled a simple blink, Sketch running just fine on T_LC to Tsermon.… waited ~8 minutes. Callbacks continue in open Verbose.

Open IDE #2 :: Callbacks STOPPED >>
> Did not touch IDE menu or anything else … splash screen of IDE #2 left and Verbose showed no more 'callback ###'
> Taskman shows both IDE #'s to each have an active: teensy_ports.exe

So TD 1.42 Beta6 doesn't let this happen - going back to the 1.42b5++ and first time on those steps shows this issue.

BUG NOTES:: { open IDE #1 and #2 - program and exit IDE's and Teensy.exe - check TaskMan Background procs }
With TD 1.42b6 - all is well. When Both IDE's exit - teensy_ports.exe survives as a Background process.
> I've seen this before with it consuming CPU time in the prior cases - trying to repro to confirm I ran into the following
<<EDIT>>: Just repeated this - it is Teensy_serialmon.exe that survived again - not Tports. :: Now using 15.3% of CPU When I close Teensy.exe CPU use jumps to ~29.2%
b6_OrphanTsermonEdit.PNG

I just tried it again and this time it persists with a JAVA wrapper in background and the orphaned process is teensy_serialmon.exe.
>> Problems::
- notice it is eating 29% of CPU
- with this hidden task an install of TeensyInstaller would FAIL as the file can't overwrite.
b6_OrphanTsermon.PNG

Repro steps:
Open IDE #1 : T_LC, open Tsermon, compile, upload
Open IDE #2 : change to T_3.6 - adjust port, open Tsermon, compile, upload
{leaving Tsermon open} <edit2>
Close IDE #1
Close IDE #2
>> Check TaskMan background processes
<<edit #3>> : just did this twice without it happening?
 
Last edited:
Hi,

Not sure if this belongs here on in the general suggestions/bugs section (I am running Teensyduino 1.42b6 on a Win10 64bit).

I am using a custom USB device type as per the definition below (Serial + Midi + Keyboard + Mouse). When I increase the MIDI_NUM_CABLES to any value above 1, the Teensy device shows up on my PC only after about 9 seconds once the Teensy has been reflashed / rebooted. When I have MIDI_NUM_CABLES = 1 it shows up immediately after reflash / reboot.

Code:
#elif defined(USB_SERIAL_KEYBOARD_MOUSE_MIDI)
#define VENDOR_ID		0x16C0
#define PRODUCT_ID		0x0481
#define MANUFACTURER_NAME	{'T','e','e','n','s','y','d','u','i','n','o'}
#define MANUFACTURER_NAME_LEN	11
#define PRODUCT_NAME		{'S','e','r','i','a','l','/','K','e','y','b','o','a','r','d','/','M','o','u','s','e','/','M','I','D','I'}
#define PRODUCT_NAME_LEN	26
#define EP0_SIZE		64
#define NUM_ENDPOINTS		6
#define NUM_USB_BUFFERS	31
#define NUM_INTERFACE		6
#define CDC_IAD_DESCRIPTOR	1
#define CDC_STATUS_INTERFACE	0
#define CDC_DATA_INTERFACE	1	// Serial
#define CDC_ACM_ENDPOINT	1
#define CDC_RX_ENDPOINT       2
#define CDC_TX_ENDPOINT       2
#define CDC_ACM_SIZE          16
#define CDC_RX_SIZE           64
#define CDC_TX_SIZE           64
#define MIDI_INTERFACE        2	// MIDI
#define MIDI_NUM_CABLES       4
#define MIDI_TX_ENDPOINT      3
#define MIDI_TX_SIZE          64
#define MIDI_RX_ENDPOINT      3
#define MIDI_RX_SIZE          64
#define KEYBOARD_INTERFACE    3	// Keyboard
#define KEYBOARD_ENDPOINT     4
#define KEYBOARD_SIZE         8
#define KEYBOARD_INTERVAL     1
#define MOUSE_INTERFACE       4	// Mouse
#define MOUSE_ENDPOINT        5
#define MOUSE_SIZE            8
#define MOUSE_INTERVAL        2
#define KEYMEDIA_INTERFACE    5	// Keyboard Media Keys
#define KEYMEDIA_ENDPOINT     6
#define KEYMEDIA_SIZE         8
#define KEYMEDIA_INTERVAL     4
//Serial
#define ENDPOINT1_CONFIG	ENDPOINT_TRANSIMIT_ONLY
#define ENDPOINT2_CONFIG	ENDPOINT_TRANSMIT_AND_RECEIVE
// MIDI
#define ENDPOINT3_CONFIG	ENDPOINT_TRANSMIT_AND_RECEIVE
//Keyboard
#define ENDPOINT4_CONFIG	ENDPOINT_TRANSIMIT_ONLY
//Mouse
#define ENDPOINT5_CONFIG	ENDPOINT_TRANSIMIT_ONLY
// Media keys
#define ENDPOINT6_CONFIG	ENDPOINT_TRANSIMIT_ONLY

I replicate this behavior with running the standard Teensy/USB_MIDI/InputRead example code.

Using any of the pre-made USB types that come with Teenyduino such as USB type "All of the above" does not have this delay issue.
 
I am using a custom USB device type as per the definition below (Serial + Midi + Keyboard + Mouse). When I increase the MIDI_NUM_CABLES to any value above 1, the Teensy device shows up on my PC only after about 9 seconds once the Teensy has been reflashed / rebooted. When I have MIDI_NUM_CABLES = 1 it shows up immediately after reflash / reboot.

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).
 
<<EDIT>>: Just repeated this - it is Teensy_serialmon.exe that survived again - not Tports. :: Now using 15.3% of CPU When I close Teensy.exe CPU use jumps to ~29.2%
View attachment 13917

I just tried it again and this time it persists with a JAVA wrapper in background and the orphaned process is teensy_serialmon.exe.
>> Problems::
- notice it is eating 29% of CPU

Thanks for the detailed report! I'll start looking at what might be keeping teensy_serialmon from existing.

The communication between teensy_serialmon and Java is done with stdin, stdout, stderr using anonymous pipes. Unfortunately, turns out anonymous pipes on Windows are special, lacking async I/O (or "overlapped" as Microsoft calls it), and Java doesn't support named pipes on Windows, so I was forced to use 2 worker threads and blocking APIs. My guess is something is going wrong there.

Looks like we'll be having beta7.....
 
Glad you appreciate it Paul :) :( … here's more … for got to save the Verbose Log :(

IDE #1 open to T_LC [ not sure it matters which is 1st/2nd - just how I track #1.vs.#2 ]- left it open some long time … yesterday?
Opened IDE #2 - switched to T_3.6, and Tport changed - Upload all is well. … let it sit …

Looked at Taskman - one IDE has 2 Tsermon on IDE_#1 - notice it is sitting with non-zero CPU%::
142b6_SerMonX.PNG

Closed IDE #1 and those lone processes {tport/tsermon} go to Background with the Java App Gone:
142b6_SerMonX2.PNG

Closed IDE #2 - and they persist:
142b6_SerMonX3.PNG

I closed TLoader to assure they would persist as expected … forgot to save off the Verbose data if it might have helped.

The T_3.6 was compiled Raw_HID to test - sketch was simple blink:
Code:
#define qBlink() (digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN) ))  // Pin13 on T3.x & LC
void setup() {
  Serial.begin(38400);
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, HIGH);
  while (!Serial && (millis() <= 4000))
    { qBlink(); delay(50); }
  Serial.print("\nSetup() OK :: millis()==");
  Serial.println(millis());
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
}

elapsedMillis emilBlink;  // Teensy way to delay action without delay()
int8_t loopCount = 0; // Print a NewLine periodically
#define MAX_LOOP 60
void loop() {
  if ( emilBlink > 1000 ) {
    qBlink();
    emilBlink = 0;
    Serial.print(".");
    loopCount += 1;
    if ( MAX_LOOP <= loopCount ) {
      loopCount = 0;
      Serial.println("!");
    }
  }
  char cc;
  while ( Serial.available() ) {
    Serial.print( cc = Serial.read() );
    if ( 's' == cc ) Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
    loopCount = MAX_LOOP;
  }
}
 
Last edited:
I'm running now with 2 Arduino instances a Teensy LC and 3.6. One is Serial, the other is RawHID. So far, haven't managed to get 2 teensy_serialmon processes running under either IDE. None consuming much CPU time yet.

capture.jpg

I'll leave this running overnight.

If I can't reproduce the problem, will start digging into the Windows teensy_serialmon code anyway. Maybe I can get this one too with enough guessing?
 
I'm guessing "let it sit" in your testing might actually mean "use the Windows machine for daily activity, web browsing, email, games, etc"?

In my testing, I'm letting the clean (Arduino & Teensyduino are literally the only software installed) system run without any other usage.
 
I'm guessing "let it sit" in your testing might actually mean "use the Windows machine for daily activity, web browsing, email, games, etc"?

In my testing, I'm letting the clean (Arduino & Teensyduino are literally the only software installed) system run without any other usage.

Indeed - not much for games, but this is my daily machine off and on it all day - only generally rebooted for Win Updates. When I try quick tests it doesn't seem to trigger - if I start 1 IDE ... go do stuff ... then sit down and start another is when I saw these things most regularly - perhaps partly from rushing and partly from not remembering where I was.

In starting a couple times I have had to unplug one or both Teensy's and push a button to program. Sometime I saw an orange message in the IDE - other times tLoader would note a bad CPU cross programmed. That may have been from starting two IDE's and overlapping the builds - or not putting the Port right so I was hoping to see it repro under normal conditions and have not. It may have been those 'confusing' times that aborted a Tsermon and started another? Somehow the IDE saw fit to complain that it couldn't find the Teensy there - would that cause a new instance of Tsermon? Having a Loader/Verbose log would probably show that - but I didn't save that unfortunately, but it is generally working and usable.

There are ways a user can do the wrong thing - and the wrong thing happens given the tie to the IDE to TeensySermon and TeensyPorts under Java with Loader being external. The way koromix has one external app for sermon and loading provides a cleaner user model that avoids that contention as it is removed from the Arduino IDE … for better and worse not being part of the IDE as you are supporting.
 
Anyone else on Windows seeing teensy_serialmon get stuck/orphaned and consume CPU time?

It's been running for 7 hours on my clean test machine. No problems, and I'm guessing none will happen unless I somehow turn this into a heavily used machine and myself a Windows user!

Really depending on Windows people for feedback on this one...
 
not me, but like i mentioned i run SSD in my pcs. The problem with windows and harddrives (HDDs) is sometimes the cpu can be below 5% usage while HDD is taking 95%+ usage time, while that happens other resources are in a locked/wait state because cpu is waiting for HDD data and, in the case of opening/closing the IDE I would suspect the process isn’t spawned/killed fast enough before the next instance.

example, a “clean install” should theroetically work better than, not say a bad install, but a resource dependant install... as the HDD is accessed less often

There is another possibility on a slow system that what if a user (and it happens on occasion) double/tripple clicks the IDE and the IDE starts opening 3 times, and it takes awhile for it to load the IDE

im running windows 8.0 on daily PC that runs daily and the install was done 8 years ago
 
Disk activity isn't a problem. I've had more bad luck with SSD's than any sign of utility. This machine boots from HDD - but All Arduino/Teensy is on an SSD - and system temp and page file redirected to SSD.

Before I was running the debug test stuff that goes to fault and the 'unique' keep alive code from the ifdef'd OUT code in core - but now running simple sketch above - and both are back to Serial.

Part of the problem potentially is with 'doing it over time' in that I may come back to do the 2nd half I don't always do all the steps in the right order to set Board&Ports perhaps - and maybe start one compile/Upload where the second collides with the first directly or indirectly. But not sure it is always either of those exposing some race condition.

I just forced two compiles to collide - one a bit before so it was performing upload as the second tried the same - No Problem - except TLoader complained about the wrong HEX. TLoader says 23% on code - which means it should be T_LC code - but it was really trying to program the T_3.6. So I replugged T_LC to run and Button pushed T_3.6 then it programmed that. Then Upload to T_LC works. And all is as it should be.

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.

I repeated the 'IDE Serial Monitor' icon click during compile - open copy closed - new copy came up - and now there are two TSermon on that IDE - but both 0% CPU. ORGANE IDE debug shows: "Unable to open COM11". When I close IDE #1 then IDE #2 - Tports closed okay - but there is an orphaned Tsermon at 29% CPU.
<EDIT>: BTW - I took the T_3.6 back to RAW_HID for this compile - so the 'Port' connection would have changed when it came back. Though I think this was the 2nd Upload in that state so that may not have been it? And I saved a huge 2 MB log that had to be zipped: View attachment XTsermon_log.zip

I have not been trying to click that Serial Monitor icon during compile {except above when it worked} - but normally clicking it while active just brings the window forward. During compile I now see it is closing the 'offline' one and then opening a new window? But given the 'inactive' state of the 'offline' window it may just be cleared and then not redrawing?

As noted TaskMan is not tracking/displaying processes - during compile when the TSermon goes offline that process disappears from the list? Depending on how the code checks for running copy of a program - it may also return FALSE when in fact there is an instance running?

I'm wondering if a solution may be not to de-activate the (offline) TSermon? I find it rude that I cannot select and copy text when it is in that state, when the onscreen text in the case of the Teensy going offline is something I may want to copy.
 
Last edited:
With the T_3.6 in RAW_HID mode the Tsermon does not go offline during compile. This seems nice [see prior post]. Is this expected? - I thought it worked earlier.

However I got this note in the single IDE:
Error opening HID device
Windows Error Info: The process cannot access the file because it is being used by another process.
Teensy did not respond to a USB-based request to enter program mode.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.

Button press did program. I was typing in to the Tsermon - as you'll note I added USB input processing for the posted base sketch to show the USB system fully working IN and OUT.

Okay - it does not go offline - I was not touching the Tsermon window and get this again.

This is not new - IIRC from TeensyTransfer days - but RAW_HID misses the first lines from setup - even with 8000 sec wait - it is running faster so if must show as true (Serial)
 
Last edited:
cannot select and copy text when it is in that state, when the onscreen text in the case of the Teensy going offline is something I may want to copy.

I too have wanted this on several occasions.

But no more GUI changes will happen for 1.42. Sorry, we're just too late in 1.42 testing for this sort of change. It will have to wait for 1.43.

Please put this on the suggestions forum. If I forget about it, remind me at the first 1.43 beta.
 
Status
Not open for further replies.
Back
Top