Teensyduino 1.42 Beta #1

Status
Not open for further replies.

Paul

Administrator
Staff member
Here is a first 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. Selection of these ports is by physical location on your computer, so as Teensy changes, the same physical location is suppose to remain selected.

The serial monitor is also new, when using these ports. A helper program named "teensy_serialmon" is used to talk to the hardware. This is meant to solve the dtr/online issues with Windows and the flaky Java serial communication on Macintosh, and allow the serial monitor to automatically reconnect in more cases.

The new ports menu is not yet used by teensy_reboot or Teensy Loader. I plan to add this soon. Please understand this is not done yet. Arduino still fundamentally supports only 1 selected port as a global setting. Please understand extending Arduino for multiple ports is outside the scope of this work. Please, let's not get distracted with talk of multi-port capability in TyQt (looking at you Defragster). Perhaps in the future I will hack Arduino, but for now the effort is going into this improved port detection and serial monitor connection to get away from the Java serial bugs.


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


Changes since Teensyduino 1.41

Add teensy_ports program and Tools > Ports "Teensy" section
Add teensy_serialmon - used for Serial Monitor when a "Teensy" Port selected
Fix USB Touchscreen
Add USB Touchscreen examples
Fix FlightSimFloat on Teensy 3.5
Fix USB bcdUSB number
Fix KEY_MEDIA_RANDOM_PLAY
Update OneWire, PS2Keyboard, SerialFlash, Time
Update PS2Keyboard


Known issues:

Only Arduino 1.8.5 has new Ports / Serial Monitor code
teensy_reboot does not use Ports menu yet - first/random Teensy gets auto-reboot
Teensy Loader does not use Ports menu yet - first/random Teensy gets upload
serial monitor title bar gets wrong info as device changes occur (maybe only on Windows?)
serial monitor slow updates (but still works) some cases, like 2ms delay between Serial.print
auto-restart of sketch on Teensy 2.0 not working
teensy_serial may get "stuck" and remain running, maybe 100% CPU usage
serial monitor might have leftover output from prior session when device reopened
teensy_ports may remain running after Arduino exits (Mac & Linux)
Windows XP - teensy_serialmon gets "partial USB device discovery" in some cases :(
Teensy model (2.0, LC, 3.2, etc) only show in Ports after uploading
 
If you want to see info about what the new helper programs are doing, both support verbose info.

For teensy_ports, you need to run it in a terminal window *before* starting Arduino. Add a "-v" to the command line, like "teensy_ports -v". The first thing it does is check whether another instance is already running, so you need to start it before running Arduino. You should see it print lots of info when USB devices connect and disconnect, and a bit of stuff every time Arduino queries for the known ports.

For teensy_serialmon, you can turn on its verbose info from File > Preferences. Select verbose output during upload. You'll see it spew lots of into as red messages in Arduino's console panel. On the next beta I'll probably remove of the more excessive stuff...
 
Ran - issues of course because I have a T_3.0 and a T_3.6 online.

First the error was RED in IDE - about failure to talk to COM 5 - which was the T_3.0 attached to SerMon.

So then I pushed button on T_3.6 where the code was to go, and I got a popup for wrong device.

So I went with that and recompiled sketch on T_3.0 - except forgot to change the device in the IDE - so I got notice about that.

I switched to TYPE:T_3.0 and the thing is in perpetual HID, and I can't reprogram it from IDE even now that the T_3.6 is unplugged.

td142_T3.PNG
View attachment td142_T3.txt

There is that much for now. Going to restart IDE and see if the T_3.0 can be programmed.
 
It could have gone better - had I remembered VERIFY and button push with multi-Teensy ... let me know if this adds anything useful.

Maybe a WARNING or do not do AUTO upload when you see multiple Teensy unit online? Wait for BUTTON, or suggest VERIFY and BUTTON?

IDE reprogrammed the T_3 after restart and recompile with it as the only device.

Here is Teensy_ports -v before and after reprogramming then plugged in T_3.6

Turns out the T_3.6 did get programmed at some point? Maybe the first time when it programmed the T_3.6 on COM 10 then gave the fail to access notice because it didn't close SerMon? I can tell because the F_BUS update to 120 on T_3.6 on my other install not done - so the IMU i2c unit fails on startup now at 240 MHz.

View attachment td142_T3_ports.txt
 
I can't quite understand what you're saying. I see you had a Teensy 3.0 and a Teensy 3.6 connected.

You got some error about COM5, but I can't parse much info about this error other than it was the color red and it involved the Teensy 3.0. Then you tried to use the 3.6 and more stuff went wrong, though it may have been only due to having the wrong board selected. Then the Teensy 3.0 wouldn't program.

I probably should have waited to share this until the new port location stuff was being used to reboot & upload. As things are right now, partially implemented, it's probably just too confusing to get any useful feedback (like whether the DTR / !Serial thing is better, or the 2 second delays are solved, or reconnecting the cable problems are better or worse).

I also need to do much better at logging. Making all this stuff work seamlessly as little pieces that work through Arduino is a huge challenge....
 
hi paul, ive stumbled on another serial issue not related to this new teensyduino yet as im not home to try new one yet
if i flood the usbserial so fast and for hours, eventually the serial data stream stops in serial monitor, even if i reconnect with putty, but it doesnt stop the hammering between teensy and the ESP8266 (which suggests its not a lockup) if i press the program button on teensy 3.6 and it auto reuploads last sketch without touching anything else, usb serial comes live again. i presume this is a serial issue as other terminals go blank as well with usb serial( well not blank, just dead stop, without the rest of the micro stopping it’s code. if i piggy back the rx line of the ESP, i can clearly see teensy hammering the the ESP while USBSerial is at a dead output, although, it keeps it’s online status

just throwing that up here before i get home later
 
Since I never had problems with the so called OSX serial bug, I can't tell anything about that. But I discovered another pending problem, which is not immediately blocking but will be soon: When I installed Teensyduino on the newest macOS beta 10.13.4 (17E150g), I got a warning that this app might affect the performance of my Mac... I did a little research and found that comes because it's still a 32bit app which the Apple people are about to ban completely with one of the next macOS releases. Thus, you should think about re-compiling it as a 64bit app...
Capture d’écran 2018-02-19 à 17.53.48.png
 
Paul: It was confusing for me too. Indeed twin Teensy 3 and 3.6 were online. I should have remembered to do Verify and Button.

The confusion started when it seems it did program on the COM 10 T_3.6, then tried to reconnect on the COM 5 Teensy 3.0 - which was still active? That is what I understood the 'RED IDE message' to be, but hit Ctrl+U again before recording it.

It seems then the first random Teensy moved to the T_3.0 and failed to leave it online/restarted) after refusing to upload to it, and it left it tied up in some fashion such that the T_3 would not restart until the IDE restarted.

It wasn't a good test situation - but it was where I was - using TyCommander to get USB data from both Teensy's ( where one is a Serial Proxy/FTDI for other debug data ).

As noted - when multiple Teensy's are present until the port specific is working - perhaps pop up : 'Use Verify and button press' - if that would work.
 
I've just started using it. I noticed some issues when connecting to teensy 3.2 as a serial port where data was already streaming - after initial connection it would sometimes miss an end of line character and display one line of data in line with the previous one. It only happens once when you first connect and not every time. Using Win10 and teensy 3.2 with arduino 1.8.5.
 
I'm working with Windows 7 right now. Haven't seen anything like this (and I've tested quite a lot with programs which repeated send 1 line of text with a number counting up). Will re-image my test machine to Windows 10 tomorrow. Can you give me anything more to go on? Maybe the timing could matter?
 
I'll try and replicate the issue - sorry if my description was a bit vague but I noticed it whilst I was racing the clock trying to debug something else that was causing a headache for a work project (which turned out to be a bug of my own making!). I was sending data lines with around 150 characters at 10Hz . . .
 
I also had one crash that forced me to quit the Arduino IDE completely as well (The tools menu stopped responding but I could quit the app by clicking the close icon) but I can't remember the exact circumstances other than that I was repeatedly uploading code with the serial monitor open and then using it to send commands as soon as it became active.
 
Ok, I've reproduced it. I have some code that prints at 20Hz, it starts printing as soon as it boots up and doesn't use any while(!SerialUSB){} loops to wait for the serial monitor. Both times I had the serial monitor open and uploaded code. The first few lines that appear are like this:

0 Ints: 0 STPR 0 TargetRPM: 0.00 PulseF: 0.00 CurrentRPM: 0.00 RPM-DT: 0.00 RPM-Accel: 5.00 SpdCmd: 0.00 Steps: 0 State: 0 Period: 10000000 Dir: 0
1 Ints: 0 STPR 0 TargetRPM: 0.00 PulseF: 0.00 CurrentRPM: 0.00 RPM-DT: 0.00 RPM-Accel: 5.00 SpdCmd: 0.00 Steps: 0 State: 0 Period: 10000000 Dir: 0
2 Ints: 0 STPR 0 TargetRPM: 0.00 PulseF: 0.00 CurrentRPM: 0.00 RPM-DT: 0.00 RPM-Accel: 5.00 SpdCmd: 0.00 Steps: 0 State: 0 Period: 10000000 Dir: 0
3 Ints: 0 STPR 0 TargetRPM: 0.00 PulseF: 0.00 CurrentRPM: 0.00 R10 Ints: 0 STPR 0 TargetRPM: 0.00 PulseF: 0.00 CurrentRPM: 0.00 RPM-DT: 0.00 RPM-Accel: 5.00 SpdCmd: 0.00 Steps: 0 State: 0 Period: 10000000 Dir: 0
11 Ints: 0 STPR 0 TargetRPM: 0.00 PulseF: 0.00 CurrentRPM: 0.00 RPM-DT: 0.00 RPM-Accel: 5.00 SpdCmd: 0.00 Steps: 0 State: 0 Period: 10000000 Dir: 0
12 Ints: 0 STPR 0 TargetRPM: 0.00 PulseF: 0.00 CurrentRPM: 0.00 RPM-DT: 0.00 RPM-Accel: 5.00 SpdCmd: 0.00 Steps: 0 State: 0 Period: 10000000 Dir: 0
13 Ints: 0 STPR 0 TargetRPM: 0.00 PulseF: 0.00 CurrentRPM: 0.00 RPM-DT: 0.00 RPM-Accel: 5.00 SpdCmd: 0.00 Steps: 0 State: 0 Period: 10000000 Dir: 0

The numbers at the start of each line should be sequential but you can see that line 3 gets cut off and replaced with line10, so lines 4-9 have been dropped.
 
I've spent the last couple days working on much better logging. With a little luck, when confusing problems like those described in #7 and #15 happen, we should have a good chance of getting useful info from the Teensy Loader's Verbose Info window. The other programs like teensy_ports, teensy_reboot, teensy_serialmon will all send their verbose log info to Teensy Loader, so it'll be easy to get a comprehensive log of everything that actually happened with one easy-to-use GUI.

Regarding the concatenated lines, are you seeing this problem only at startup of the serial monitor? Does it ever happen after the window has been open for a while? My current theory is there's a lingering buffering problem. Might be buffering in teensy_serialmon, or could be buffering in the PC-side drivers, or it could even be buffered packets on the Teensy side.

@tonton81 - Any chance for a program that I can run on a Teensy here without an ESP to recreate the lockup issue?
 
sorry to get back to this issue, it wasnt a problem with teensy or ide, my ssd was running out of space, i think the java fills up with the stream and fills up the memory and then collapses or something, i deleted a few gigs and hasnt went down yet, im currently working on the spi port so the ESP is having a little rest, so the issue was most likely due to lack of storage space
 
I've only encountered it after compiling and uploading code when the serial monitor is already open. It only happens to that particular line - Visually what happens is those first few lines all appear at once after a very brief freeze. I certainly agree that it looks like a buffering issue, but as far as I can tell it only affects the first second or so of operation when reconnecting the serial monitor.
 
I've just run another test and established that the issue will always occur IF the number of characters on each line is greater than 127 (including the newline character) - any less than this and it displays fine.

I used the following sent at 20Hz. If you add one more character to the last string it will produce the issue on my machine.
USB.print("abababab");
USB.print("abababab");
USB.print("abababab");
USB.print("abababab");

USB.print("abababab");
USB.print("abababab");
USB.print("abababab");
USB.print("abababab");

USB.print("abababab");
USB.print("abababab");
USB.print("abababab");
USB.print("abababab");

USB.print("abababab");
USB.print("abababab");
USB.print("abababab");
USB.print("ababab"); //Add one more character here
USB.write('\n');
 
Ithe issue will always occur IF the number of characters on each line is greater than 127 (including the newline character)

Thanks for this detailed report. It's a huge help!

Right now I'm working to convert teensy_reboot to use the new location info. Also hit a bug in the new merged verbose info logging... so lots of code open right now on my desktop!

Will look into this one later today.
 
No problem - I had a hunch about the 127 characters ... - Its not a major issue and so not urgent from my point of view, and the new version looks great in all other respects but I will report back any other issues I encounter.
 
I'm debating whether to publish beta2 today, or wait a little longer.

@Defragster - would you like to give this another try?

I've now updated teensy_reboot.exe to use the location info, so it should always reboot the selected board if you've chosen one from the "Teensy" part of the ports menu. If you select from the "Serial" part, it's still considered only a suggestion. The location info isn't (yet) being used by Teensy Loader, so there are still some unlikely cases where the wrong board could get used, like having another board sitting in bootloader mode with Teensy Loader's auto mode switched off. But it should now be much better for using more than 1 board.

As you can see in that screenshot, Teensy Loader's verbose info window now collects details from the other utilities. Hopefully this will pave the way for easily reporting problems and me being able to solve them.
 
Status
Not open for further replies.
Back
Top