Overwhelmed on an NRF5280 Wireless Conversion

[wind plover]

Hello,

I am trying to convert a wired keyboard kit to a wireless (Bluetooth) solution and I feel overwhelmed and lost. I have read many different guides and sources about how this is done, some of which don't explain what tools serve what purpose, and others that are in different languages -- can someone please help me understand:

1. If a keyboard creator originally wrote wired firmware for a board using QMK, can I even ask for help using ZMK in this community? Can I try to build off their work and use it for my personal build if I don't submit it to the github repo for public use?

1.a If not, are there any wireless hardware options that build off of QMK firmware I could use as an alternative? I also looked at BlueMicro_BLE but it seems that ZMK has active community work/development and BlueMicro_BLE does not

2. If so, does a ProMicro NRF5280 work for a wireless option as a drop-in substitute for from the ProMicro ATmega32U4, or should I use a different controller/board? Should I use a nice.nano?

3. If it does work, would there be a good method in this community to request paid tutoring or guidance? I feel like I have no bearing on what does/doesn't work and I'm trying to avoid sinking dozens more hours into a solution for something that simply may not work that someone else may have already found an answer to.

I work in a technical discipline and am familiar with code, but writing firmware feels like swimming up a waterfall. I am happy to unpack the steps I have taken (and guides) to replicate where I am stuck at, but I'm trying to keep my post brief.

Thank you very much for your time,

[drifting perch]

HI there,

If a keyboard creator originally wrote wired firmware for a board using QMK, can I even ask for help using ZMK in this community? Can I try to build off their work and use it for my personal build if I don't submit it to the github repo for public use?

Sure, feel free to ask. You can reference code and use for personal use, as long as you don't release it under an incompatible license (safest would be to use what they use)

If so, does a ProMicro NRF5280 work for a wireless option as a drop-in substitute for from the ProMicro ATmega32U4, or should I use a different controller/board? Should I use a nice.nano?

Should be fine, they might have reliability issues so buy a few extra

If it does work, would there be a good method in this community to request paid tutoring or guidance? I feel like I have no bearing on what does/doesn't work and I'm trying to avoid sinking dozens more hours into a solution for something that simply may not work that someone else may have already found an answer to.

If you share what keyboard you are trying to port, maybe there is one already? Or, people might at least be able to tell if something is impossible or not.

Otherwise, #commissions can be used for paid work, or just keep asking questions and share what you tried when you have trouble with something

[viscid kelp]

i believe all you have to do is connect the same pinouts from the PCB to your micro controller, so sometimes the PCB's dont line up correctly with the microcontrollers. But if they do you just just be able to drop in the wireless board and install zmk normally

[mild jay]

I managed to replicated this solution with nice! nano v2.

[wind plover]

Thank you very much for the information.

I am currently trying to convert a DailyCraft / owl8 -- which has firmware for the kit under QMK here: https://github.com/qmk/qmk_firmware/blob/4e2191ce20564e520b27248513cdfc5aac897ab6/keyboards/dailycraft/owl8/keyboard.json#L4

Where I stand right now:

• I have the board built, functional, and working with the wired USB-C ProMicro ATmega32U4 controller and have updated/flashed the firmware. I have 2x ProMicro NRF5280 controllers, I read on reddit that they were a swap-in for the pin-out of the existing board (+/- 2 extra pins). I haven't soldered anything to the controller and am using some standoffs for swapping the wired/wireless controller for testing.

What I need to do next (?)

• I need to write a .uf2 firmware file, with the relevant shields/layout/C code to be compiled for the NRF5280 -- this is the part I am feeling lost on, since I'll be reverse engineering the rows/columns logic from the QMK option to ZMK compatible logic,
• Then, I need to flash the firmware flashing it (which I'm also unclear on, some guides say I need to use Ardunio software for this particular controller -- others insist on a web interface via Google Chrome only due to it supporting access to the Web Serial interface?)

After that:

• I don't yet understand what my options are to assign key functions, apart from re-writing the keycodes and re-building/flashing the firmware? Is there a GUI software like VIA that allows updating key bindings more easily?

[timber sable]

Just to make sure, you mean nRF52840 right? One of these https://github.com/joric/nrfmicro/wiki/Alternatives

make a firmware
Follow this guide https://zmk.dev/docs/development/hardware-integration/new-shield

flash the firmware
Connect the controller via USB, short RST pin to GND twice within 500ms (or double tap reset button if your keyboard has one, does the same thing), the controller will go in bootloader mode and reconnect to your PC as a virtual USB drive (it's not a real storage device, just a virtual representation of the controller memory). Drag/copy the .uf2 file onto that USB drive and it's done.

assign key functions
Edit the .keymap file, recompile, re-flash. Flashing new firmware is really easy like I said, you don't need special software and you can do it anywhere.
Or use ZMK Studio but it currently still lacks a few features compared to editing .keymap files.
https://zmk.dev/docs/features/studio

[wind plover]

Yes, sorry -- an nRF52840. Thank you for the instruction, I will try to step through the guide.

[wind plover]

I have worked through the new-shield docs and am confused by this step: https://zmk.dev/docs/development/hardware-integration/new-shield#github-actions

It states:

    If your shield is defined in your zmk-config, then the shield should start building.

    If the shield is defined in a separate module, you will need to adjust your west.yml to reference the module.

However, I have no zmk-config folder. Is this outdated documentation? I feel like what I'm supposed to do is push my code to my forked repo, create a PR, and let the .github/workflows/build.yml trigger a GHA runner that will produce an artifact (presuming a .uf2 file) -- but I don't understand what this zmk-config path is, or what I need to "update"

Any advice?

[drifting perch]

zmk-config is used to refer to the repo itself

It needs a bit tweaking to make it clearer

So you are looking for build.yaml at the root of the repo

[wind plover]

Thank you for the clarification. What do I exactly need to update? Or is the update instruction conditional on if I'm using a separate module?

[drifting perch]

No, the Github workflow will always use that file contents to determine what to build

See https://zmk.dev/docs/customization#building-additional-keyboards

You will add board/shield combinations for your keyboard

[wind plover]

I see, so I will include the board type (in my case the nRF52840 and then specify my shield per each board/shield pairing. Yes?

[drifting perch]

It's the specific board, then each of your shields

Since your keyboard is not split, you want one item like this:

---
include:
  - board: nice_nano_v2  # the pro micro nrf52840 is a clone
    shield: owl8  # assuming your shield name

[wind plover]

Oh, does nice_nano_v2 include the nRF52840? I thought they were separate

Sorry, missed your comment that it's a clone.

I will give that a try.