TyCommanderC.exe trigger bootloader from -multi select list #59
Comments
|
Right now, how it works is that the TyCommander instance triggers the selection dialog only for upload AND only if it cannot find a Teensy associated/linked to the HEX file passed as argument to the upload command. Two things can be done:
|
|
This is an odd case where TyCommand not integrated - and TeensyLoader owns programming. Without integration the 'command line IDE build' as used doesn't know what Teensy to take offline or pass to TeensyLoader as TyComm owns that USB port. This just needs to offer an easy way to have TyComm drop the port and trigger TeensyLoader to program. If TyComm tried to program while TeensyLoader active it hangs TLoader. This isn't critical - in current use the IDE build passes the HEX to TLoader and then I have to push button or hit 'Bootloader' in TyComm to get the TLoader to program. If this change could present a dialog it would make it easier. |
|
While I'm willing to improve this use case, this begs the question: is there a specific reason you prefer the official loader? Is it because of #41? |
|
I really did this on HardWare Beta before TyComm was able to be updated to support new devices you didn't have. One reason is when I'm doing Beta builds of TeensyDuino I do it to help test PJRC code - even though not directly in the IDE - at least it confirms that works. Using my TSET for command line build it uses the installed IDE and TeensyDuino so that is tested too. But I can pop into the IDE as well for stupid IDE SerMon. Another is that only the TeensyLoader will provide Firmware Upgrades to the Teensy when they happen - that sort of ties in with the item above to make sure when they are delivered I get them. Also indeed #41 - it would be nice if the RTC set code mechanism was exposed by PJRC. |
|
I've added a semi-hidden option to handle this situation. You will need to edit platform.txt yourself (after integration), and add --delegate to the list of options:
With this option, the upload task will let the Teensy Loader do its stuff. TyCommander won't talk to the loader; you first need to point the Teensy Loader (manually or by adding a command to platform.txt) to the correct HEX file. TyCommander will assume you have done so, and once the board becomes available again it will assume the HEX file has been uploaded by the loader. Build is here: https://koromix.dev/files/tytools/ (TyTools-0.9.1-18-gd7e26e9) |
|
That works PERFECTLY!
The 'upload.pattern' code runs from SublimeText Editor batch file - it doesn't use any changes to platform.txt. NOTE: That temp build does not have the RED around the Multi Serial# and the number only half shows in white on the black: |
|
Okay - not quite perfect? I did a DROP association and upload after prompt that shows running but TyCommander is confused? Program worked - but had to close TLoader - and hit Button to take both T_4.1's offline - then hit GUI Reset ? Did a drop Assoc on the one running 'SerialUSB' with 3 USB
BTW - in this case the Association labels are not updated? |
|
Perhaps with '--delegate' it would be okay to always prompt for device? On the 3 USB Serial sketch it takes input and prints on ALL three - getting 'busy on task? Have to kill TyComm and background processes? Listing USB host controllers and root hubs
|
|
It works fine for multiple uploads - until I try Drop Association to put the code on another Teensy. Not sure how it decides to prompt or not - I could edit build from T_4.1 to T_4.0 and it wouldn't know and the model# isn't in the HEX filename. |
|
It decides to prompt if it can't find a Teensy associated with the firmware path. It does not care about the model at this stage. When you integrate TyCommander with Arduino, the path of the firmware is changed a bit to always include the board model. So if you change from Teensy 4.0 to Teensy 4.1 (for example) for the same sketch, the HEX file will have a different path. Without integration, this is not the case. You could do the same change/hack in platform.txt to fix this problem, without doing the integration stuff. |
|
The "red circle bug" in the build was caused by an older version of Qt. I made this build on my old MacBook, and it did not want to rebuild Qt because it is so sloooowww ><. I've made a new build, it should work correctly. Also, this new build has a fix for Wndows 7, on which dual/triple serial Teensies would not work correctly in TyCommander. |
|
Indeed, the batch file code posted above differentiates based on seeing if the model is in the HEX name if EXIST "%temp1%%sketchname%.%model%.hex" ( When integrated it runs the Proper TyComm first line, without that it then uses the default sketch.HEX. Frank Boesing crafted the Windows Command Line code that runs the IDE build - and I wrote a further batch file that prompts for all the board settings so the resulting batch file was easy to create or change for each sketch folder. It prompts user for and then sets these values: So the IDE GUI never has to be touched . The IDE builds { with or without TyComm Integration } and then works afterwards. It is very handy and the SublimeText editor I use can trigger the needed batch file with its 'Build' system and capture the output very nicely, but the same also works from the Command line - or even Windows File Explorer to trigger a build. It works now - as long as the Teensy doesn't change or it isn't needed on multiple Teensy or a different Teensy. But in the case of TyCommanderC --delegate it would work well if the test for " find a Teensy associated with the firmware path" was removed - and it always Prompted. I need to restart my computer for an update before I can try the new code - there is an Update pending and also I can't overwrite the TyComm files for some reason? I don't see where - but some process has the files open and locked by the system. |
|
Looks very good. I just did a Drop Association three times to change the code on the One T_4.1 and all seems well going from 2 to 3 USB and back with alternate sketch using the --delegate in my batch file with no changes to IDE { integration or platform.txt edits } The file name of the Sketch is properly tracking now which may have cleared up the issue I was seeing. |
|
Seems to work, don't hesitate to comment again or open a new issue if not :) |
|
Indeed - working well as tested. Thanks. Went back to Integrated TyComm and no issues there. I never tried hacking platform.txt - but for use in Windows TSET batch file where it does or does not see the .model.HEX file I was able to detect when to trigger the --delegate to get TeensyLoader to work as needed. |
Would it be easy and sensible to have the UPLOAD behavior presenting the 'choose board' dialog trigger a Reboot?
In the case of platform.txt it uses :: upload --autostart --wait --multi
Having the ability to command line present the list and then trigger 'Bootloader' would in the case where TyCommander is not integrated but using the TSET command line build from editor would take the Teensy offline and trigger the TeensyLoader to Upload the Teensy before it returned. Currently I have to click the GUI 'Bootloader' button - or the Teensy Button to disconnect TyCommander and allow TeensyLoader USB access to the desired Teensy.
This comes up during Beta releases of TeensyDuino when avoiding the IDE GUI is okay - but need to see TeensyLoader do the upload without having to so Integrate.
Using perhaps a variation of this that currently results in this with no prompting:
T:\TyComm>TyCommanderC.exe reboot --autostart --wait --multi
reboot@7819600-Teensy Rebooting board '7819600-Teensy' (Teensy 4.1)
reboot@7819600-Teensy Board is already in bootloader mode
reboot@1245170-Teensy Rebooting board '1245170-Teensy' (Teensy 3.2)
reboot@1245170-Teensy Board is already in bootloader mode
The text was updated successfully, but these errors were encountered: