Paw

[KnoblesseOblige]

This adds the Paw macro pad to ZMK.

I have rebased against main. Firmware builds successfully.

[Nicell]

@KnoblesseOblige This message wasn't put here when the metadata changes came out. Please review these changes if you'd like to update and get this board merged in! Some parts may not be applicable to your board FYI.

Thank you, contributor, for your patience with how long review and merge of boards/shields has taken!

There are three recent refactors/changes to boards and shields that require some attention, and then we can finally get this PR merged!

1. Hardware Metadata
2. Pro Micro shield DT naming changes
3. Split changes for BLE advertising

Hardware Metadata

The Problem

When first developing the process around contributing new shields/boards to ZMK, we failed to recognize that several key files (setup scripts, documentation page of supported hardware, and GH Action build.yml file) required changes, often in the same spot, for every PR. This resulted in immediate merge conflicts for every other PR after one was merged, which is a headache for contributors.

The Fix

By adding discrete metadata files that are located with the boards/shields in question, and using that metadata to generate setup scripts, website hardware list, etc., users can contributing new hardware descriptions without the need to change the same files that other contributors are changing.

Next Steps

First, refer to https://zmk.dev/docs/development/hardware-metadata-files to familiarize yourself with the new metadata file format.

Next, you have two options for fixing up your PR:

1. If comfortable with git rebase, perform an interactive rebase and revert any changes to build.yml, hardware.md, or the setup scripts setup.sh/setup.ps1, and then add the new metadata YAML file. Then force push your branch. Or,
2. Create a new branch from an up-to-date main, copy in the files for your new hardware, add the metadata file, then commit and push the new branch. Then, edit your open PR to point to your new branch.

Pro Micro shield DT naming changes

In #876, we have simplified the DT naming for the "nexus node" we expose for pro-micro compatible boards, deprecating the use of pro_micro_a, and renaming pro_micro_d node to simply pro_micro. For pro-micro boards and shields, you'll need to adjust your DT to use the proper names.

Please see https://zmk.dev/docs/development/new-shield#shield-overlays for the updated docs on this.

Split Shield Advertising Changes

In addition, if this is a split PR, please see #658 where we have changed our conventions to remove the the name from the right sides, to prevent users attempting to pair with them and causing split sync issues. This also includes removing the " Left" suffix from the naming on the left side. See the changes in that PR for examples of what to change with your split shield.

Getting Help

If you have any questions about any of these changes, please comment here and tag @zmkfirmware/boards-shields or ask in the #boards-shields Discord channel.

[lesshonor]

This PR should be closed.

While I am reviewing it in good faith for the sake of constructiveness, I am confident there is no chance the originator will make any modifications to this code. Nearly two years of radio silence after Nicell's comment aside, KnoblesseOblige has ceased all communications regarding much more serious financial matters.

Should KnoblesseOblige reappear on the scene and—improbably—wish to see Paw's firmware through to whatever state ZMK exists in at that point, I'm sure they would be capable of opening a new PR (...or even requesting that this one be reopened).

[lesshonor]

This file should be deleted. ZMK now uses Zephyr's UF2 generation as part of the changes made in the move to Zephyr 3.0.

[lesshonor]

Suggested change

	CONFIG_BUILD_OUTPUT_UF2=y

See previous comment re: the move to Zephyr 3.0.

[lesshonor]

Suggested change

	#include <nordic/nrf52840_qiaa.dtsi>
	#include <nordic/nrf52840_qiaa.dtsi>
	#include <dt-bindings/led/led.h>

This too is part of the upgrade to Zephyr 3.0.

[lesshonor]

Suggested change

	spi-zero-frame = <0x40>;
	spi-zero-frame = <0x40>;
	color-mapping = <LED_COLOR_ID_GREEN LED_COLOR_ID_RED LED_COLOR_ID_BLUE>;

See previous comment re: Zephyr 3.0 upgrades.

[lesshonor]

You would also need to migrate the pin details to use the pinctrl subsystem for a chance at acceptance—but that at least does not cause compilation to fail, so I will leave the implementation details to you.