Teensyduino 1.40 Beta #3

Status
Not open for further replies.

Paul

Administrator
Staff member
Here is a third beta test for Teensyduino 1.40.


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


Changes since Teensyduino 1.40-beta2

USBHost_t3 keyboard improvements (Kurt, Frank)
Update Snooze (Duff)
Fix USBHost_t3 hub bugs (thanks Kurt)
Fix missing upload error messages in newer Arduino
Show warning for certain counterfeit boards, still allow upload
Fix race condition causing "Teensy Loader is unable to read your compiled sketch (r)"
 
Looking for feedback from non-Ubuntu Linux distros.

1: Does the installer run? It's now links to a newer set of Gnome/GTK libraries. Problems would manifest as not being able to run at all, due to missing libraries.

2: Does Teensy Loader appear when you click Verify in Arduino? It now links to libudev, and newer Gnome/GTK libraries. Problems would manifest as not being able to run Teensy Loader, due to missing libs.

3: Can you upload LED blink or any other program? USB devices are now discovered with libudev. Problems would manifest as not finding your Teensy, so no uploading possible.
 
Running Linux Mint 18.1
1. Installer ran
2. T-Loader appeared when I clicked verify
3. Upload without issue to Teensy 3.2

The sketch that I posted about in the beta #2 thread continues to run fine. It uses the serial monitor--also fine. :)

--Michael
 
It works on Fedora 24 (x86_64, 64-bit).

As I've been complaining about off and on since Teensy 1.31, the recent changes to Adafruit_ST7735 have not been merged in. In particular, INITR_144GREENTAB (for the 128x128 display) is not defined. According to github, this change was made on September 5th, 2014 by LadyAda:

I don't load the Teensy Adafruit_ST7735, and use the Adafruit version, but it would be nice in 1.41 that these new changes get merged in.
 
Last edited:
Installed on Windows 10 and works.

Sort of interesting, that when I do the upload now, the Teensy app launches but does not come up to the top of window chain, so you don't see the upload progress happen. I do hear the USB come and go sounds from Windows. Don't know what the right functionality should be, as now you may miss any feedback... Almost like you simply ran the teensy_loader_cli type program.

I ran the usbhost mouse test program and it builds and it works with my DELL keyboard :D including having an HP mouse plugged into one of the USB ports on the keyboard.
 
Installed on Windows 10 and works.

Sort of interesting, that when I do the upload now, the Teensy app launches but does not come up to the top of window chain, so you don't see the upload progress happen. I do hear the USB come and go sounds from Windows. Don't know what the right functionality should be, as now you may miss any feedback... Almost like you simply ran the teensy_loader_cli type program.

With TyComm - I don't use it enough to remember for sure Kurt - but I think that seems almost how I've seen it. It would get focus/attention on the taskbar - but not be brought to front. It seems I made note of that some releases back - it would flash on the taskbar but not come to front in Windows. Will install and see after download finishes.
 
Also installed on Headless UP board Ubuntu 64 bit using tightvnc server... - 1.8.5

Appears to work, programmed T3.6 with mouse example...
 
TD 1.40b3 installed fine on Win 10 w/IDE 1.8.5 - not stopped by Malwarebytes this time either. Ran the posted sample TeensyThreads & EventResponder Timer sketch no problem - it runs - and Teensy.exe does act differently from what I recalled - after first run - it just stays hidden and does not get focus now.

Notable news is that IDE SerMon being very effective at connecting - stopping and picking up on subsequent Verify uploads.
 
I ran the usbhost mouse test program and it builds and it works with my DELL keyboard :D including having an HP mouse plugged into one of the USB ports on the keyboard.

Do you feel like this is a reasonably stable point to publish 1.40, as far as Teensy 3.6 USB Host is concerned?


Sort of interesting, that when I do the upload now, the Teensy app launches but does not come up to the top of window chain,

That's the way it's always been intended to work. I'm really not sure why it was ever bringing itself above other windows. There's nothing I've done in the code to make that happen, but it is built on top of the wxWidgets toolkit. There's a ton of code in wxWidgets!

The one major structural change on the Windows size is how teensy_reboot runs. Long ago, Arduino would run teensy_post_compile and then also run teensy_reboot. But recent versions of Arduino made running 2 programs after compile much harder. Rather than patching Arduino, I added a "-reboot" option to teensy_post_compile to make it run teensy_reboot. So clicking Verify in Arduino doesn't use the -reboot option, and clicking Upload does.

Originally I used used ShellExecute() to run teensy_reboot. It worked, but it turns out running teensy_reboot that way causes its stderr output to go nowhere. Any errors or other stuff it tries to print never ends up in the Arduino console. Apparently Windows doesn't have any way to run another program and have it inherit stdin, stdout, stderr like Linux & Mac and all traditional Unix systems do. Or if it can do so, I don't know how.

With this latest beta, I changed teensy_post_compile to run teensy_reboot with CreateProcess(). Windows does have a way to create pipes that can be inherited and connected to stdin, stdout, stderr. The biggest difference here is that teensy_post_compile doesn't end when teensy_reboot begins. It has to sit there and wait, and read the pipe to get whatever teensy_reboot prints to stderr, and then send it to its own stderr so Arduino gets the messages.

I can't see why the way these console-only utilities are run would affect the Teensy Loader GUI. But both of them to open localhost connections to Teensy Loader to get status info. Maybe that's affecting things somehow?

Teensy Loader also got some changes, but that was mostly on the Linux side to use libudev, and adding the counterfeit warning message.
 
Do you feel like this is a reasonably stable point to publish 1.40, as far as Teensy 3.6 USB Host is concerned?
Probably. I will take a quick run again of the Mouse program and see if all of the mice/keyboards/PS3/PS4 work, so I can then remove most of them from my desktop...

I sort of wish the PID/VID stuff made it into the HID stuff, but I know that can make it for the next release. The one place that I would use something like this in code is for handling Joysticks. As for example the PS3 and PS4 map the buttons differently, especially on the 4 button area on the left... So for example if I decide to try to control a hexapod with joystick, would want to know which one to know how to map the buttons/axis. ... Note: with ROS using joysticks, Often include a mouse remapping program to stack to handle this. Something like: http://wiki.ros.org/joystick_remapper/Tutorials/UsingJoystickRemapper ... Maybe at some point may want to optionally add functionality to the Joystick code that we can detect which joystick and then put in a remapping function, to come up with a semi standardized order of buttons and axis.... But not for this release.

That's the way it's always been intended to work. I'm really not sure why it was ever bringing itself above other windows. There's nothing I've done in the code to make that happen, but it is built on top of the wxWidgets toolkit. There's a ton of code in wxWidgets!
...
Teensy Loader also got some changes, but that was mostly on the Linux side to use libudev, and adding the counterfeit warning message.
Yep as I mentioned it is hard to say what the desired functionality is... In most cases probably as you have it. If there is a problem, probably want to see the program as to know there is a problem.
 
Do you feel like this is a reasonably stable point to publish 1.40, as far as Teensy 3.6 USB Host is concerned?
Doing a quick round of testing. For the most part things are working fine.

One case I have run into is plugging in and removing devices multiple times, at some point it fails. I had tested several devices (Keyboard and maybe 4 mice) before I plugged in the Wacom tablet. Where it stopped responding. I also noticed the LED on the Wacom was not lit. So I restarted the program and the tablet worked. I then unplugged it, replugged it in worked. Repeated... It failed on maybe the 10th iteration.

Not sure if this is a timing issue and/or some resource not being reset or ???

But will continue to test other devices.

Finished testing: tested 4 keyboards, 6 mice, TLC as mouse, PS3 and PS4. Locked up 2nd time with Microsoft wireless... But maybe also I moved something wrong or hit program button (using T3.6 beta board for testing)

Notes to self:
Keyboards: Should figure out how to process non Ascii keys
a) Function keys/Arrow/Home/End...
b) Other keys: like on Logitech wireless pressing some of these, shows up as mice events? On Dell/HP don't show up as anything... Next to try Microsoft Wireless
 
Last edited:
I sort of wish the PID/VID stuff made it into the HID stuff, but I know that can make it for the next release.

I see you brought the device pointer into the HID parser class. I had planned on doing this, but I'm not quite sure how it will all work out for C++ multiple inheritance. KeyboardController is probably the one case where we'll want that, so it can use the boot protocol for the normal stuff and the hid parser for the media & power keys.
 
Yes - I found that for several of the cases like getting the PID/VID you needed to ask the device for information... Likewise for the strings.

As for multiple inheritance, I usually try to avoid it like the plague. Usually this ends up needing things like Dynamic casting and all of the run time support.

As for Keyboard. I keep wondering if it should be converted over to using the HID code like the mouse was... As for the media keys, it will be interesting to see how they are implemented. Do they generate events for the Keyboard object or are they another Interface? Obviously not something for this release. Maybe not for awhile as I can imagine this may be lower priority than getting some support in for other USB devices like FTDI. But I may take a quick look out of curiosity.
 
Running Raspbian 4.9.35+ on PiZero

1: Installer runs from command-line after chmod 755 - not from GUI mouse clicks
2: Teensy Loader does appear after compiling (kind of slow on PiZero)
3: Blink uploads and Teensies 3.2, 3.5 and 3.6 blink
 
Yes - I found that for several of the cases like getting the PID/VID you needed to ask the device for information... Likewise for the strings.

I merged the idVendor & idProduct functions for the HID parser class.

https://github.com/PaulStoffregen/USBHost_t36/commit/0e35681c48f6e2fb136a452b12de238ff9ae3bc4


As for multiple inheritance, I usually try to avoid it like the plague.

Me too, but it kinda does seem like the way forward for this particular case.

For 1.40 the last thing I want to do is mess with this. 1.41 is likely to be in December, so we'll have some time...


As for the media keys, it will be interesting to see how they are implemented. Do they generate events for the Keyboard object or are they another Interface?

Media keys are done on a separate interface. It's only because of a lame Microsoft Windows requirement. Apparently Microsoft has some sort of a special security measure that treats keyboard interfaces differently than everything else. As a result, all USB keyboards have 2 separate interfaces, even though the HID protocol was designed to do all of this within 1 interface, even within 1 HID collection.
 
Thanks!

It is interesting that it looks like the logitech one is done differently... Maybe why I am seeing mouse events show up on the display when I press the special keys... WIll debug more later to see what events are actually generated.

Now back to play!
 
Sorry for posting in a not perfectly matching tread.

I just ran TeensyduinoInstall.dmg (from "Download Teensyduino, Version 1.40" page) after running on OSX 10.11.6 and Arduino IDE 1.8,

When starting Arduino IDE I get "Unable to Load Java Runtime Environment"

Re-installed the current Java 8.150 still getting the same error.

Only unconventional setup detail, Arduino IDE is not running out of Applications folder, using a copy on a secondary drive.

Tried a prexisting virgin installation of Arduino IDE, getting same Java error message.
 
TeensyduinoInstall.dmg poisinging Arduino Java Runtime

Sorry for posting in a not perfectly matching tread.

I just ran TeensyduinoInstall.dmg (from "Download Teensyduino, Version 1.40" page) after running on OSX 10.11.6 and Arduino IDE 1.8,

When starting Arduino IDE I get "Unable to Load Java Runtime Environment"

Re-installed the current Java 8.150 still getting the same error.

Only unconventional setup detail, Arduino IDE is not running out of Applications folder, using a copy on a secondary drive.

Tried a prexisting virgin installation of Arduino IDE, getting same Java error message.

------------- Folowup --------------

Investigating further, I found running the TeensyduinoInstall.dmg seemed to poison 2 Arduino IDE installations, not just the one I pointed to?

I was able to reinstall a fresh copy in a different directory using the same 1.83 installer on hand, the newly installed copy runs OK, finds existing library.
The other copies still give Java runtime fail message. (btw it's on IOS 10.11.6)

Tried running TeensyduinoInstall.dmg on a newly installed working copy of Arduino, getting same "Unable to Load Java Runtime Environment" running it after install
.
I examined the content of the poisoned copy of Arduino, hoping to find some pattern:


Arduino.app content just modified by Teensyduino installer:

Info.plist
JAVA/ arduino-core.jar b4 (1,565,565) after install (1.567.482 Bytes) (should I copy over a stock copy to see if the error goes away?)
JAVA/examples/teensy dir
JAVA/hardware/teensy/avr dir
JAVA/hardware/tools/arm dir
JAVA/hardware/tools/ 6 teensy 'unity executables' & Teensy.app

Let me know if there is a simple test I can make for you...
 
I was installing into a copy of arduino IDE I had been running for weeks the first tine it fouled up. ( It's possible that there was an unused copy of the IDE installed in the Apps folder, which confused the finder's unverified author internet download security or your installer somehow, although I was not installing on or running that copy)
Just tried a 4th time installing and running a fresh copy of IDE (this time in proper Applications folder) BEFORE running TeensyduinoInstall, still getting the "Unable to Load Java Runtime Environment" alert next time I tried to run the IDE (that does seem more like a code corruption issue than a security system lockout.)

I least I have learned that one can reinstall the IDE and carry on, so the damage done is not so bad a setback)
 
Status
Not open for further replies.
Back
Top