feature(shields): Add nice!view

[Nicell]

Board/Shield Check-list

• This board/shield is tested working on real hardware
• Definitions follow the general style of other shields/boards upstream (Reference)
• .zmk.yml metadata file added
• Proper Copyright + License headers added to applicable files (Generally, we stick to "The ZMK Contributors" for copyrights to help avoid churn when files get edited)
• General consistent formatting of DeviceTree files
• Keymaps do not use deprecated key defines (Check using the upgrader tool)
• &pro_micro used in favor of &pro_micro_d/a if applicable
• If split, no name added for the right/peripheral half
• Kconfig.defconfig file correctly wraps all configuration in conditional on the shield symbol
• .conf file has optional extra features commented out
• Keyboard/PCB is part of a shipped group buy or is generally available in stock to purchase (OSH/personal projects without general availability should create a zmk-config repo instead)

[caksoylar]

Is this definition intended to be used along with other shields using a build definition with multiple shields? If so, does the Github actions workflow support such a definition through build.yaml?

Is this also supposed to be compatible with nice!nano only (or with pro micro boards, for that matter)? I don't see why that should be, but it seems like the case from the SPI node alias.

[Nicell]

Is this definition intended to be used along with other shields using a build definition with multiple shields? If so, does the Github actions workflow support such a definition through build.yaml?

Exactly! The GitHub actions workflow should work fine according to Pete... I need to test it though. Should just need to update the build.yaml shield prop to have nice_view after the existing one, so user configs should be fine. The repository's build workflow does need to be updated though.

Is this also supposed to be compatible with nice!nano only (or with pro micro boards, for that matter)? I don't see why that should be, but it seems like the case from the SPI node alias.

Should be compatible with all the other Pro Micro boards, I just need to define SPI nodes/aliases for others, which is on my todo.

[petejohanson]

Some initial thoughts!

[Nicell]

Our requires/exposes system doesn't really handle this new type of interconnect (built on top of a complete keyboard, not to create one). We'll need to figure out how we handle this with our build system and our hardware docs page. I've set up stubs and done nothing with them for now for both the build system and docs.

[petejohanson]

A few follow up thoughts.

I think each shield deserves a readme file as well to explain their use, lacking tooling for this in some setup script.

[petejohanson]

I think omit this entirely? Have folks override the cs-gpios property in their keymap for whatever pin they bodged.

[Nicell]

It'd be nice to allow for this to be a default fallback. I'll likely put in the docs for the nice!view to use this pin if available. (it should be for most since it's on the trrs serial pin)

[petejohanson]

As long as this is clearly documented there, and in the README, that's fine.

[petejohanson]

I think last thing: can you please add board overrides for the other in-tree nRF52 boards, e.g. nRFMicro, etc?

[petejohanson]

Sorry, one last thing I noticed after a re-read of this.

[petejohanson]

I think this should be removed. The adapter itself doesn't add a display.

[petejohanson]

Thanks!