Note the ncs shell thing which packs its own python iirc which can cause troubles, although you are not operating on that level yet - the west patvh should work outside of the ncs shell so this should be ignorable.
I would start by installing the requirements.txt packages with pip3.
Now Iāve reached a point where I cannot build because CMake stubbornly refuses to read the āARMGCC_DIRā environment variable even though it is very much set. Iāve tried in both bash and zsh.
Sorry for the delay.
Yes, I do an export ARMGCC_DIR='/usr/bin' in both ~/.zshrc and ~/.bashrc
Also, I have tested out another tweak to HRMs in my macro: Minimum key press time required for a key to be allowed to trigger as secondary. It works very well, and I will also be making a Feature request for that on Github Soonā¢. I am up to 5 distinct requests planned, 4 of which are tested in the macro.
Actually, is that correct? Readme says (for linux):
export ARM_GCC_DIR="/usr"
Iirc ARMGCC_DIR is set automatically by the build machinery depending on the ARM_GCC_DIR. My guess is that since your ARM_GCC_DIR is (probably) empty, the build machinery actually clears the ARMGCC_DIR when trying to assign it.
The timeline of my failure was that I didnāt export it the right place first, then saw the ARMGCC_DIR variable in the error message and went all in on that.
Now Iām seeing this:
-- Found assembler: /usr/bin/bin/arm-none-eabi-gcc
CMake Error at /home/someuser/UHK/uhk-workspace/mcuxsdk/cmake/extension/mcux.cmake:25 (__project):
The CMAKE_C_COMPILER:
/usr/bin/bin/arm-none-eabi-gcc
Looks like too much bin, doesnāt it?
EDIT: Oops, doxed myself a tiny bit there. Donāt stalk me please.
Should have mentioned that I already did that. Rebooted and everything. Searched my entire home dir for instances of ARM_GCC_DIR and ARMGCC_DIR to make sure I had no old exports from previous tinkering. I can find no reason for this error in my setup. This does not of course rule out that itās my fault.
The file /usr/bin/arm-none-eabi-gcc exists.
My guess was that at least an option for āsame hand detectionā and maybe some āminimum idle timeā would overlap between our wishes. But Iāll wait to read your requests once they are available.
Is it possible that the path is cached somewhere in the build directory from some earlier failed attempt? I.e., are you doing a pristine build? Have you tried to delete the device/build directory?
Now I canāt make west flash the build because Iām missing LinkServer.
When I try the other method under " UHK60 Minimal development setup", I fail at the step with npx tsc. I get Found 39 errors in 20 files..
Iām running node 20.18 as per request of output from the cd lib/agent && npm ci && npm run build part.
Iirc, you need to npm install in the firmware root, and have lib/agent built. Please fetch and checkout fresh master in the lib/agent repo - we are not updating the git version reference as dutifully as we should.
Then using ./build.sh rightv1 flashUsb should do the trick (with uhk60v1). (Alternatively, see its sources; it just calls lib/agent/packages/usb/<flashing script> with proper product id and firmware path).
Please elaborate on the npx tsc step. It doesnāt ring the bell, so I suspect it might not be needed.