Added shield temper_dongle + BLE/USB toggle keys - #72
Conversation
- boards/shields/temper_dongle: shield dongle autonome (central, 2 peripheriques, BT_MAX_CONN/PAIRED=7); keymap resolu vers config/temper.keymap - zephyr/module.yml: board_root pour exposer le shield local - build.yaml: 4 entrees dongle sur nice_nano@2//zmk (variante zmk requise pour BLE/USB sur ZMK recent), artifact-names distincts - selenium.keymap: &out OUT_BLE/OUT_USB/OUT_TOG sur la couche FnMedia - settings.h: prefs layout (hote AZERTY + emulation ErgoL, macOS) Co-Authored-By: Claude Opus 4.8 <[email protected]>
Nuclear-Squid
left a comment
Nuclear-Squid
left a comment
There was a problem hiding this comment.
This looks pretty good ! There are a couple of things I’d like to go over with you though. The main one is the firmware for the dongle itself. I trust that it works well, but I’d rather not having any custom board or shield in this repo, that way we can completely separate the concerns of the keymap from the electronics (while also providing the community hardware support that isn’t specifically for this project ^^).
What this entails, is that you create a new GitHub repository for your driver (you can fork the zmk-module-template repo for this), then add your repo to the list of imports Ækeynox does by editing the config/west.yml file.
If you want an example of this kind of thing in action, we’ve done this for the support of the Chocofi Temper some time ago : #58
Import the temper_dongle shield from its standalone module (niiico69/zmk-keyboard-temper-dongle) via config/west.yml, add the three dongle/peripheral builds to build.yaml, and wire BLE/USB output toggles (&out OUT_BLE / OUT_USB / OUT_TOG) on the Fn/Media layer. The hardware definition lives in the external module so the keymap repo stays free of custom boards/shields.
|
Done |
|
Trying to get this PR back into review mode… If I get this right, there are two concerns here:
Is that correct? EDIT: seeing your repo, I understand this patch would be very specific to the Temper. So these USB dongles are generic, but they must be flashed specifically for a given keyboard, right? |
| #include <dt-bindings/zmk/bt.h> // bluetooth behaviors (see fn/media layer) | ||
| #include <dt-bindings/zmk/outputs.h> // &out OUT_TOG (see fn/media layer) |
There was a problem hiding this comment.
This comment doesn’t help much. What is this key supposed to do?
Do you know if including these two libraries has a significant impact for low-memory devices like the Ferris?
| include: | ||
|
|
||
| ### |
There was a problem hiding this comment.
Nitpick: please don’t change any code that’s not relevant for your patch.
(And most of the time, line skips are there to ease the readability and code navigation with Vim. These might be weak reasons, but we tend to like that kind of details. ;-))
| # Bad Temper BLE with dongle (aekeynox keymap) | ||
| # Distinct artifact-names: the dongle-mode halves are peripherals (CENTRAL=n), | ||
| # a different firmware from the nice_view temper_left/right central builds above. |
There was a problem hiding this comment.
Is there any reason to call it Bad Temper instead of Temper?
There are several configs that handle several keyboards, and I think it makes sense to stick to the name defined in the config directory:
cradiofor Cradio, Hyperbolic, Sweep…temperfor Fifi, Chocofi, Temper, Bad Temper…
| - board: nice_nano@2//zmk | ||
| shield: settings_reset | ||
| artifact-name: bad_temper_settings_reset |
There was a problem hiding this comment.
I would expect these reset targets to depend only on the MCU, not the shield. Am I wrong?
There was a problem hiding this comment.
They don’t rely on the shield yeah, the point is to override a section of the flash memory that is normally left untouched by the firmware. We can safely remove this, I think
|
Hi, I'm on vacation and can't reply accurately right know. Since this PR is 2 months old, if we're not in a hurry, I'd like to take some time to answer correctly 😅 |
|
Sorry for the lag! Sure, take all the time you want. Enjoy your holidays! 😄 |
3 participants
No description provided.