zmk
zmk copied to clipboard
Added nRF52840 Feather Express support and MF68 shield
Board/Shield Check-list
- [X] This board/shield is tested working on real hardware
- Partially: only the nRF52840 Feather Express configuration
- [X] Definitions follow the general style of other shields/boards upstream (Reference)
- [X]
.zmk.yml
metadata file added - [X] 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)
- [X] General consistent formatting of DeviceTree files
- [X] Keymaps do not use deprecated key defines (Check using the upgrader tool)
- [X]
&pro_micro
used in favor of&pro_micro_d/a
if applicable - [ ] If split, no name added for the right/peripheral half
- [X] Kconfig.defconfig file correctly wraps all configuration in conditional on the shield symbol
- [X]
.conf
file has optional extra features commented out - [X] 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)
Is there a reason the upstream Zephyr board definition didn't work?
Zephyr's definition has a memory map for which is necessary to use a hardware programmer to flash the board, with my edits it's possible to generate a functioning UF2 file, and it disables functions like UART, SPI, I2C, and the QSPI flash due to the low number of available pins
Zephyr's definition has a memory map for which is necessary to use a hardware programmer to flash the board, with my edits it's possible to generate a functioning UF2 file, and it disables functions like UART, SPI, I2C, and the QSPI flash due to the low number of available pins
I wonder if we going to accomplish the same thing, by adding an application specific board overlay in our repo instead of completely duplicating the board.
To be clear, very grateful for the contribution, just want to be sure we're taking the right path to better support that board.
To be honest, I'm sure you know the right approach better than me since I'm not really experienced in contributing to this kind of project, but my thought process was that Zephyr is a larger, more complex project used by embedded developers and even companies, while ZMK is targeted mostly towards keyboard enthusiasts that aren't necessarily accustomed to working on this kind of software. The ZMK "target audience" would certainly benefit from the changes I made
To be honest, I'm sure you know the right approach better than me since I'm not really experienced in contributing to this kind of project, but my thought process was that Zephyr is a larger, more complex project used by embedded developers and even companies, while ZMK is targeted mostly towards keyboard enthusiasts that aren't necessarily accustomed to working on this kind of software. The ZMK "target audience" would certainly benefit from the changes I made
Yeah, I would much rather we add:
-
app/boards/adafruit_feather_nrf52840.overlay
to change the code partition settings for UF2, disable certain nodes for SPI, etc. -
app/boards/adafruit_feather_nrf52840.conf
to override whatever Kconfig settings we need to.
Are you interested in refactoring to that?
Thanks again.
Fine by me, I'll work on the refactoring as soon as I can
@exentio Could you split the feather and mf68 changes into two separate PRs?
Yes, I'll split them once I finish with the refactoring, I've been focusing on something else at the moment. Do you suggest closing the PR and making two new ones, or renaming this one and keeping it for the board definition?