Closed Defragster closed 3 years ago
Hello @Koromix and @Defragster @mjs513 - I think I have most of the editing done to support the MicroMod, but I am in link/library heck trying to get an executable. I tried deleting all I have, downloaded again. Downloaded the QT5 you mentioned for Window 64 bit. in Readme of lib directory, I then went up and did the instructions to create the build directory I made win64 cd to it, cmake... Then loaded the solution file and then tried to build.
7>tycmd.vcxproj -> D:\GitHub\tytools\build\win64\Debug\tycmd.exe
8>Automatic MOC for target tycommander
6>test_libty.vcxproj -> D:\GitHub\tytools\build\win64\Debug\test_libty.exe
9>Automatic MOC for target tyupdater
8>qwindows.lib(main.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in mocs_compilation_Debug.obj
8>qwindows.lib(main.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindowsgdiintegration.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindowsgdiintegration.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindows_plugin_resources.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindows_plugin_resources.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindowsintegration.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindowsintegration.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindowsbackingstore.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindowsbackingstore.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in mocs_compilation_Debug.obj
8>qwindows.lib(moc_qwindowsnativeinterface.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in mocs_compilation_Debug.obj
8>qwindows.lib(moc_qwindowsnativeinterface.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindowsnativeinterface.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindowsnativeinterface.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in mocs_compilation_Debug.obj
8>qwindows.lib(moc_qwindowsgdinativeinterface.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in mocs_compilation_Debug.obj
8>qwindows.lib(moc_qwindowsgdinativeinterface.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindowsgdinativeinterface.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in mocs_compilation_Debug.obj
8>qwindows.lib(qwindowsgdinativeinterface.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in mocs_compilation_Debug.obj
...
I think from last time there is some issues on Static vs dynamic library and debug stuff...
My WIP changes are up at: https://github.com/KurtE/tytools/tree/teensy_mm
Thanks, if it works for you I'll make a dev build soon.
The Qt static build does not work (currently) with "Debug" TyTools builds, just set the build to "RelWithDebInfo" (or "Release") in Visual Studio and it should work.
Good to hear Niels.
Kurt got it to build debug and will test it tomorrow - about 6+ hours. Nice he can just test the debug and you can do a 'normal' Release build with libs and all working.
Morning, actually I was able to get a release version to build and it at least runs. I have not tested it much but it did show up as Micromod...
@Defragster if you wish to try it, I know from last time that binaries I built my or may not be runable by others due to virus detection on different machines.
What I did was to delete (actually I renamed) the directory that I had for github. I then told github for windows to redownload. I then went into the lib\qt5 directory and looked at the README.me there and I followed the instructions for the 64 bit static MSVCRT (using VS 2019).
I cut and pasted the batch stuff there... Then in the same x64 native tools command window, I went back to the main readme and at the root of project created the build directory then the build/win64 directory and cd and did the cmake ../..
When that completed I then opened up the solution file as mentioned. And then did a build that failed.
BUT: I then later changed the build from Debug to release and it completed :D
Not sure if it is easier for you want to try this, or for me to try to copy these files to someplace like OneDrive or Apple drive stuff... I am pretty sure I can not easily post it or email it...
@Kurte - just glanced at your changes - look decent - I forgot to pass the new PID value to @Koromix Not seeing a release to try anywhere?
Seems there is one Command line selection area not found to ID T.MM for upload in the selection dialog?
In this file : T:\TyCommKE\tytools-teensy_mm\src\libty\class_teensy.c
It seems like this func() : teensy_upload()
May be failing without notice before doing the upload?
Here is TyComm verbose output for attempted upload? [upload@8473300-Teensy] *** teensy_identify_models [upload@8473300-Teensy] flash: 5601000042464346 [upload@8473300-Teensy] flash size: 1000000 [upload@8473300-Teensy] Matched TY_MODEL_TEENSY_MM [upload@8473300-Teensy] Uploading to board '8473300-Teensy' (Teensy MicroMod) [upload@8473300-Teensy] Triggering board reboot Received removal notification for device 'USB\VID_16C0&PID_0483&MI_00\6&3354DE81&0&0000' Received removal notification for device 'USB\VID_16C0&PID_0483\8473300' Remove device 'USB\VID_16C0&PID_0483\8473300' Received arrival notification for device 'USB\VID_16C0&PID_0478\000CEDE2' Examining device node 'USB\VID_16C0&PID_0478\000CEDE2' Device 'USB\VID_16C0&PID_0478\000CEDE2' has no 'PortName' registry property Received arrival notification for device 'HID\VID_16C0&PID_0478\6&156F921F&0&0000' Examining device node 'HID\VID_16C0&PID_0478\6&156F921F&0&0000' Found port number of 'USB\VID_16C0&PID_0478\000CEDE2': 8 Found controller ID for 'USB\ROOT_HUB30\4&3765104F&0&0': 2 Add HID device 'USB\VID_16C0&PID_0478\000CEDE2' on iface 0
That last line from : static int run_upload(ty_task *task) seems to be out of place though? It should be doing the upload from TyComm - not waiting for loader ... so maybe it isn't getting to the above.
Also the normal allow TyCommander to be used in IDE without integration to hand off to Teensy Loader is not working here? It is hanging in Teensy Loader?
Yep - those debug messages were things I added to try to track down...
But it does not run that way if I do the integrate and run it from Arduino IDE, it then goes sort of the same route as the T4.1 That looked something like:
d HID device 'USB\VID_16C0&PID_0478\000BB967' on iface 0
- USB VID/PID = 16c0:0478, USB location = usb-1-1-1-1
- USB manufacturer = (none), product = (none), S/N = 000BB967
- HID usage page = 0xff9c, HID usage = 0x25
*** teensy_load_interface
*** Type HID
*** HalfKey
Identified 'Teensy 4.1' with usage value 0x25
*** Model: 13
*** teensy_update_board
[upload@7683590-Teensy] *** get_halfkay_settings model: 13
[upload@7683590-Teensy] Firmware: MSCFormatter.ino.teensy41.hex
[upload@7683590-Teensy] Flash usage: 98 kiB (1.2%)
[upload@7683590-Teensy] Sending reset command (with RTC)
[upload@7683590-Teensy] *** get_halfkay_settings model: 13
...
But we are not getting to that part. Almost wondered if something in the TSET stuff is getting it?
FALSE ALARM - IT WORKS WITH TSET !!!!!
TSET needs this NAME CHANGE MADE :: if "%model%"=="teensyMM" set model=TEENSY_MICROMOD
Before building to get the proper HEX NAME.
In boards.txt it expects teensyMM
However the official board name in #ifdef's is TEENSY_MICROMOD and that is the resulting .HEX NAME
With KurtE 'test' TyCommander it works in Sublime w/TSET IDE with integration to 'test' version works
Issue when not 'Integrated' ?? @koromix : when TyComm is open the 'test' build does not surrender the USB COMM port to the IDE like I thought it would? And hitting the RESET alone causes it to fail the TeensyLoader programming?
Is there another code path to recognize that?
I think I will remove some of the debug output that I added to see what was going where. and then setup to issue PR..
Sounds good the 'test' TyCommander is working fine from here!
I think the other 'Issue' noted above is the same with T_4.1 and not new behavior.
That behavior works when compiling STM32 boards - TyComm somehow knows to release the port for them. I thought it did for Teensy as well but apparently not - it require a 'Bootloader' button when not integrated to allow Teensy Loader to program.
Thanks!
I've merged your changes into the repository with minor code style fixes. I can't test your PR, I trust you that it works :)
BTW is this new Teensy already out? If so I can make a release with this change.
Looks like it is not yet released. Here the current MicroMod boards:
No the Teensy MicroMod is not released or even officially announced yet – except that Teensy Forum thread.
Thanks, Look forward to testing and working with it.
Is there a build published? It won't likely be changing - so if included in an official release it wouldn't cause any harm, and not likely to need redone if it works, it would only add support for the new board.
Windows builds here: https://koromix.dev/files/tytools/ Sorry, no macOS because that involves booting up my 2009-era HDD-based MacBook (with broken WiFi and ethernet) and I only do that for releases :)
This project used to have CI integration some time in the past, with AppVeyor (for Windows) and Travis (for Linux and macOS). Dev builds used to flow out of this automatically :) Eventually it broke, like everything that is based on the house of cards that is modern tooling and build systems, and I'm too old and grumpy to deal with nightmare-YAML-based-CI-system-of-the-month so I ripped it all out in a rage. But if someone more patient than me wants to restore this, you're more than welcome :)
Windows build seems good for Teensy MicroMod upload! Thank you.
@KurtE and @mjs513
@Koromix - in beta now is Sparkfun's MicroMod MCU board with a Teensy bootloader and 1062 processor.
As far as uploading the FLASH went to 16MB ( instead of 2MB on 4.0 and 8MB on 4.1 )
And it has a new ID of 0x26, but works and acts like the T_4.x's other wise AFAIK using the PJRC bootloader chip
Beta hardware just released to three of us using TyCommander so far ... is it easy to put out an interim build that would recognize it to work?
Thanks for any feedback, @defragster
@KurtE and @mjs513