Teensyduino 1.45 Beta #2

Status
Not open for further replies.

Paul

Administrator
Staff member
Here is a second beta test for Teensyduino 1.45.


Linux 32 bit:
https://www.pjrc.com/teensy/td_145-beta2/TeensyduinoInstall.linux32

Linux 64 bit:
https://www.pjrc.com/teensy/td_145-beta2/TeensyduinoInstall.linux64

Linux ARM: (coming soon...)
https://www.pjrc.com/teensy/td_145-beta2/TeensyduinoInstall.linuxarm

Mac OS-X:
https://www.pjrc.com/teensy/td_145-beta2/TeensyduinoInstall.dmg

Windows:
https://www.pjrc.com/teensy/td_145-beta2/TeensyduinoInstall.exe


Changes since Teensyduino 1.45-beta1

Add 256 MHz Teensy 3.6 to Tools > CPU Speed menu
Fix asm in delayMicroseconds on Teensy LC (Frank B)
Audio: Fix ADAT output with 168 MHz (Frank B)
 
Win 10 - good install with 1.45 Beta #2 and indeed FrankB's 256 MHz speed change is selectable and usable.

Did the order under 'Tools / Port' change so that IDE 'Serial ports' is listed before 'Teensy'? I wondered why SerMon stayed Offline after a Button upload.

Works well to reconnect when the PJRC Teensy_ports owns the port after Button upload, not so with IDE SerMon Serial.
 
Thanks for testing. :)

Did the order under 'Tools / Port' change so that IDE 'Serial ports' is listed before 'Teensy'?

Yeah, looks like the Arduino devs changed some stuff. It was never in any particular order. The Teensy specific ports used to end up first due to something about the order of instances created and updated elsewhere, probably in the DiscoverManager stuff.

With T4 beta about the begin, I'm trying to avoid hacking the Java code or any other low priority work which can be put off until next summer.

Hoping to wrap up the 1.45 release Monday or Tuesday.
 
Thanks for testing. :)

Yeah, looks like the Arduino devs changed some stuff. It was never in any particular order. The Teensy specific ports used to end up first due to something about the order of instances created and updated elsewhere, probably in the DiscoverManager stuff.

With T4 beta about the begin, I'm trying to avoid hacking the Java code or any other low priority work which can be put off until next summer.

Hoping to wrap up the 1.45 release Monday or Tuesday.

:)

I wasn't sure about the order - doesn't matter - but at a glance I was about to Bug Teensy_serial for not working on the Button restart … then I saw the lower entry properly marked and it worked.

Indeed your T_4 schedule will give enough new work without getting caught up in stuff that always takes more than it seems and is hardly as critical or as widely rewarding.

IDE 1.88 seems okay without any major edits that caught me - so should be safe to call it working soon - glad I tested as I did.
 
Updated Win 10 Surface Book to IDE 1.88 and td 1.45b2 with no issues. Both are most recent Win 10 Fall 2018 update versions. And starting the IDE didn't pop the 'unknown' source popup on the Surface so it has become trusted it seems. Both use MSFT included 'Windows Defender' and Malwarebytes - no conflicts.
 
I'd remove the boards.txt 256MHz changes. This will lead to many questions as long the audiolib throws errors when compiling.
 
I'd remove the boards.txt 256MHz changes. This will lead to many questions as long the audiolib throws errors when compiling.

Perhaps comment the lines in place as needed so they are easy to use for non-Audio applications.

Or drop a speed tested warning in the AUDIO.h noting 240 MHz max supported.
 
Ok, will comment those lines in boards.txt for 1.45.

Not seeing any reason to hold up releasing 1.45. Will probably release it later today.
 
Unplugged T_3.6 and the T_3.6_K66 Beta still online.
Just plugged in a T_3.1 and uploaded - it worked. I had set Teensy_port to T_3.1 prior and opened the t_sermon.

Minor [non]issue? The console offers this text - not sure what to do with the BOLD part? I did that and there was no upload issue.
Sketch uses 19884 bytes (7%) of program storage space. Maximum is 262144 bytes.
Global variables use 4828 bytes (7%) of dynamic memory, leaving 60708 bytes for local variables. Maximum is 65536 bytes.
T:\arduino-1.8.8\hardware\teensy/../tools/teensy_post_compile -file=DebugMin.ino -path=T:\TEMP\arduino_build_261286 -tools=T:\arduino-1.8.8\hardware\teensy/../tools -board=TEENSY31 -reboot -port=usb:0/140000/0/1 -portlabel=COM13 (Teensy 3.2) Serial -portprotocol=Teensy
Previously selected Teensy port is offline.
2 other Teensy boards found. Please select
a Teensy from the Tools > Ports menu.

Moved Board Teensy and port back to T_3.6_K66b and t_sermon opened, above console text not presented on upload.

Moved Board Teensy and port back to T_3.1 and t_sermon opened, above console test not presented on upload.

Just to record it - here is Tloader_Verbose in case it tells you something :: View attachment td145b2_log.zip
{ lots of callback … } this started :: 10:35:13.605 (ports 5): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE

BTW: IDE closed and TaskMan shows nothing orphaned - Good!
 
Yeah, the Arduino port selection is less than ideal. We're juggling 3 different approaches. You can have a "Teensy" port selected, or a "serial" port selected, or nothing chosen at all. When uploading, those latter 2 cases try to automatically find a Teensy, without considering when else you've selected in the Tools menu.

Probably in late-2019 I'll pour another programming session into improving this. By then, maybe the Arduino IDE will look quite different... since they're trying to migrate more components to Google Go language.

Right now, I'm going to wrap up 1.45 and get back to work on T4.


On the WM_DEVICECHANGE messages, I'm afraid that's (probably) very normal behavior for Windows. MacOS and Linux udev provide change notices that are very well integrated with Apple's IO Registry and the Linux sysfs virtual filesystem. You can configure filters for the specific notifications you want. With each notice, you get very specific info about the changes within the device hierarchy. Microsoft has pretty similar hierarchical structure in their Configuration Manager, but there's pretty much no integration with Windows event messages. You don't get to pre-filter just the ones your application needs (or if this is possible, I've never managed to find it on MSDN), so Windows ends up delivering all sorts of unnecessary Windows event stuff. Pretty much no useful info is delivered with WM_DEVICECHANGE, like you get on MacOS & Linux (udev), so a tremendous amount of extra work is needed with complex SETUPAPI and Windows Registry stuff to figure out what changed. I'm going to stop now, before this turns into a rant about Windows....
 
Sounds good - especially cutting the rant off saving valuable energy not jousting at windmills :) … the old link noted suggests the devicechange was Windows feeling insecure about device access as noted if I read that right, other than clutter in the log it seems to allow full operation as I can see it.
 
After a few more releases, I'll probably prune most of that verbose info logging. It is a bit excessive, especially as the code becomes more mature.
 
Picked up my SurfaceBook and put the T_3.6 back on it - then added T_3.1 : that machine doesn't exhibit the callback select note, and it didn't present the console note about port select programming T_3.6 then the T_3.1.

Indeed it seems to have matured well. I closed all down on the SurfaceBook and TaskMan shows no orphans.

I found one of my links about the callbacks - but it seems there was another - some app is causing that on the desktop.
 
Installs on MacOS 10.14.3, Arduino IDE 1.8.8 but doesn't see any serial ports... No doubt a MacOS problem since the upload button doesn't work, but if anyone has any ideas, I'd appreciate it!

Thanks

David
 
My test Mac has 10.14.2 and checking for updates says it's up to date. If something broke with .3, I have no way to test it.

For testing, make sure the Teensy Loader windows is *not* in Auto mode (the green button on the right side of its toolbar), then press the button on your Teensy. This will put it into bootloader mode, where it is a HID device. It is NOT a serial port in this mode, so you should NOT see a normal serial device. Instead you should see "HID=16c0:0478...." in the Ports menu.

Here's how it looks in 10.14.2.

sc.jpg
(click for full size)

If you don't get the HID device in the Ports menu, check your USB cable. This test uses HID protocol, so it's a different driver than serial (and one that pretty much always works, since keyboard & mouse depend on that driver). Charge-only cables (only power wires, no data wires at all) from cell phones and cheap USB products are the most common problem.
 
Many thanks for you swift reply.

Turns out, it was the USB cable. And, no, not even a cheap, power-only one. A faulty USB cable - first in about 30 years, well, okay not 30 years of USB cables, but cables in general. Anyhow, now I can move on

David
 
Status
Not open for further replies.
Back
Top