Teensy Qt

Thanks for the report, I saw your posts a couple hours ago. It's a silly mistake in my code, where the wrong exit code is used from the command-line client used by Arduino. Until 1.6.10, the IDE did nothing with the exit code so it had no consequence, but now it prints its own error message.

Since 0.8.0 will not be released before 3 weeks, I have just released TyQt 0.7.6 which fixes this issue and a few others.
 
This program is such a godsend for Teensy developers! I suggest everyone send Koromix a donation to help cover the time and effort to make it all work.

On a tech support level, what would trigger a unauthorized access error?
 
Thanks, glad it's useful. There are many things I don't really like about the current code, but it's not all bad. A bit over-engineered, I guess. But hey, that's how you learn. My next project, currently in early development (still Arduino and Teensy related) does / will benefit from the many lessons I've learned since the first release of TyQt.

I'm not sure what error you've seen, but I guess it's a "Permission denied to open 'blah'", which is what TyQt reports when a device cannot be opened, be it Serial or HID. I always forget the details about Win32 but basically some device types cannot be opened by two applications at the same time. If the Teensy Loader is opened, it can happen. Windows also blocks opening keyboard and mouse devices directly. Maybe it can also happen before the device is completely installed.

I've recently improved the device code to enumerate devices without really opening them, it seems to work well but it's not finished yet. It's in the development builds, on BinTray. Did the error happen with 0.7.5 or in a dev build?

Unrelated Tip (about a feature I tend to forget myself, I've just used it for the first time in a long time hence the tip): you can select multiple boards, click "Upload New", select multiple firmwares in the upload file dialog (say, Blink_LC.elf and Blink_31.elf) and TyQt will pick the first compatible choice for each board. On Windows (< 10) parallel uploads are done one board after the other (unlike OSX and Linux)... Because Windows just screws up device setup / COM attribution way too easily. I've seen the same COM port attributed to two devices more than once.
 
Good work and Awesome Tool Koromix - as I've said before - Teensy is great - but TYQT makes it more usable! Given how quickly you've fixed any issue I've found the engineering level on my end seems robust and good. Doing cross platform OS's with new target Teensy hardware popping out isn't trivial.

Hoping all is well on the 1.6.9/.10 builds for all. I've got beta hardware and the 'Integrate to Arduino' hosed the files with the custom boards.txt so I have not tested it to work. [noted 6/25/16 in post#300]
 
Hi, TyQt is what i've been looking for! Question, i have downloaded QT Creator (including MinGW) but it's not immediately clear how to best open the project from the source you've included (thank you!) on GitHub. I don't see a project file. Any easy advice? I need to make few small changes and recompile. Thanks!
 
Hi, TyQt is what i've been looking for! Question, i have downloaded QT Creator (including MinGW) but it's not immediately clear how to best open the project from the source you've included (thank you!) on GitHub. I don't see a project file. Any easy advice? I need to make few small changes and recompile. Thanks!
TyQt is a CMake project, so you need to open CMakeLists.txt as project. You can get CMake from here:
https://cmake.org/download/

Qt Creator has a setup tab for CMake under "Options / Build & Run". There is another set of CMake configs under "Options / Build & Run / Kits".
 
Yes, you can open CMakeLists.txt with Qt Creator. For a while I maintained a set of qmake .pro files in the repository for Qt Creator, but I dropped them because they were regularly broken and Qt Creator supports CMake files pretty well. This wasn't so true a year ago.

Building TyQt this way works, but the resulting executable depends on the (heavy) Qt shared libraries / DLLs to work. To avoid that, you need to build a static build of Qt (Digia does not provide such a build). You can follow my instructions to do so at https://github.com/Koromix/ty/tree/master/qt5

Lastly, this project can now be compiled with Visual Studio 2015. The official Win32 builds use Visual Studio. Obviously I completely forgot to update the README, which still mentions that Visual Studio is not supported.
 
I'm sometimes getting crashes in monitor.c::trigger_callbacks(ty_board *board, ty_monitor_event event) when resetting the Teensy.
at
ty_list_foreach(cur, &board->monitor->callbacks) {
Variable state (this is a release build):
board->monitor->callbacks = {prev=0x0000000000000000 <NULL> next=0x000000a200000000 {prev=??? next=??? } }

Stack trace (TyQt is current GIT version):
Code:
tyqt.exe!trigger_callbacks(ty_board * board, ty_monitor_event event) Line 59
tyqt.exe!drop_board(ty_board * board) Line 171
tyqt.exe!ty_monitor_refresh(ty_monitor * monitor) Line 584
tyqt.exe!QMetaObject::activate(QObject * sender, int signalOffset, int local_signal_index, void * * argv) Line 3728
tyqt.exe!DescriptorNotifier::activated(void * _t1) Line 154
tyqt.exe!QMetaObject::activate(QObject * sender, int signalOffset, int local_signal_index, void * * argv) Line 3728
tyqt.exe!QWinEventNotifier::activated(void * _t1, QWinEventNotifier::QPrivateSignal __formal) Line 138
tyqt.exe!QWinEventNotifier::event(QEvent * e) Line 244
tyqt.exe!QApplicationPrivate::notify_helper(QObject * receiver, QEvent * e) Line 3800
tyqt.exe!QApplication::notify(QObject * receiver, QEvent * e) Line 3762
tyqt.exe!QCoreApplication::notifyInternal2(QObject * receiver, QEvent * event) Line 988
tyqt.exe!QEventDispatcherWin32::processEvents(QFlags<enum QEventLoop::ProcessEventsFlag> flags) Line 847
tyqt.exe!QWindowsGuiEventDispatcher::processEvents(QFlags<enum QEventLoop::ProcessEventsFlag> flags) Line 75
tyqt.exe!QEventLoop::exec(QFlags<enum QEventLoop::ProcessEventsFlag> flags) Line 209
tyqt.exe!QCoreApplication::exec() Line 1261
tyqt.exe!TyQt::runMainInstance(int argc, char * * argv) Line 404
tyqt.exe!TyQt::run(int argc, char * * argv) Line 342
tyqt.exe!main(int argc, char * * argv) Line 82
tyqt.exe!WinMain(HINSTANCE__ * __formal, HINSTANCE__ * __formal, char * __formal, int __formal) Line 123
 
Last edited:
It's funny you mention that because I got my first crash in this function yesterday. Mine only happens if you have used "Reset Application (& Settings)" at least once. Did you?

I have pushed a fix for this particular bug. I'm not sure it's the same because "board->monitor" would be NULL if it was the same bug, but with a release build the debug info is not reliable at all anyway.
 
Last edited:
It's funny you mention that because I got my first crash in this function yesterday. Mine only happens if you have used "Reset Application (& Settings)" at least once. Did you?
Most likely yes.
I have pushed a fix for this particular bug. I'm not sure it's the same because "board->monitor" would be NULL if it was the same bug, but with a release build the debug info is not reliable at all anyway.
With your fix, I haven't had any crashes yet.
 
BTW, TyQt doesn't compile with my standard Qt static build due to some libraries not being included during linking by the CMake build scripts (with your Qt configure flags things work). But that's really an issue with the Qt CMake support being broken with static linking:
https://bugreports.qt.io/browse/QTBUG-38913
 
Most likely yes.

With your fix, I haven't had any crashes yet.

Cool :)

BTW, TyQt doesn't compile with my standard Qt static build due to some libraries not being included during linking by the CMake build scripts (with your Qt configure flags things work). But that's really an issue with the Qt CMake support being broken with static linking:
https://bugreports.qt.io/browse/QTBUG-38913

Qt static builds are a pain. I have a bunch of workarounds in https://github.com/Koromix/ty/blob/master/cmake/FindEasyQt5.cmake to make it work with this particular set of flags, but it's hard-coded. I'm sure it can be improved, but as you can imagine this is really not something I like to mess with. This mess is the primary reason why I (very probably) won't reuse Qt for future project. The one I'm working on currently does not use Qt.
 
Yes, you can open CMakeLists.txt with Qt Creator. For a while I maintained a set of qmake .pro files in the repository for Qt Creator, but I dropped them because they were regularly broken and Qt Creator supports CMake files pretty well. This wasn't so true a year ago.

Building TyQt this way works, but the resulting executable depends on the (heavy) Qt shared libraries / DLLs to work. To avoid that, you need to build a static build of Qt (Digia does not provide such a build). You can follow my instructions to do so at https://github.com/Koromix/ty/tree/master/qt5

Lastly, this project can now be compiled with Visual Studio 2015. The official Win32 builds use Visual Studio. Obviously I completely forgot to update the README, which still mentions that Visual Studio is not supported.

Thanks Koromix. I was able to get the static builds to work according to your note above.. but i'm still struggling to get the actual tyqt gui to compile. I am pretty sure it's solely a configuration issue in QT Creator... I think it would be easier for me to get this imported into VS2015 and go from there so I am trying to figure out how to do that now. Thanks for any additional advice. I guess if i can't get this part working, i can always resort to putting a gui wrapper around tyc.exe.
 
Yes, sorry, I've been meaning to put VS2015 instructions.

First, you need to build static Qt for MSVC (see the qt5 instructions above). Then, to generate VS2015 project files for 32-bit builds:
- 1) in the project directory, make a subdirectory "build/msvc32" (the name does not really matter here, unlike the one under the qt5 subfolder)
- 2) open the "VS2015 x86 Native Tools Command Prompt" console, go to the directory we just created and execute 'cmake -G "Visual Studio 14 2015" -T v140_xp ../..' (without the '-T v140_xp' bit the binaries won't support XP, don't ask me why you need that it's another one of Microsoft's bad ideas)

You can then find the VS2015 project files in build/msvc32, with a "ty.sln" solution.

Only Release builds will work because my qt5 instructions generate a release Qt build, it does not work in Debug because of the MSVCRT mess. I never use the VS2015 debugger so it was not a problem for me.
 
Yes, sorry, I've been meaning to put VS2015 instructions.

First, you need to build static Qt for MSVC (see the qt5 instructions above). Then, to generate VS2015 project files for 32-bit builds:
- 1) in the project directory, make a subdirectory "build/msvc32" (the name does not really matter here, unlike the one under the qt5 subfolder)
- 2) open the "VS2015 x86 Native Tools Command Prompt" console, go to the directory we just created and execute 'cmake -G "Visual Studio 14 2015" -T v140_xp ../..' (without the '-T v140_xp' bit the binaries won't support XP, don't ask me why you need that it's another one of Microsoft's bad ideas)

You can then find the VS2015 project files in build/msvc32, with a "ty.sln" solution.

Only Release builds will work because my qt5 instructions generate a release Qt build, it does not work in Debug because of the MSVCRT mess. I never use the VS2015 debugger so it was not a problem for me.

Thanks again Koromix. I'm making progress! I do still have a build error if you don't mind taking a look. It did create quite a few files & folders in the build\msvc32 directory but i did receive an error and it did not create ty.sln. Below is the cmake message and I have attached the log. I think it could because it's not finding FindEasyQt5.cmake... i wasn't real sure where to put it so i sprinkled it liberally over several of the directory paths i thought it could look in. I understand if this is getting too detailed and complicated.. i'll keep trying and thanks for your help!
View attachment CMakeOutput.log.txt
C:\ty\src\tyqt\build\msvc32>"c:\program files\cmake\bin\cmake.exe" -G "Visual Studio 14 2015" -T v140_xp ../..
-- The C compiler identification is MSVC 19.0.24213.1
-- The CXX compiler identification is MSVC 19.0.24213.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning at CMakeLists.txt:6 (find_package):
By not providing "FindEasyQt5.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "EasyQt5", but
CMake did not find one.

Could not find a package configuration file provided by "EasyQt5" with any
of the following names:

EasyQt5Config.cmake
easyqt5-config.cmake

Add the installation prefix of "EasyQt5" to CMAKE_PREFIX_PATH or set
"EasyQt5_DIR" to a directory containing one of the above files. If
"EasyQt5" provides a separate development package or SDK, be sure it has
been installed.


CMake Error at CMakeLists.txt:43 (qt5_wrap_ui):
Unknown CMake command "qt5_wrap_ui".


CMake Warning (dev) in CMakeLists.txt:
No cmake_minimum_required command is present. A line of code such as

cmake_minimum_required(VERSION 3.6)

should be added at the top of the file. The version specified may be lower
if you wish to support older CMake versions for this project. For more
information run "cmake --help-policy CMP0000".
This warning is for project developers. Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also "C:/ty/src/tyqt/build/msvc32/CMakeFiles/CMakeOutput.log".
 
Oh, I see. You need to build the whole project, not just "src/tyqt/CMakeLists.txt" which is only the GUI part of the project, without all the lower-level parts that make it work.

So the "build\msvc32" directory needs to be at "C:\ty\build\msvc32".

I guess the mistake comes from me calling the repository "ty". There was not even a plan for a GUI when I created the repository, and "ty" was the name of the command-line executable. It's not a good name, but it was easy to type "ty upload firmware.hex", and I had no name idea. I later renamed this executable "tyc" because there were not enough silly names in this project :)
 
Last edited:
Thanks again Koromix. I'm making progress! I do still have a build error if you don't mind taking a look.
...
C:\ty\src\tyqt\build\msvc32>"c:\program files\cmake\bin\cmake.exe" -G "Visual Studio 14 2015" -T v140_xp ../..
You created the build dir in the wrong place. Your build dir should be: "C:\ty\build\msvc32".

Edit: Too slow.

BTW, if you did build an x64 version of Qt, you want to use:
cmake.exe -G "Visual Studio 14 2015 Win64" -T v140_xp ../..
 
Last edited:
You created the build dir in the wrong place. Your build dir should be: "C:\ty\build\msvc32".

Edit: Too slow.

BTW, if you did build an x64 version of Qt, you want to use:
cmake.exe -G "Visual Studio 14 2015 Win64" -T v140_xp ../..

Thanks tni. I had actually tried that first... and didn't get quite a far. I think i need to go through and re-read all of the QT static build documentation and learn more about cmake... I've never used it before as most of my development is in VS. I'll need to go through all this again on the Mac once i get it working on the PC so I think i need to understand it a bit better. Below it the output of running it at the c:\ty\build\msvc32 dir.

C:\ty\build\msvc32>"c:\program files\cmake\bin\cmake.exe" -G "Visual Studio 14 2015" -T v140_xp ../..
-- The C compiler identification is MSVC 19.0.24213.1
-- The CXX compiler identification is MSVC 19.0.24213.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found WindowsSDK: C:/Program Files (x86)/Windows Kits/10;C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A;C:/Program Files (x86)/Microsoft SDKs/Windows/v8.1A;C:/Program Files (x86)/Windows Kits/8.1;C:/Program Files (x86)/Windows Kits/8.0;C:/Program Files (x86)/Microsoft SDKs/Windows/v7.1A
-- Looking for stpcpy
-- Looking for stpcpy - not found
-- Looking for asprintf
-- Looking for asprintf - not found
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.8.1.windows.1")
fatal: Not a git repository (or any of the parent directories): .git
CMake Error at CMakeLists.txt:130 (string):
string sub-command SUBSTRING requires four arguments.


CMake Error at cmake/FindEasyQt5.cmake:36 (find_package):
Could not find a package configuration file provided by "Qt5" with any of
the following names:

Qt5Config.cmake
qt5-config.cmake

Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR"
to a directory containing one of the above files. If "Qt5" provides a
separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
src/libtyqt/CMakeLists.txt:6 (find_package)
 
Last edited:
Correction... the second time i tried it at c:\ty\build\mscv32 but using the ""Visual Studio 14 2015 Win64" option i did get further... just taking a look at the new errors to see if i can figure them out... thanks guys!
 
This means you built Qt for 64-bit builds. You should probably omit "-T v140_xp" for 64-bit builds because there's no point to XP support in this case. I had to put a few workarounds in my CMake files to make "-T v140_xp" work (again, thanks Microsoft) and I didn't test them for 64-bit builds.
 
You should probably omit "-T v140_xp" for 64-bit builds because there's no point to XP support in this case.
A 64 bit version of XP exists (it's based on Windows 2003 Server x64).
I had to put a few workarounds in my CMake files to make "-T v140_xp" work (again, thanks Microsoft) and I didn't test them for 64-bit builds.
It compiles fine.
 
Last edited:
I know Windows XP 64 exists, but it had many problems and the driver support was poor. The number of XP-64 users is probably *much* lower than XP, so not worth any effort. If anything, in a year or two I may drop XP support entirely.
 
Back
Top