HRM/Secondary Role - Yet another way. With examples!

Argh. Python is pain.

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.

Are you exporting t so that it is inherited by subshells?

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.

I have added a fallback to ARMGCC_DIR, since this is clearly a common pitfall. (I had also burned some time on it when setting it for the first time.)

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.

How many of them overlap and/or could be merged with my 3 requests phrased in Homerow mods Ā· Issue #797 Ā· UltimateHackingKeyboard/firmware Ā· GitHub ?

bin there, don that. You should bin one of them.
(Sorry, couldn’t help ignore those puns.)

Indeed. Just export ARM_GCC_DIR="/usr" should do the trick.

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.

None, my requests are for changes to the Secondary Role behavior inherent to the UHK.

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.

That should not require a reboot.

Quick and obvious reality check: what does echo $ARM_GCC_DIR say?

I know, but it can’t hurt.

~/UHK/uhk-workspace/firmware master
python-venv āÆ echo $ARM_GCC_DIR                                                                               
/usr

How are you triggering the build?

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?

Yeah, that was going to be my next try for when I had time for more than just a couple of quick commands. And it worked.

1 Like

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.

I will try when I can.

From the readme file in the root of the firmware repo: GitHub - UltimateHackingKeyboard/firmware: Ultimate Hacking Keyboard firmware