Teensy Qt

[defragster]

Great version number! It works - of course as always. All the coolest stuff was added weeks ago . . . Well Done!

Back to using TYQT with my ESP8266 units. Have two 3.2's each bonded to an ESP <physical onehorse soldered & esp12e on proto PCB> - pulling the ESP serial out to USB and back through TYQT USB for this phase. Lets me use TYQT for monitor again finally. And the ESP units have an OTA reloading sketch.

I did have a failure to upload to Teensy - I worked around it with TeensyLoader upload and TYQT upload of HEX file. I didn't save the error text, and it is now working.

<edit> was to note this was in the PREVIEW version and the same happened in the 0.7 version - not new behavior from TYQT - but something odd on my computer.

<edit> this text is still in log and looks like part of what I saw:

Board has disappeared
Reset does not seem to work

Koromix: Now using TYQT as the 'Loader' - One issue I have created is I'll be writing the same sketch from the same IDE instance to either of two (or 3 or 4) Teensy units. Once TYQT associates an IDE with a Teensy it doesn't ask where to put it - this was the problem with Teensyloader. In my case the sketch will determine at runtime which Teensy it is on so I'll want the same HEX on each unit - not always the same unit. Is there a way to break the 'remembered TYQT association' without having to 'Export compiled binary' and use a directed upload to each Teensy?

Also - I may be looking to set up Visual Micro as a second IDE - I don't know how it executes the uploading and if TYQT will fit in there like the Arduino IDE? Jumping between two 'Tools /Board' settings forces a full recompile and using Arduino for Teensy & ESP will be a pain with swapping builds.

 

[defragster]

Koromix: If I had '- send file / dump serial to file (0.7.1)' I could use it for testing ;-)

I'm looking for an easy way to have the PC get a file onto the ESP file system. Ideally OTA would be best and it will be needed, but that would be work on my part :-0

BTW: I've got two T_3.2's each with an ESP feeding their debug output over serial to the Teensy and into TYQT - very nice no more FTDI connects - only I keep wanting to hit RESET in TYQT to restart the ESP - I need to start looking at ESP serial input for such 'commands'. The cool thing is the ESP's are taking OTA program updates so they are wireless - but bolted to the Teensy. This makes a path for Teensy OTA updates. That of course will create the need for TYQT to start doing network transfers as noted the other day - because somehow the OTA HEX needs to get stored on the ESP FS.

 

[Koromix]

Thank you! Your help was invaluable, and quite a few of these features would not exist without your input.

I did have a failure to upload to Teensy - I worked around it with TeensyLoader upload and TYQT upload of HEX file. I didn't save the error text, and it is now working.

I'll go over on Windows and try to mass upload a little, to stress the code a bit more. I test on Win10 and WinXP VMs but VirtualBox does not like the frequent USB changes, so there are a lot of weird bugs I tend to ignore because under a native Win7 I don't see them happen. But mlaybe one of those is a genuine bug.

Koromix: Now using TYQT as the 'Loader' - One issue I have created is I'll be writing the same sketch from the same IDE instance to either of two (or 3 or 4) Teensy units. Once TYQT associates an IDE with a Teensy it doesn't ask where to put it - this was the problem with Teensyloader. In my case the sketch will determine at runtime which Teensy it is on so I'll want the same HEX on each unit - not always the same unit. Is there a way to break the 'remembered TYQT association' without having to 'Export compiled binary' and use a directed upload to each Teensy?

You can drop the association in the Settings tab, just clear the Firmware text field.

Right now, the multi-upload only works when triggered from the GUI. From Arduino / command-line you can only select one board and the association only triggers the first board that uses the firmware. That's the limitation I wanted to fix for TyQt 0.7.0 but instead it'll be lifted in 0.7.1.

Also - I may be looking to set up Visual Micro as a second IDE - I don't know how it executes the uploading and if TYQT will fit in there like the Arduino IDE? Jumping between two 'Tools /Board' settings forces a full recompile and using Arduino for Teensy & ESP will be a pain with swapping builds.

I don't know how to customize Visual Micro, if you can find where to hack the upload command you can trigger an upload in TyQt (with the initial selection dialog if you have more than one board) with this command:
tyqtc.exe upload --autostart --wait firmware.hex

BTW: I've got two T_3.2's each with an ESP feeding their debug output over serial to the Teensy and into TYQT - very nice no more FTDI connects - only I keep wanting to hit RESET in TYQT to restart the ESP - I need to start looking at ESP serial input for such 'commands'. The cool thing is the ESP's are taking OTA program updates so they are wireless - but bolted to the Teensy. This makes a path for Teensy OTA updates. That of course will create the need for TYQT to start doing network transfers as noted the other day - because somehow the OTA HEX needs to get stored on the ESP FS.

Definitely something I want to add, right now I'm just exploring the area a little to let my brain slowly think the code/UI details through. There's some refactoring needed in the core C code (the stuff that evolved from teensy_loader_cli) which I will slowly pull through over the next few weeks, by then I should have a good picture about ESP/OTA support.

 

[Flydroid]

I don't know how to customize Visual Micro, if you can find where to hack the upload command you can trigger an upload in TyQt (with the initial selection dialog if you have more than one board) with this command:
tyqtc.exe upload --autostart --wait firmware.hex

I have a similar problem: to flash multiple teensy when i made changes to the code.
Afaik using TyQT's commandline interface i could upload to specific ports.
As Visual Micro is actually quite neatly tied into Visualstudio, you can compile using the

msbuild "YourSolution.sln" /p:Configuration="YourConfiguration"

That command worked alright when i tested it in november. As far is have followed the VisualMicro Changelog there where some changes for the build output.
For a batch compile you could just hack a batchfile together and excute it in Visual Studio using the Tools -> External Tools function.
Unfortunately i hadn't have to time to test this fully.

 

[defragster]

Koromix - Updated post above:

I did have a failure to upload to Teensy - I worked around it with TeensyLoader upload and TYQT upload of HEX file. I didn't save the error text, and it is now working.

<edit> was to note this was in the PREVIEW version and the same happened in the 0.7 version - not new behavior from TYQT - but something odd on my computer.

 

[defragster]

Koromix: What are the internal rules on RAM usage to maintain the USB buffered data? It does an awesome job at gathering and storing unbelievable amounts of data - it was very handy the other week when you improved receive throughput and I was wanting to capture multiple runs of 2+MB in my buffer in a few seconds each - something SerMon would dump too quickly - or rather die trying with JAVA memory mis-management. Please don't change your MAX history.

However at times the random spew has no long term value - consuming large RAM buffers - perhaps affecting overall system performance. Having an option to limit those would at times be a good thing - For instance multiple teensy's connected for long term runs and just the recent spew is important - even just seeing it scroll is enough. Some MB is a good minimum - and 'MAX' is great as you have it. This selection ideally under "Monitor /Settings / Monitor " 'per device' so the RAM saved on one might be used on another. Having it right click exposed would make for easy access. And perhaps delaying the purge when active selection in progress.

 

[Koromix]

I have a similar problem: to flash multiple teensy when i made changes to the code.
Afaik using TyQT's commandline interface i could upload to specific ports.

You can trigger an upload in TyQt for a specific board using the --board argument. Random examples:

tyqt upload --board 1125310 --wait firmware.elf
tyqt upload --board my-teensy-31 --wait firmware.elf (if you have named a board my-teensy-31)
tyqt upload --board @COM1 --wait firmware.elf
tyqt upload --board @/dev/ttyACM0 --wait firmware.elf
tyqt upload --board @usb-1-2 --wait firmware.elf
tyqt upload --board 112560@usb-1-2 --wait firmware.elf

Of course the @COM1 syntax does not work if the board is in bootloader mode, because then there is no corresponding COM port. The --wait just tells the client to wait for the end of the command, you can omit it if you don't care about that.

If you don't want the GUI you can use the command-line version called tyc instead, it is packaged along TyQt.

However at times the random spew has no long term value - consuming large RAM buffers - perhaps affecting overall system performance. Having an option to limit those would at times be a good thing - For instance multiple teensy's connected for long term runs and just the recent spew is important - even just seeing it scroll is enough. Some MB is a good minimum - and 'MAX' is great as you have it. This selection ideally under "Monitor /Settings / Monitor " 'per device' so the RAM saved on one might be used on another. Having it right click exposed would make for easy access. And perhaps delaying the purge when active selection in progress.

The scrollback buffer is limited to 200000 lines in the current version. To be honest, Qt does most of the work and TyQt just uses QTextDocument's maximumBlockCount property. Theoretically, if the device sends a lot of stuff without any CR/LF characters you can exhaust the memory.

The per-board limit is a good idea though, so I've just pushed the code for that. It'll be available in TyQt 0.7.1.

 

[defragster]

The scrollback buffer is limited to 200000 lines in the current version. To be honest, Qt does most of the work and TyQt just uses QTextDocument's maximumBlockCount property. Theoretically, if the device sends a lot of stuff without any CR/LF characters you can exhaust the memory.

The per-board limit is a good idea though, so I've just pushed the code for that. It'll be available in TyQt 0.7.1.

200K - lots of lines - good code base and integration work either way and another way it makes the JAVA IDE SerMon a weak comparison. Knowing the storage is line based will make for better control and usage.

Glad I thought to mention the limiting - can make it more responsive reducing unneeded buffer. My system problem was probably from browser auto-refresh watching the ESP's web output - but machine was so sluggish I just rebooted before waiting for TaskMan to come up and looking for a RAM horder. Also not good my machine was on the same WiFi net with two ESP WiFi clients giving it data for days - each on 2.5sec update.

 

[defragster]

Koromix: this post really-weird-upload-problem-with-Teensy-3-1

Reminded me of what I noted in post #151 this thread as noted on post #4 on the thread just linked.

If the IDE gave you a hex file link that wasn't usable - what error would you report? Any chance it is an unhandled/unexpected error that resolves to another error?

BTW: I like that added LOG page! When I looked a the logs though oddly two Teensy's both had the exact same text when I went to copy the text I put in post #151 - which may make sense as I saw it after the fact - but I did wonder if somehow they were showing the same log info or board specific?

 

[defragster]

Looking at the Log tab - I find these notes:

Reset does not seem to work
Cannot reboot in this mode
No board available

There are no time or date or 'device Ser#' stamps. And indeed when I power up a second Teensy - that same text appears on that log page I assumed was 'device dependent'

I'm not looking to have them diagnosed - just hoping to get the log to become more indicative.

Side Note: I think I created these events by having TYQT upload corrupted HEX files. I manually corrupted the files - changing a byte in two files and truncating the files in two other copies. TYQT proceeded to push these files to the Teensy leaving it needing a valid program install to work. I did this because I was hoping to self validate the HEX files in my ESP8266 work using a per line checksum - but that fails to track sequential line numbers or validate any sort of valid <EOF> completion. When I ran those four files past TeensyLoader it caught TWO of them - the changed lines - but also proceeded to use the partial files to program the Teensy leaving it not running.

 

[LAtimes]

Wondering if this is possible - I am loading the same sketch into 2 different Teensy's (LC and 3.1) using Teensyduino integrated with tyqt. The first load (LC) asks which board (good) but when switching to the other board and rebuilding, it says firmware is only compatible with 3.1 (and last load was an LC). Is there a way to have tyqt either look for the Teensy 3.1 or at least ask which board again if it can't load the sketch in the LC board (due to wrong processor type)?

 

[defragster]

If these vars map as I am thinking they do I see Teensyloader takes an extra param that might be good to pass into TYQT to identify the board and a mismatch up front:

In platform.txt:
## Teensy Loader
#tools.teensyloader.upload.pattern="{cmd.path}/teensy_post_compile" -test "-file={build.project_name}" "-path={build.path}" "-tools={cmd.path}" "-board={build.board}" -reboot

## TyQt
tools.teensyloader.upload.pattern="{cmd.path}" upload --autostart --wait "{build.path}/{build.project_name}.hex"

In boards.txt:
teensy31.build.board=TEENSY31
teensy30.build.board=TEENSY30
teensyLC.build.board=TEENSYLC
teensy2.build.board=TEENSY2
teensypp2.build.board=TEENSY2PP

 

[Koromix]

There are no time or date or 'device Ser#' stamps. And indeed when I power up a second Teensy - that same text appears on that log page I assumed was 'device dependent'

Indeed it is a global log page, for simplicity. I'll look into adding the board tag as a prefix, when applicable.

Side Note: I think I created these events by having TYQT upload corrupted HEX files. I manually corrupted the files - changing a byte in two files and truncating the files in two other copies. TYQT proceeded to push these files to the Teensy leaving it needing a valid program install to work. I did this because I was hoping to self validate the HEX files in my ESP8266 work using a per line checksum - but that fails to track sequential line numbers or validate any sort of valid <EOF> completion. When I ran those four files past TeensyLoader it caught TWO of them - the changed lines - but also proceeded to use the partial files to program the Teensy leaving it not running.

Could you send me the corrupted files accepted by TyQt but rejected by Teensy Loader? I can't reproduce this bug, changing the HEX files fails the rudimentary line-based checksum verification.

Theoretically, you can detect partial HEX files because there is an EOF record to mark the end. But I'm not sure it is always present, so TyQt does not require it.

Wondering if this is possible - I am loading the same sketch into 2 different Teensy's (LC and 3.1) using Teensyduino integrated with tyqt. The first load (LC) asks which board (good) but when switching to the other board and rebuilding, it says firmware is only compatible with 3.1 (and last load was an LC). Is there a way to have tyqt either look for the Teensy 3.1 or at least ask which board again if it can't load the sketch in the LC board (due to wrong processor type)?

The simplest fix for this is to change arduino/hardware/teensy/avr/platform.txt to use a different output filename depending on the board model/variant. You can hack it yourself, find the line "tools.teensyloader.upload.pattern=..." and replace it with these two lines instead:

recipe.objcopy.tyqt.pattern="{compiler.path}{build.toolchain}{build.command.objcopy}" {compiler.elf2hex.flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.{build.board}.hex"
tools.teensyloader.upload.pattern="{cmd.path}" upload --autostart --wait {upload.verbose} "{build.path}/{build.project_name}.{build.board}.hex"

Restart the IDE, and you're good to go. This is probably what I'm going to do to support your use case in 0.7.1 anyway.

 

[defragster]

These are the files as edited:View attachment badBBT31.zip

Two truncated, one edited line # and one random byte change. Teensy Loader gave me this where the second files 'not named' are the other two longer files:

10:47:23: Open File event
10:47:30: File "badBBT31_A.hex". 176 bytes, 0% used
10:47:33: Verbose Info event
10:48:15: Open File event
10:48:19: File "badBBT31.nousb_A.hex". 192 bytes, 0% used
10:48:24: Open File event
10:48:29: ihex: parse error line 31
10:48:33: Open File event
10:48:40: ihex: parse error line 56

<edit> The two named truncated files are taken and coded into the Teensy by TeensyLoader and left in an 'unkown' state. I see the <EOF> notes on the files I have seen. Is there always a transition across 'groups' or data types in the HEX? Maybe confirming that happens would catch obvious truncation like mine, if not expecting the <EOF>? If you spend time and find a pattern would it be worthy of a bug to PJRC?

I don't know the HEX format but I see these transitions:

:1000000000800020BD0100007114000035140000C4
:1000100035140000351400003514000035140000BC
...
:102EB0009E467047152B0000350400005527000082
:0C2EC00081280000AD290000052A000058
:042ECC00F8B500BF96
:102ED000FFFFFFFF0A040000120100020200004091
...
:10338000000000000000000000000000000000003D
:10339000000000000000000000000000000000002D
:0833A000000000000000000025
:00000001FF

 

[Koromix]

I've improved the correctness checks, thanks for the files. They are now all rejected by the latest code, and it will be in 0.7.1.

I was not sure about making the EOF record mandatory, especially since binutils/objcopy does not seem to enforce it on input files... but it does always write the EOF record, and it is the tool used by Arduino to make HEX files. So it is probably safe to reject files without an EOF.

 

[defragster]

Koromix: - that is good news. Can you hotlink me to your GitHub source for that file check code if online?

Also - your autoload has bit me again. I connected a second Teensy - but forgot to flip switch the USB power switch. So TYQT boldly overwrote my long running Teensy without asking.

Once that happens I don't know how to change the association to get the current code on the NEW Teensy and free the OLD Teensy to put the right code back on it? Other than Closing TYQT. You addressed this once when I asked before - but I didn't see it work so I must have misunderstood. It might be nice to have an 'Always Ask' setting because putting the wrong code out is not handy.

 

[Koromix]

https://github.com/Koromix/ty/blob/2b3cab14ddf769004929ca281fd5cb794478b6a7/libty/firmware_ihex.c



I will add a "Forget '...'" shortcut to the Upload submenu to do the same.

 

[defragster]

Thanks for the "parse_line()" link and the PICTURE! I tried editing it on the (read only) INFORMATION tab not SETTINGS - that failed and then I stopped looking.

The ScrollBack looks well placed, looking forward to it - before long I'll remember where the Settings tab is.

 

[Koromix]

I've considered dropping the information tab multiple times... Most of the fields are redundant and already available in the board list widget, except the "interfaces" list which I want to show somewhere. I don't know where, so I have kept the tab so far.

 

[defragster]

The Settings tab was so sparse I never looked at it. And with future 'friendly naming' or other persistent settings that will have to appear somewhere and indeed the Interface and details device info is important. I've demonstrated :-( redundant info is misleading can be confusing.

The 'per device' looking log tab that is global should almost be up on the 'button bar'?

I like the 'minimal' interface for wide debug text in a smaller space, but then there is no devices list to switch with a click. Adding a tab for that show 'all devices and Interface' info would be handy but redundant to the left column when displayed and would put global info tab in the per device tabs . . . . so much utility and we want it in a Teensy space.

 

[LAtimes]

The simplest fix for this is to change arduino/hardware/teensy/avr/platform.txt to use a different output filename depending on the board model/variant. You can hack it yourself, find the line "tools.teensyloader.upload.pattern=..." and replace it with these two lines instead:

recipe.objcopy.tyqt.pattern="{compiler.path}{build.toolchain}{build.command.objcopy}" {compiler.elf2hex.flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.{build.board}.hex"
tools.teensyloader.upload.pattern="{cmd.path}" upload --autostart --wait {upload.verbose} "{build.path}/{build.project_name}.{build.board}.hex"

Restart the IDE, and you're good to go. This is probably what I'm going to do to support your use case in 0.7.1 anyway.

This worked. Thanks for the quick reply.

 

[Koromix]

The Settings tab was so sparse I never looked at it. And with future 'friendly naming' or other persistent settings that will have to appear somewhere and indeed the Interface and details device info is important. I've demonstrated :-( redundant info is misleading can be confusing.

You can already rename boards with friendly names, and it is persistent. Double-click on the board, or select it and press F2. In the future I will add a context menu to the board list for simple actions / renaming / etc. to make all these things more discoverable. And maybe expose this in the Settings tab too.

The 'per device' looking log tab that is global should almost be up on the 'button bar'?

I'll probably move the log information to an independent window, kind of like Teensy Loader.

I like the 'minimal' interface for wide debug text in a smaller space, but then there is no devices list to switch with a click. Adding a tab for that show 'all devices and Interface' info would be handy but redundant to the left column when displayed and would put global info tab in the per device tabs . . . . so much utility and we want it in a Teensy space.

Quickly came up with an improved version of the minimal interface this morning. That's what I came up with:

 

[defragster]

SWEET! I named my two connected Teensy units! It works on device power up - and on TYQT restart! I thought that was noted as in for 0.70 but I missed the specifics - I should edit post #151 with the two things I learned today. I naturally tried right click on device - but not double click so that is a great plan.

Okay - new feature request:: Show the sketch name to be uploaded on 'board selection' pop-up. Seeing the sketch name as well as the Teensy custom name side by side will be a double check after a long compile ;-)

I generally like your UI and improvements - further minimizing and putting the board dropdown there is a GOOD EXAMPLE of why! Will that drop down be 'always on'?
[ Question - does the 'Alt' key restore the menu? - the only items missing would be 'restore full interface' and 'new Window' - maybe the board dropdown could expose 1/2 of those ]

Independent Log/Verbose window like PJRC is good as it is rarely used. It could maybe also work on the board drop down?

 

[defragster]

Koromix is this accurate - about the USB Serial, etc::

It already is open - at least the format and information is - there is a great forum contributed app by Koromix : Teensy-Qt. He got that info needed to code that from PJRC in some fashion.

It has a GUI and CMD line version with an awesome feature set for upload and so much more as a stand alone app.

 

[WMXZ]

Koromix is this accurate - about the USB Serial, etc::

most likely not, as it also works with button pressed.

Koromix may correct,
but I suspect TeensyQt works also along the line
- detect teensy on usb-serial ports OR usb-hid
- send 'reboot' command to teensy (different for hid and serial) to put teensy into program mode
- download hex file
- restart teensy

There are still some tricks with hid, but in principle that is the procedure

As with PJRC teensy loader you must have a running teensy to be able to download