Teensy Qt

Thanks Koromix, Copied the whole file list and that first build working in Win8.1!

Interesting Win7 would show the Ghost/Orphan COM# and Win8 gets stuck on the Ghost and stops showing like TYC does. In fact if TyQt is open TYC also quits on the Permission denied device.

Now I just have to clean and fix my Win7 box if I'm going to build with that.
 
Yes it's unfortunate, but Windows does not seem to allow the sharing of devices even if you open with the appropriates SHARE flags. Or maybe I'm doing something wrong but I can't see it. On the other hand I will make the code a little more robust and ignore devices that can't be opened due to permission errors, and perhaps check the already opened devices regularly. This way, ghost devices will at least be ignored.

It's not a problem on Linux and OS X, and I don't see a way around it short of reimplementing everything in a client-server model; this is not going to happen any time soon.
 
Just tried TyQt with TeensyDuino 1.22 and IDE 1.6.3:

It plays well with "1.6.3 IDE" then hit 'Bootloader' [HOUSE] in TyQt. That causes TeensyDuino to Upload the just compiled sketch to the selected device, Then the Serial monitor auto restarts!

When TyQt is running and 'takes' the Monitor port then TeensyDuino cannot see it. The 'Bootloader' is the best button to hit to get new code uploaded. Like hitting the device 'Button'.

> Works with IDE Upload - or Verify: pick the right device and new code is programmed and the monitor restarts.

> Restart works to restart the Teensy
> Manual Upload works if you have a saved HEX file

Upload works, but you have to manually walk to find the file you want
{ on Windows %localAppdata%\temp will get you to see build*.tmp dir the IDE uses }

Items:
> On Windows sometimes the port for monitor is not seen until the Teensy restarts
-- Having a way to open a named port in that case if possible would be nice
> Right click 'clear' on the Monitor is useful to purge old data
-- Checkbox to clear on restart would be handy
 
By any chance, is the Teensy Loader running when TyQt misses a device? A permission error could explain it. TyQt only responds to device notifications from Windows, it does not poll so if a device cannot be opened, it is ignored and stays that way. If it's indeed the problem, I will add some retry code to keep info about failed devices and try every x seconds. If it's not, well then it's a bug.

If you change platform.txt, you can use TyQt instead of the official Loader to upload code. This will bypass device conflicts. Of course, since the LC is not supported yet (until I get one), it's probably useless to you. Something like:

Code: 
## Teensy Loader
tools.teensyloader.cmd.path=C:/Program Files (x86)/TyQt/tyqt.exe
tools.teensyloader.upload.params.verbose=
tools.teensyloader.upload.params.quiet=
tools.teensyloader.upload.pattern="{cmd.path}" "--upload={build.path}/{build.project_name}.hex"

I have made progress on various functionalities for TyQt (pause, ignore device, board aliasing, firmware history), but nothing is quite finished yet so I have not pushed any of it. Unfortunately, my free time is very very limited right now, and will be until the very end of May (trust me, it annoys me). After that I'll work on fixing the bugs, enhancing TyQt and finally get Qt Creator integration but until then pretty much nothing will change.

The clear on reset exists :) It's hidden in the "Upload" tab, which is not very intuitive. It is closer to a "Settings" tab, maybe I'll rename it later on.
 
Last edited:
I can't reproduce the failure to see the device. With or without TeensyDuino active it will see it now.

It has been some time and some reboots since I ran TyQt (I think just before 1.22 started), it seems once it saw it restart it always finds it now. There may have been a Ghost port in the way. It was after I ran 'TYC list' it seems when it showed the device as 'blocked' in some fashion - I forget the text as I didn't think I had an issue then.

Good work on this! You may see my 1.22 note that Paul should give it a look when he thinks about changing the TeensyD UI.

Too many hidden features :) - I almost forgot the Right Click to clear! And I had never used the HOUSE icon for Bootloader but it seems it is the best one to not mess with TeensyD when you want code uploaded and don't want to push the button.

Until I try Visual Micro I think I'll be back to using TyQt again for the Multiple Monitors. Paul got Verify passing the HEX path to TeensyD for 1.6.3 - edit to platform.txt - so I won't have wrong device errors with upload like I would before when TyQt was holding the serial port.

Oh I forgot one add I may have noted before as part of the board aliasing showing the com# on the device tag might be nice - though that is of marginal value as it isn't really a fixed hardware port.

Good luck getting an LC soon - I'm not sure what I'll do with mine as the 3.1 is more awesomer - except as a logger or debug output device it has TWIN SPI to do a display and something else.
 
Okay, I received my LC just as I finished with my exams :) So I've just updated TyQt to 0.6.2, the only change is working support for Teensy LC boards.
 
defragster said:
Good luck getting an LC soon - I'm not sure what I'll do with mine as the 3.1 is more awesomer
Click to expand...

Yes, 3.1 has far more, but LC is pretty useful. Here's a couple serial-controlled 10 watt RGB LEDs, where I needed a quick way to send data at a particular baud rate.

led4.jpg

I guess even a regular 8 bit Arduino could do this, well, at least one with an unused serial port. Still, the LC is pretty handy for such things. ;)
 
I've been using the free version of Qt Designer for generating XML that gets instantly translated to Python. (I'm using Python 2.7 by choice). Qt designer, after 4 hours of fumbling as a newbie, is great. Not locked into the grid concept but rather it's like MS Visual Studio's GUI design tool.
Qt Designer says it also generates XML to C++, Ruby and maybe Lisp.

Good stuff.
 
Just downloaded the Win and MacOSX versions of TyQt.. Works great, but...
A couple questions:

1) the serial number seems to be derived from the low order 2 bytes of the MAC (what I expected).. on a Teensy 3.1 it reports 10*decimal value of the 2 bytes: that is if the low order two bytes are F2:41, then TyQt reports 620170
2) for Teensy 3.0, it doesn't multiply by 10.

I suspect that this is something more in how the USB interface on the Teensy works than anything in TyQt.

It would be very cool if there were a way to open multiple monitor windows. For multi Teensy systems, we find ourselves opening multiple copies of some terminal emulator (putty, or the Arduino IDE) so we can see what's going on on all of them.
 
jimlux said:
1) the serial number seems to be derived from the low order 2 bytes of the MAC (what I expected).. on a Teensy 3.1 it reports 10*decimal value of the 2 bytes: that is if the low order two bytes are F2:41, then TyQt reports 620170
2) for Teensy 3.0, it doesn't multiply by 10.

I suspect that this is something more in how the USB interface on the Teensy works than anything in TyQt.
Click to expand...

The serial number is what is exposed in the USB descriptors. It used to be equal to the MAC address, but Paul changed the core code to multiply the number by ten as a workaround for a bug in the OSX serial driver. You can see more in the corresponding commit: https://github.com/PaulStoffregen/cores/commit/4d8a62cf65624d2dc1d861748a9bb2e90aaf194d

If your Teensy 3.0 uses an older Teensyduino version, you don't get that behavior. Or if the serial number (before workaround) is superior to 10000000, as you can see in the commit.

jimlux said:
It would be very cool if there were a way to open multiple monitor windows. For multi Teensy systems, we find ourselves opening multiple copies of some terminal emulator (putty, or the Arduino IDE) so we can see what's going on on all of them.
Click to expand...

You can do that already, use File > New Window. You can also toggle the minimized view in each window with View > Minimal Interface.
 
Last edited by Koromix; Today at 07:57 AM. Reason: Update to TyQt 0.6.3
Click to expand...

I pulled this TyQt update and put it on Win7x64 to good effect. After first boot/reset it can ID the Teensy type, multiple monitors open and reset of device from the TyQt window button!

I have it set up with one LC and one 3.1 on USB:
One time Oddity with 3.1? I hit 'house'/Bootloader and TeensyLoader once gave the 'board' error [LC .vs.3.1] - and it doesn't reset? I proceeded through LC then 3.1 and it worked fine the next time doing 'verify' then 'house' icon in TyQt. I'm wondering if this was Teensy or miscommunication on the device by TyQt?
 
Oh it should have been able to do all that before :)

When the Teensy reboots, the device goes away and another shows up on the same USB port. There is no way for the software to differenciate between an unplugged device, and a Teensy reboot or reset. What TyQt does is keep around the board data/info, and wait a little before dropping it (that's the greyed out board thing in the device list). If a device shows up on the same USB port before the timeout, with the same serial number and it's also a Teensy (compatible VID:pID pair), it's considered to be the same board. So TyQt keeps the knowledge of the model and all is well, it treats it as the same board.

The only problem with this is that on Windows, the new device can take very long to show up... so often when it did, TyQt had already dropped the board because the timeout was 3 seconds. I changed it to 7 seconds with this release, let's see how it goes now. I was relunctant to change it before but after testing the software a little more on Windows, I realized that 3 seconds was way too short. Even though oddly enough, in my virtual machine tests, it was often enough so that's why I kept the value for so long.

As for the bug you encountered, I don't know. The interaction with the COM port bugs Paul also gets and my general lack of knowledge on Windows debugging, means it's hard to know for me what goes wrong. I try to improve the Windows code here and there, and I even finally fixed the XP support (which took several hundred lines of additional code), but I have a hard time knowing if I actually make it better.

On the positive side, it seems the USB and serial bugs and delays are gone from Windows 10, or so it seems based on quick tests.
 
Last edited:
Koromix said:
Oh it should have been able to do all that before :)
Click to expand...

It did - I was just noting it for my first time summarizing the cool factor :)

7 sec delay will be better - though the old delay seemed sufficient. I got my Win8 machine to put an LC&3.1 both on Com3 - confused TyQt and IDE_SerMon not surprisingly. I noted that elsewhere yesterday - DevMan killed the devices and without reboot it came back working on prior TyQt 0.6.2.

As noted I'm doing dueling LC.vs.3.1 and I just saw that board conflict again - not sure again if it was Teensy confused as I rebooted 3.1 during TyQt 'house' press to upload last Verify build - or if TyQt had a 'static' ref to the last unit programmed. I have two instances of TyQt - one on the 3.1 and one on the LC and generally they are working well to restart and software upload after Verify without pushing the physical button. Doing the same device sequentially is okay, it seems to appear when changing instances/devices.
 
Just FYI..
I'm using Qt4 and Qt Designer 4.8.6 - with the GUI code written in Python 2.7.
The output of Qt designer is XML that depicts the entire GUI. My GUI is at the moment about 20 buttons, 4 scrolling text windows, one table matrix. Timer in the GUI, and so on.

The entire application is in Python modules/classes - all my application logic and all the GUI call-back events. And using python libraries such as smartCard, serial, networking.
So there's no platform dependencies in all of this. The GUI and all the libraries exist for Windows, Linux and Mac OS.
I'm using Komodo Edit for Python code.

Indeed, I've run the entire app on Win 7, Win 10, Linux Mint and RPi. I don't own a Mac. I have read that that Mac is the hardest due to the way they do graphics.

It's amazing to me. No C++ or C# in any of this. Real portability. Qt is a super well documented and well implemented GUI tool suite. Easy to learn.
This app talks via ISO7816 to an embedded system using an ARM M4 - that's a big and complex app, in ANSI C, with a tiny bit of C++, using IAR.

And for non-commercial (not for resale) work, these tools are all free. The commercial-use license prices are reasonable.
 
Last edited:
Koromix: Got 3.2's today - it see's it as Teensy - no 3.2 name of course just generic "Teensy". It allows 'Reset' - then comes up as "HalfKay Bootloader" : \\.\HID#VID_16C0&PID_0478#8&30268D6B&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}

Is this You or PJRC from what you know about the changes?

Haven't programmed them yet - not sure about what else to expect. Let me know if there is anything I can do to help with info.

<edit>: The second is not powering up right > as "Seremu" and "\\.\HID#VID_16C0&PID_0486&MI_01#9&C0273ED&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}". On "Reset" it looks like the first one as "HalfKay Bootloader", seems like the reset not completing?

<EDIT update> after I actually program with USB sketch: This behavior stopped after first sketch loaded - because the factory sketch has no USB connect I suppose.

It does note 'red' error : "Cannot reset board" - which clears and the buttons go back active. It does show what seems to be a valid serial # (as does TYC) [this is windows 10]

It can also initiate programming just fine 'with no "Cannot reset board"' and all else looks right.

BONUS:: I just noticed the GUI responds to 'Ctrl+Mouse_wheel' in the monitor window and changes the FONT size - like a good program!
 
Last edited:
The big question is, has Paul changed the HID primary usage value for the Teensy 3.2? When you push the button and put the Teensy in bootloader mode, what does TyQt say? Does it say "Teensy 3.1" or "Teensy"?

If you can upload, I guess it's the first one but there's an unused usage value (0x1F) between the 3.1 and the LC that I was suspicious about.
 
With TeensyDuino closed button pressed to bootloader I get this:
I:\tCode\Tmp\Custom\TYQT>tyc list
+ usb-1-1-3-3#1253740 teensy
Click to expand...
Matches the 'name' shown in tyqt - of course. There is something odd about the 3.2 - it went back to the 'halfkay' in the interface name - on tyqt software reset - with reset&upload disabled. That stopped after another upload though.

TeensyDuino Verbose exposes this for the 3.2 if it helps:
02:27:32: HID/win32: vid:045E pid:0745 ver:0634
02:27:32: HID/win32: vid:5664 pid:0930 ver:0001
02:27:32: HID/win32: vid:045E pid:0745 ver:0634
02:27:32: HID/win32: vid:5664 pid:0930 ver:0001
02:27:32: HID/win32: vid:5664 pid:0930 ver:0001
02:27:32: HID/win32: vid:1B80 pid:B409 ver:0131
02:27:32: HID/win32: vid:1B80 pid:B409 ver:0131
02:27:32: HID/win32: vid:1B80 pid:B409 ver:0131
02:27:32: HID/win32: vid:1B80 pid:B409 ver:0131
02:27:32: HID/win32: vid:045E pid:0745 ver:0634
02:27:32: HID/win32: vid:045E pid:0745 ver:0634
02:27:32: HID/win32: vid:045E pid:0745 ver:0634
02:27:33: redraw, image 9
Click to expand...

Though I doubt that helps as the same stream shows on a 3.1. And I see this in the verbose for a 3.1 and a 3.2 - so the (firmware?) version is not even changed:
Board is: Teensy 3.1 (MK20DX256), version 1.03
Board is: Teensy 3.1 (MK20DX256), version 1.03
Click to expand...

Windows 10 changed and the TEENSY units no longer show in DevMan that I can see [though it does a view refresh on any change] so I can't give you any data from that.
 
Thank you for the help. It's kinda weird, but the reset&upload disabled thing you saw is there on purpose, when the model reported by HalfKay is unknown. Could you temporarily replace libty.dll with this version and post me the output of "tyc list --verbose" with the Teensy 3.2 in bootloader mode?

At some point I'll definitely put some log/debug mode in there to make it easier in the future, and avoid sending you printf-enabled "debug" versions :)
 
Results on the T_3.2 In bootloader and then out - with copy of the T_3.1 to compare:
I:\tCode\Tmp\Custom\TYQT>tyc list --verbose
Unknown Teensy model with primary usage value 0x21
+ usb-1-1-3-4-1#1253740 teensy
- model: Teensy
- capabilities: (none)
- interfaces:
* HalfKay Bootloader: \\.\HID#VID_16C0&PID_0478#8&30268D6B&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}

// direct ref for T_3.1 on Win 10
* HalfKay Bootloader: \\.\HID#VID_16C0&PID_0478#9&129EB76&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}

I:\tCode\Tmp\Custom\TYQT>tyc list --verbose
+ usb-1-1-3-4-1#1253740 teensy
- model: Teensy
- capabilities: reboot, serial
- interfaces:
* Serial: \\.\COM5
Click to expand...
 
defragster said:
Results on the T_3.2 In bootloader and then out - with copy of the T_3.1 to compare:
Click to expand...

Thanks for sharing
I learn: primary usage value 0x21 seems now T3.2

I assume that there are no changes in teensyduino to download to T3.2, but would like Paul to confirm
 
I downloaded fine to the T_3.2 from 1.24b3 version I have in another directory. It seems from normal software points but one (the unique ID) - the T_3.2 is running and acting like a T_3.1
 
It's interesting, so maybe the report length is the same. I should have checked it with the previous DLL, but that's what you get for multitasking; everything you do is half-assed. Could you report the output of "tyc list --verbose" with this DLL in bootloader mode?
 
same length:
I:\tCode\Tmp\Custom\TYQT>tyc list --verbose
Teensy with usage 0x21 and report length 1089
+ usb-1-1-3-4-1#1253740 teensy
- model: Teensy
- capabilities: (none)
- interfaces:
* HalfKay Bootloader: \\.\HID#VID_16C0&PID_0478#8&30268D6B&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}

I:\tCode\Tmp\Custom\TYQT>tyc list --verbose
Teensy with usage 0x1e and report length 1089
+ usb-1-1-3-4-1#803580 teensy31
- model: Teensy 3.1
- capabilities: upload, reset
- interfaces:
* HalfKay Bootloader: \\.\HID#VID_16C0&PID_0478#9&129EB76&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Click to expand...

<edit>: not sure what is "--experimental" - but if you left his as a dump of diagnostic value while you are here you'd be ready for the T_#.x++ and other issues.
 
Last edited:
Thank you :) I'll try to put out a new release during the next week, but I've got to install OS X back first because I can't build an OS X binary right now.

I've wanted to put a debug option for a while, but it's always been a "maybe later" idea. A large chunk of this code and logic is two years old and back then it was just for me, so I just didn't need this kind of thing. I guess now is a good time (except for my lack of free time).

--experimental (for tyc and TyQt) just enables uploading to the AVR models, something I have never tested myself because I don't have any.
 
You must log in or register to reply here.
Back
Top