Teensy Qt

--debug would be handy since we've done this twice now. Though by now I should be making my own version.

OS X - OS/2 - who cares - probably more people still using Win 9x and Win 2000 and COBOL or Windows Phone than OS X.
OS X is one third of the downloads, and Windows the other two :p By this logic, Linux would be the first to go but that's what I'm using and liking the most. And I'm an idealist on the multi-platform issue, if I had a little more time I would work on an absolutely useless FreeBSD/PC-BSD/DragonFlyBSD port :)

I'd love to port this to Android and iOS too, but realistically I just don't have the time, and I doubt I will for at least a year. In computing terms, this is close to the end of time itself. I'll try to release 0.7.0 in the next couple months to bring some new features and fix a bunch of issues. I doubt much will happen after that.

EDIT: of course in the next week there will be 0.6.4 to support Teensy 3.2.
Last edited:
Interesting stats on the downloads! Would have expected more Linux - at least I picked the RIGHT one :( Will look for the getting the update as I can and let you know it is working as I use it.
I've just released 0.6.4, the only real change being support for the Teensy 3.2 (untested, since I don't have one) and some back-end changes related to the firmware compatibility check. The previous code assumed each firmware only worked with a single board model, which is not true anymore.
I downloaded from GitHub the 0.6.4 version and have it open on four Teeny's - two 3.1's and two 3.2's and all looks good!


<feature request - keyboard shortcuts are great - can you add Ctrl+C for CLEAR of the 'Monitor' data? Tough to reset and clear quickly and effectively with right click>
<feature request> It would be very useful to have a feature where you can dump output (or output and input) to a file. Right now I copy paste from the Monitor window to a file, then save it. This is just to save me firing up N instances of putty or teraterm, because TyQt is so useful for doing the reset/reload thing.
Copy / paste is what I do - works well enough. Koromix did a great job on TYQT as a learning experience but doesn't have plans to expand on it.

I find it to be one of the good things about Teensy as it fills in gaps of the IDE with multiple monitor windows and the reset/reload thing for multiple Teensy's is critical and missing from Teensy loader.
It's true although I would love to expand on it, but I just don't have the time to go deep into code. Small stuff should be okay though. 0.7.0 is pretty far along with a few changes (both UI and back-end), and dumping into a file does not seem like a complicated thing to add.

So I guess I'll add it, and try to release 0.7.0 in the next month. I'm not sure how to put it into the UI (I'm a fan of avoiding settings dialogs if I can), but this is what I'm thinking about :
Capture-TyQt - Teensy - 714230@usb-8-2-2.pngCapture-TyQt - Teensy - 714230@usb-8-2-2-1.png

I'll also add a key shortcut to clear the Monitor, but I'm not sure which one to use (Ctrl+C is copy). Maybe Ctrl+B (blank)?

And something like this to send files?
Capture-TyQt - Teensy - 714230@usb-8-2-2-2.png
Last edited:
How about ABUSING Ctrl+X for CUT? Maybe even do a select all first?

I tried to get you off the hook - may as well make it perfect now.

Oh yeah - it has Clear on reset - on the Upload page - Settings tab is nice. Easier to find settings I forget I've seen. That seems like it might be on the main page by echo, as it is selective.

Finding the last IDE uploaded "C:\Users\defragster\AppData\Local\Temp\build659422687681598528.tmp\qBlink2k_sketch_sep25a.cpp.hex" to save would be nice.

Does the SEND button replace 'enter' key when you don't hit the dropdown part? A mouse clickable enter would be nice

You could autoname the files 'serial#_DateStamp' and put in a random directory and dare the user to find it and skip the UI.

Sending a file -as shown- would be cool - Send macro strings?
Would it be easy to have TYQT 'disconnect USB' to a selected device and ignore it? There are times I want TYQT open for say multiple Teensy's but would like a given Teensy to not be OWNED by TYQT - perhaps I want IDE SerMon to work for some reason. To do that now requires closing TYQT for all Teensy units.

In parallel with this - and because REFRESH is cool - you could add a Refresh button where it would rescan and connect any Teensy that is alive on USB, including one marked 'disconnect'

I just offered TYQT as a possible solution on this apple problem thread and in that case the OP will want to have his own APP own the USB at times. Hopefully TYQT is what he needs. As I read the OP though he wants to toggle from APP USB to a SerMon program - and right now the newest apple OS is not letting him work smoothly with other SerMon apps.
I tried your software today, I have 11 Teensy's, It only seen the 3 that weren't on a hub. Is that normal?

I don't think I tried over 5 yet, most all on a hub,it worked.
OS Windows? Do they show in Dev man?

Did you repower them after starting tyqt? Are they all running as usb, factory fresh don't.
I don't think I tried over 5 yet, most all on a hub,it worked.
OS Windows? Do they show in Dev man?

Did you repower them after starting tyqt? Are they all running as usb, factory fresh don't.

I am using WIN7, They all show up fine in the devices tab as Teensy's None are factory fresh, all have custom code. Now they are programmed as FlightSimControls thru Teensyduino
Are they running USB interface code or something else for the controls?

USB All 11 are programmed with same Teensyduino FlightSimControls. Only the ones NOT plugged iinto a Hub are recognized by the software even though WIN7 sees all of them fine as Teensy's
Odd. Can you program them all with a button press? Hubs are part of fixes and problems sometimes. Suppose you tried the hub with just 1 or so attached and other games like a different hub?
Mmmh, what model/vendor is this hub? Is this a USB 3.0 hub?

Next week (where I will have some free time) I will add debug statements to the Win32 device code, to make this easier to investigate. This is probably a failure of the device location code, which identifies the USB port the Teensy is on. In my great wisdom, I made a lot of these errors completely silent in the Win32 code (unlike in the OSX code), to avoid false positives.

Still, to help locate the bug: does it make any difference if you plug a Teensy while TyQt is started versus starting TyQt with all the Teensies already there? The cold device detection and the hotplug detection use different code paths on Windows.
Koromix: Really appreciate your work - Please do more :)

I'm trying to debug with USB output a scenario where the Teensy Goes offline at some point. The USB leaving can exhaust the timeout before I can view or capture the output. Working with Frank's SD Bootloading code and it takes about 5 seconds of no action to see the reboot, just after that the data is flushed.
> Could a way [setting checkbox] to hold the monitor data indefinitely be made to hold the OFFLINE Teensy data on screen in the app?

Also - same project - I am wanting to 'Send data...' over USB
> Where do you set the focus (on the tabs?)? Could it be set to the data entry box when the Monitor window selected or Teensy arrives?

When HEX file upload is used - do you do that or work through TeensyLoader? I can investigate somewhat - but am looking at the SD Flashing and about out of time. I got the feeling when I used TYQT to flash a HEX file it may not have worked properly, so I stopped using it.
Yes, I have my own upload code. Nothing fancy, it's probably the oldest code in there (adapted from teensy_loader_cli, it was called teenload at first before I added all the fancy stuff) and everything else grew around it. I've tested it quite often with various firmwares, never had any problem.
I'll do some more trouble shooting over the next couple of days. I have 3 different hubs in my system so I don't think brand or speed would matter since none of the Teensy's on all 3 are not recognized. Just a guess though.
I have uploaded a temporary build for OS X El Capitan (Apple changed some things in the USB stack and it broke the location resolution code) on Dropbox. It is also usable on other OS X versions, hopefully without any regression but I've tested it on Mavericks so I am confident.
=> https://www.dropbox.com/s/jharipxe07cumt7/TyQt-0.6.4-4-gce5de81-osx.dmg?dl=0

I'll do some more trouble shooting over the next couple of days. I have 3 different hubs in my system so I don't think brand or speed would matter since none of the Teensy's on all 3 are not recognized. Just a guess though.

Before the end of the week I will upload a build with some Windows debug information built-in, so you should wait for that.
@raflyer: here is a small package to help me debug device enumeration issues on Windows: https://www.dropbox.com/s/tltv0z16hckufjl/hs_debug.zip?dl=0

Extract the hs_debug directory, and run debug.bat with the Teensies plugged in the problematic hub. Then unplug one, wait a couple seconds, replug it, wait a few seconds again and press ENTER in the console window to stop the program. Than you just need to copy-paste the result (in debug.txt, it should open automatically when you close the debug program) here.

Hopefully it will capture whatever is wrong in the code :)
Last edited:
Installed it 2 days ago on my MacBook Pro and it worked perfectly out of the box.

Now I didn't read the full licence thing (tldr) but I wonder if there is a legal way to deploy it as a firmware updater with a Teensy based product and if there is a way to customize things a little, for example not displaying "Teensy 3.1" but a custom name, and which fees would apply?
It's the Mozilla Public License (MPL) 2.0, which in effect is similar to the LGPL but without the annoying dynamic/static linking mess. So far, 100% of the code is mine and I have been seriously considering switching to the MIT license because I don't really care what my code is used for, for me it's really about the fun of programming. Also, thinking about licenses annoys me.

So really, you are free to use it to use it for whatever you need. At this point, I'm pretty sure I will relicense it soon, and also get rid of that annoying license prompt in the OS X bundle.

It's relatively easy to build, the main obstacle is the dependency on Qt. I build a static version of the qtbase5 libraries, and it's not as easy as I'd like to, and not completely integrated into my build system. Of course the command-line version does not need Qt. I guess you could pilot it from your own GUI instead.

The master branch is stuck into a messy, half-refactored state. After letting it rot away for some time due to lack of time and energy, I did force myself to fix it a few days ago and it's looking good now (even though I haven't pushed anything yet, gotta remove the remaining FIXMEs I littered around in my workspace). The maintenance branch is where the stable and working code lives, for now.