Yay! With this change i was able to get a good compile in VS 2015. Very happy. Thank you Koromix and tni for all the help you've given me on this!!
Teensy Qt
- Thread starter Koromix
- Start date
Yay! With this change i was able to get a good compile in VS 2015. Very happy. Thank you Koromix and tni for all the help you've given me on this!!
defragster
Senior Member+
I just did the following to good effect with recent TYQT - also note I did INTEGRATE with 1.6.11, and then RESTORE, then INTEGRATE and that all worked as below ( that I had posted on the 1.30b3 release thread:
IT WORKS to program a T_3.6! :: I just got to my Win 10 DESKTOP and installed IDE 1.6.11, TeensyDuino 1.30b3, and TyQt-0.7.5-187.
Note - I DID INTEGRATE TYQT to replace TeensyDuino LOADER - I got the anomaly text below - I did not check before I did TYQT - is this because of that?
UPDATE EDIT:: That text is from TYQT, not IDE or TeensyDuino. It is saying it doesn't know the serial # as the clock speed was too high:
IT WORKS to program a T_3.6! :: I just got to my Win 10 DESKTOP and installed IDE 1.6.11, TeensyDuino 1.30b3, and TyQt-0.7.5-187.
Note - I DID INTEGRATE TYQT to replace TeensyDuino LOADER - I got the anomaly text below - I did not check before I did TYQT - is this because of that?
UPDATE EDIT:: That text is from TYQT, not IDE or TeensyDuino. It is saying it doesn't know the serial # as the clock speed was too high:
Koromix
Well-known member
The -187 build is the same as -184, the three commits are small build and documentation changes.
In the latest builds, boards without a valid S/N are named "Unknown", instead of "0-Teensy", and board settings won't be saved until TyQt gets a valid S/N. On Teensy 3.6, it's caused by the fact that init_usb_serialnumber() fails above 120 MHz. So it's normal, at least on TyQt's side.
In the latest builds, boards without a valid S/N are named "Unknown", instead of "0-Teensy", and board settings won't be saved until TyQt gets a valid S/N. On Teensy 3.6, it's caused by the fact that init_usb_serialnumber() fails above 120 MHz. So it's normal, at least on TyQt's side.
defragster
Senior Member+
Koromix - I posted core code change that works for reading serial number at higher speeds here : teensy-3-MAC-address.
It is a subset of a change KurtE proposed - not sure if it will be used - but it gets ser# at 180 and 240 MHz.
Very glad to report that TYQT is up and running - and Integrating to 1.6.11 on the newest Teensy 3.6! I'll have a T_3.5 to test in the next 15 hours.
Where does one find the link to share to get this version of TYQT?
It is a subset of a change KurtE proposed - not sure if it will be used - but it gets ser# at 180 and 240 MHz.
Very glad to report that TYQT is up and running - and Integrating to 1.6.11 on the newest Teensy 3.6! I'll have a T_3.5 to test in the next 15 hours.
Where does one find the link to share to get this version of TYQT?
Koromix
Well-known member
I've just found that I introduced a pretty bad leak a few commits ago, which could also cause weird issues in some cases (board swaps, upload, reset, etc.). You might want to update your copy to the latest version on GitHub.
You can just give the BinTray file link, I think. BinTray is pretty bad but it's free and easy to upload to from the CI services
Oh and for some reason the MSI files end up as ".msi.zip" when you download them. As usual, the web makes perfect sense.Hey Koromix!
First of all: Thank you for your tool! It is really great and it is excatly what I searched for my application.
I'm curretly developing a little Web-IDE, which should be used to remotely program two or more Teensy++ 2.0 connected to a server. My develop and test server is a Raspberry Pi 2 with Rasbian on it. Here TYQT works fine and detects every connected Teensy++ 2.0 immediately. Also reseting and programming of each individual controller is possible without any problems.
Because I have finished a first (hopefully) stable version of the project, I today tried to move everything on the final server which is a normal desktop-pc running Ubuntu 16.04. There all connected Teensy++ 2.0 are also detected in TYQT but they are marked as "unkown" and neither a reset nor the programming without a manual button press works.
Do you have any idea where this problem is comming from and how it could be fixed?
Thank you in advance!
First of all: Thank you for your tool! It is really great and it is excatly what I searched for my application.
I'm curretly developing a little Web-IDE, which should be used to remotely program two or more Teensy++ 2.0 connected to a server. My develop and test server is a Raspberry Pi 2 with Rasbian on it. Here TYQT works fine and detects every connected Teensy++ 2.0 immediately. Also reseting and programming of each individual controller is possible without any problems.
Because I have finished a first (hopefully) stable version of the project, I today tried to move everything on the final server which is a normal desktop-pc running Ubuntu 16.04. There all connected Teensy++ 2.0 are also detected in TYQT but they are marked as "unkown" and neither a reset nor the programming without a manual button press works.
Do you have any idea where this problem is comming from and how it could be fixed?
Thank you in advance!
Koromix
Well-known member
Did you install the udev file available at https://www.pjrc.com/teensy/49-teensy.rules? Without it, only root can open the Teensy device files, so upload / reset / serial actions won't work.
The "Unknown" label is misleading (I'll change it), it means the Teensy does not have a unique serial number, so the settings cannot be saved / restored unambiguously. It's quite recent, and before it would show as "12345-Teensy". All Teensy 2.0 boards use S/N "12345" so it is ignored, and considered non-unique. Except for settings persistence, TyQt should have no problem with your Teensies.
The "Unknown" label is misleading (I'll change it), it means the Teensy does not have a unique serial number, so the settings cannot be saved / restored unambiguously. It's quite recent, and before it would show as "12345-Teensy". All Teensy 2.0 boards use S/N "12345" so it is ignored, and considered non-unique. Except for settings persistence, TyQt should have no problem with your Teensies.
Thank you for your quick answer.
The udev file should be installed correctly. I followed the instructions on https://www.pjrc.com/teensy/td_download.html. But I will again check this on monday.
What I also want to try is, installing Debian as a virtual machine on the desktop-pc and check if it works. Maybe there are some difference between Ubuntu and Debian regarding the device management. Could that be a possible source for the problems? Changing the OS on the final servre would be no problem in the current development state.
The setting persistence is actaully not important for the final application. I only need to individually program the two (or more) connected Teensy++ 2.0 via a command-line-tool and without a manual button press (since it should be done remotely). So your tool should be the perfect solution
The udev file should be installed correctly. I followed the instructions on https://www.pjrc.com/teensy/td_download.html. But I will again check this on monday.
What I also want to try is, installing Debian as a virtual machine on the desktop-pc and check if it works. Maybe there are some difference between Ubuntu and Debian regarding the device management. Could that be a possible source for the problems? Changing the OS on the final servre would be no problem in the current development state.
The setting persistence is actaully not important for the final application. I only need to individually program the two (or more) connected Teensy++ 2.0 via a command-line-tool and without a manual button press (since it should be done remotely). So your tool should be the perfect solution
I will immediately check that on monday and post the result (unfortunately I have currently no access to the server).
Thank you for your help!!
Koromix
Well-known member
I did a test on the Live CD of Ubuntu 16.04.1, and both TyQt and tyc worked well after installing the udev rules file. At least the latest GitHub version. You need to unplug / replug the Teensy after installing this file, but I guess you already did that.
When you can, try to do a couple resets / uploads and then give me a copy of the Full Log in "Tools > Open Log".
When you can, try to do a couple resets / uploads and then give me a copy of the Full Log in "Tools > Open Log".
I have now reinstalled the udev file and tested everything again, but unfortunately the problem persists.
When I open TyQt the Teensy is first detected as "unkown" and I can't reset or program it without a manual button click. From the moment I click the button, the programming works, the controller is detected and also a reset is possible without any problems. Even when I close TyQt and restart it, the controller is still detected and everything works fine. But when I switch to the command-line-tool tyc the Teensy is always detected as "unkown" and neither the reset nor the programming without a manual button press works.
In the following attachment you can find the log, as requested. After the start of TyQt I tried to reset the Teensy three times. Then I tried to program it and I clicked the button. After that I reset it a few times and I did a second programming. Could you see any hint that could help solving the problem?
Thank you!
View attachment TyQt_Log.txt
When I open TyQt the Teensy is first detected as "unkown" and I can't reset or program it without a manual button click. From the moment I click the button, the programming works, the controller is detected and also a reset is possible without any problems. Even when I close TyQt and restart it, the controller is still detected and everything works fine. But when I switch to the command-line-tool tyc the Teensy is always detected as "unkown" and neither the reset nor the programming without a manual button press works.
In the following attachment you can find the log, as requested. After the start of TyQt I tried to reset the Teensy three times. Then I tried to program it and I clicked the button. After that I reset it a few times and I did a second programming. Could you see any hint that could help solving the problem?
Thank you!
View attachment TyQt_Log.txt
Koromix
Well-known member
You can pull from GitHub to change the 'Unknown' label thing. For the actual problem, it's... weird. It looks like things are done correctly, but for some reason the board won't reboot.
Could you run "TY_DEBUG=1 strace tyc reset 2>&1 >tyc_log.txt" on the latest version and give me the log? Of course I need the log from an instance where the reset does fail.
Could you run "TY_DEBUG=1 strace tyc reset 2>&1 >tyc_log.txt" on the latest version and give me the log? Of course I need the log from an instance where the reset does fail.
defragster
Senior Member+
Dude: Is TeensyDuino active when trying the reset? I suppose not - but it often doesn't go right when it is.
@Koromix: I have updated Teensy Qt to the latest version and now the "Unkown" labels are replaced by the old serial numbers. You can find the output file of the command in the attachment. Is this what you need? Because the strace-output is currently shown on the terminal and not fed into the file.
@defragster: TeensyDuino is not active, at least the Arduino IDE/Tools are not in use, if that's what you mean?
View attachment tyc_log.txt
@defragster: TeensyDuino is not active, at least the Arduino IDE/Tools are not in use, if that's what you mean?
View attachment tyc_log.txt
Last edited:
Koromix
Well-known member
Sorry, I messed it up. Should have checked, here is the correct version: "TY_DEBUG=1 strace tyc reset >tyc_log.txt 2>&1". Indeed without the strace statements the log is useless
No problem. I have attached the new log ;-) (Unfortunately the file exeeds the forums size limit of < 200kb, so I provided a Dropbox link.)
https://www.dropbox.com/s/9o0asbzx7gg3lno/tyc_log_strace.txt?dl=0
https://www.dropbox.com/s/9o0asbzx7gg3lno/tyc_log_strace.txt?dl=0
Koromix
Well-known member
Thanks for the log. Everything seems to go as it should, but the baudrate change does not trigger a Teensy reboot. You did not change the Teensy core code, by any chance?
I've pushed a workaround to GitHub for the only thing I could think of. I've gone through the Teensy2 core code and the Linux tty / ioctl() / cdc_adm code and nothing makes me think it is the right fix, but who knows.
I've pushed a workaround to GitHub for the only thing I could think of. I've gone through the Teensy2 core code and the Linux tty / ioctl() / cdc_adm code and nothing makes me think it is the right fix, but who knows.
No I didn't change the Teensy core code. At least as far as I know (but I think it is very unlikely that it had happen accidentally ).
As you already assumed your change unfortunately doesn't fix problem. Tomorrow I'll try everything again on a Debian OS. If the problems then are gone, it maybe is something ubuntu specific. I will get back with the results.
Thank you for your time and your help!
).As you already assumed your change unfortunately doesn't fix problem. Tomorrow I'll try everything again on a Debian OS. If the problems then are gone, it maybe is something ubuntu specific. I will get back with the results.
Thank you for your time and your help!
Koromix
Well-known member
Sorry, I can't find anything going wrong. The Teensy Loader does basically the same thing as TyQt, according to strace.
Still, you might want to try the Teensy Loader on the server, to see if it gets the same kind of failure. You don't need to install arduino, just extract the Arduino archive, and run the Teensyduino installer on it. And then use the IDE to reboot.
Still, you might want to try the Teensy Loader on the server, to see if it gets the same kind of failure. You don't need to install arduino, just extract the Arduino archive, and run the Teensyduino installer on it. And then use the IDE to reboot.
Last edited:
defragster
Senior Member+
I got the latest TYQT for testing with the KS Beta T_3.5 and T_3.6 - looks to be better than ever! Thanks - again- Koromix!
This image shows two active devices and being able to pull out a cached copy of uploaded HEX files that are device specific. In the IDE I compiled for one and then the other uploading in turn, but then I needed to run a prior version - LOOK there it is in the 'Recent Firmware' - I don't have to recompile for the T_3.5 even though the IDE is now set for T_3.6:
And here is the prompt for which Teensy to upload to - No button pushing!
This image shows two active devices and being able to pull out a cached copy of uploaded HEX files that are device specific. In the IDE I compiled for one and then the other uploading in turn, but then I needed to run a prior version - LOOK there it is in the 'Recent Firmware' - I don't have to recompile for the T_3.5 even though the IDE is now set for T_3.6:
And here is the prompt for which Teensy to upload to - No button pushing!
Koromix
Well-known member
Glad you like it
I have to say that except for loading the always useful Blink sketch and testing, I don't use the Arduino IDE. So I'm not sure what it does when you switch board type but it seems like it may delete the previous HEX file in at least some cases. TyQt only keeps the path to previous HEX files but does not copy them, so it won't work if the IDE deletes them. Copying them could be an idea for 0.8.0, I guess.
It's been years now and I still don't understand why the compiled binary files are not put in a "build/<board_type>" subdirectory inside the sketch folder. That would allow for faster builds, especially after starting the IDE, and avoid the recompilation when you change the board type. The IDE already forces you to put your INO file in a folder, it could take more advantage of that (beyond pulling in the cpp and header files that go with the sketch).
I have to say that except for loading the always useful Blink sketch and testing, I don't use the Arduino IDE. So I'm not sure what it does when you switch board type but it seems like it may delete the previous HEX file in at least some cases. TyQt only keeps the path to previous HEX files but does not copy them, so it won't work if the IDE deletes them. Copying them could be an idea for 0.8.0, I guess.
It's been years now and I still don't understand why the compiled binary files are not put in a "build/<board_type>" subdirectory inside the sketch folder. That would allow for faster builds, especially after starting the IDE, and avoid the recompilation when you change the board type. The IDE already forces you to put your INO file in a folder, it could take more advantage of that (beyond pulling in the cpp and header files that go with the sketch).
defragster
Senior Member+
I saw the "Only_qBlink.ino.TEENSY36.hex" and assumed that was TYQT at work - must be the doing of the IDE now - it is in the TEMP work directory.
It was very handy - if 0.8.0 could codify that it would be cool - would also be cool if compiling for one T_3.x put that same HEX in the upload list for all similar T_3.x units.
Too many cool options and extensions evolve from each new use or feature! Of course right now in beta hardware test mode the use case is special.
It was very handy - if 0.8.0 could codify that it would be cool - would also be cool if compiling for one T_3.x put that same HEX in the upload list for all similar T_3.x units.
Too many cool options and extensions evolve from each new use or feature! Of course right now in beta hardware test mode the use case is special.
defragster
Senior Member+
TYQT working very well for me on Teensy 3.6, 3.5 and 3.1/3.2!
I installed the IDE 1.6.11 with TeensyDuino 1.30 on my desktop and have been compiling and using it quite a bit and it works very well! I have done the Tools / Integrate to Arduino and TYQT replaces TeensyDuino for uploading - so close TeensyDuino.
Worst case is I did some code before Teensy was ready in an early HOOK() and the Teensy wasn't responsive, or in other work playing with T_3.6 runtime speed clocks the USB goes dead.
FIX--> Press Button, or unplug Press&Hold Button while plugging it in, pause a second with button down, release button, then do the Upload from IDE again.
I installed the IDE 1.6.11 with TeensyDuino 1.30 on my desktop and have been compiling and using it quite a bit and it works very well! I have done the Tools / Integrate to Arduino and TYQT replaces TeensyDuino for uploading - so close TeensyDuino.
Worst case is I did some code before Teensy was ready in an early HOOK() and the Teensy wasn't responsive, or in other work playing with T_3.6 runtime speed clocks the USB goes dead.
FIX--> Press Button, or unplug Press&Hold Button while plugging it in, pause a second with button down, release button, then do the Upload from IDE again.