qmk_firmware
qmk_firmware copied to clipboard
Add Helios converter
Description
Add converter for 0xCB Helios controller board
GitHub: https://github.com/0xCB-dev/0xCB-Helios
Shop: https://keeb.supply/products/0xcb-helios
Pinout reference:
Types of Changes
- [x] Core
- [ ] Bugfix
- [x] New feature
- [ ] Enhancement/optimization
- [ ] Keyboard (addition or update)
- [ ] Keymap/layout/userspace (addition or update)
- [x] Documentation
Issues Fixed or Closed by This PR
Checklist
- [x] My code follows the code style of this project: C, Python
- [x] I have read the PR Checklist document and have made the appropriate changes.
- [x] My change requires a change to the documentation.
- [x] I have updated the documentation accordingly.
- [x] I have read the CONTRIBUTING document.
- [ ] I have added tests to cover my changes.
- [x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).
Hi, @zvecr thank you for looking into this! Just one quick question:
The changeset also doesnt configure
USB_VBUS_PIN
so adds little value over the existingSparkFun RP2040
converter.
Can I add #define USB_VBUS_PIN 19U
to the _pin_defs.h file, or should I use OPT_DEFS += -DUSB_VBUS_PIN=19U
(would that even work?) in the converter.mk file?
The changeset also doesnt configure USB_VBUS_PIN so adds little value over the existing SparkFun RP2040 converter.
This is something I've actually been meaning to raise - the elite_pi
converter lacks a configuration of USB_VBUS_PIN
even though it also has VBUS detection implemented on GPIO 19. This pin assigment is part of the Bastardkb standard
.
In this case maybe this can be folded in with the elite-pi and the USB_VBUS_PIN
configured to make a unified converter?
This seems to work :+1:
@zvecr @casuanoob maybe we could create a bastardkb converter? That would cover all boards following the standard and avoid confusion with multiple converters.
A common converter would be the general direction I would like to see things go in. However it would be somewhat dependent on something like #19533. There is also the issue with name, as throwing the term "bastard" around might lead to some issues with derogatory language.
yeah definitely :thinking: @bstiq maybe you could suggest something?
If I recall correctly, elite_pi
is the "bastardkb standard" pin definition?
Hey,
Common converter seems like a good idea. We agreed on reusing the elite-pi pin assignment for the bottom row because it was difficult for him to change the pin assignment, and we expect a lot of people to use those.
Re: converter name. I'd like to keep the reference to the bkb server somewhere as the standard comes from there and I've pushed actively for it. However you are correct - using the full word "Bastard" can have negative connotation (unless you are a french person coming from the north of France).
Imho, the name should also reflect the fact that it's a standard, and therefore encompasses multiple boards (splinky, elite-pi, Liatris, Frood Helios etc...). Something like elite-pi
and helios
implies the converter is only for those specific boards and may or may not be compatible with the others.
Pushing a standard also encourages others creators to follow it, and makes cross-compatibility easier for the end user who just wants to buy a RP2040 controller and compile his firmware for it.
Converter name ideas:
- bkb-standard
- bk-converter
Let me know what are your thoughts, I'm not super set on the name.
Also pinging @0xcharly on the vbus issue.
EDIT: might be worth linking this as well: https://github.com/Bastardkb/technical-docs/wiki/RP2040-controllers
Converter name ideas: bkb-standard bk-converter
"bkb-standard" stylised as bkb_standard
would be my preference from the suggestions. Slight reservations for a "something-converter" converter due to the repetition. But any combo of "standard"/"common"/etc with some form of prefix works for me.
@zvecr should I redo the PR to make a bkb_standard and update the docs? Would be happy to progress this :smile:
For completeness sake, the above is the current documentation for the standard, as authored by @leah-splitkb and currently pinned in BastardKB's Discord server. All the red pins are adapted from Sparkfun, the black ones are added by the community.
When it comes to naming I'd suggest using a different one. "BastardKB RP2040 standard" was a working name because it originated from their Discord server, but it is a community effort rather than a BastardKB-specific creation, and based on SparkFun's controller at that, with efforts primarily from Leah and Chris (designer of the Elite Pi). Using a vendor-specific name would, in my opinion, be disingenuous.
As the standard is used by various controllers, designed by various creators and vendors, and sold through various vendors, I'd propose a more common name for the standard such as "Common Pi Controller", having a converter name such as "rp2040-common".
I think it is beneficial to document this standard within QMK as well, so other creators can choose to implement it to prevent further converters from having to be added.
I would be extremely hesitant to push forward with Common Pi Controller
/rp2040-common
. It is far too generic that it will lead to confusion about what it actually implements.
with efforts primarily from Leah and Chris (designer of the Elite Pi). Using a vendor-specific name would, in my opinion, be disingenuous.
Rather than flood this PR with discussion, I would suggest raising that concern on the Discord where the standard was originated/designed. (I can hop on to it to help veto anything ahead of PR time if it helps.)
Rather than flood this PR with discussion, I would suggest raising that concern on the Discord where the standard was originated/designed.
Good point. We did exactly that and will come up with a mutually agreed upon name. We’ll get back once the name is final one of these days 😌
TLDR: A vendor-agnostic name is desirable, and care will be taken by vendors to mention the origin of the standard when documenting the converter in vendor documentation. If allowed by QMK, a reference can be placed in the documentation there too.
Moved here: https://github.com/qmk/qmk_firmware/pull/19628