Adding alternative configs for Piantor and update example

[duncanam]

Description

Here we add an entrypoint for the Weact controller which is an option that Beekeeb ships with their Piantor kits, as well as the required variable to define which vbus pin the vanilla Pico uses vs. the Weact Pico. Additionally, added an example flashing with the Weact config as well as an alternative layout, Miryoku (this was originally puzzling for me, and this would have been helpful).

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• enable Weact for Piantor
• add example
• adding "no vbus sense" for microcontrollers without that mode assembled in the Piantor

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage). (I'm currently typing this using this change)

[duncanam]

@l4u Mind reviewing?

[dunk2k]

In readme.md could you add a paragraph with conditions for when to compile no_vbus_sense?

[duncanam]

Sure thing, good idea.

…

-------- Original Message --------

On Jul 5, 2023, 3:08 AM, Duncan Sutherland wrote: In readme.md could you add a paragraph with conditions for when to compile no_vbus_sense? — Reply to this email directly, [view it on GitHub](#21452 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFNZ22GVT4J7I65WEY2S4XLXOU4KRANCNFSM6AAAAAAZ6D3VOA). You are receiving this because you authored the thread.Message ID: ***@***.***>

[duncanam]

@dunk2k and/or @drashna - what is this repo's policy on squashing commits during PR? Would you like me to add commits with edits then squash at the end, squash as I add, or don't squash at all and leave a full paper trail (albeit messier) upon merge with master?

[drashna]

@dunk2k and/or @drashna - what is this repo's policy on squashing commits during PR? Would you like me to add commits with edits then squash at the end, squash as I add, or don't squash at all and leave a full paper trail (albeit messier) upon merge with master?

We squash when we merge PRs. So the commit history from the PR doesn't really matter.

Though, personally, I prefer that it's not "cleaned up", since it makes it easier to see when and where changes occurred. But that's just my preference.

[duncanam]

TODO for me:

• add no vbus sense example
• update with copyright header

[duncanam]

Build failing on bcat targets here- I may need some guidance on how best to proceed to fix.

[dunk2k]

Build failing on bcat targets here- I may need some guidance on how best to proceed to fix.

Thankfully I've already a PR (#21205) for fixing that.
Regardless, as it's a userspace+community layout, it wouldn't be your remit/responsibility to fix 😉

[duncanam]

@l4u just wanted to also check in with you on this one too

[duncanam]

@drashna Any other suggestions here?

[fauxpark]

This should really be inverted, that way there is no need to undef. And keyboard updates need to go through develop.

[duncanam]

@fauxpark How do we invert such that the default config has that pin defined but the two special configs have variations (either a new pin in the case of the Weact microcontroller, or no pin, for that case)?

[fauxpark]

Probably the easiest would be to split the board into two "revisions" instead of how you've done it here. Then make sure the "base" cannot be built, either by removing the rules.mk or setting DEFAULT_FOLDER to the revision corresponding to the current config.

[duncanam]

@fauxpark Okay let's see if I am understanding this: we can remove the pin definition from the current "base" config and place this into a new folder, "base", with its own rules, and define a new constant DEFAULT_FOLDER in the root definition that points to "base", such that when building the config it will default to "base" if not specified?

[fauxpark]

Basically. You'd have two subfolders named say pico and weact, both with empty rules.mk (to make them build targets), but one also has a config.h with the VBUS pin define. Then you add DEFAULT_FOLDER = beekeeb/piantor/pico to the existing rules.mk.

[duncanam]

Basically. You'd have two subfolders named say pico and weact, both with empty rules.mk (to make them build targets), but one also has a config.h with the VBUS pin define. Then you add DEFAULT_FOLDER = beekeeb/piantor/pico to the existing rules.mk.

Got it- that does seem cleaner.

[lesshonor]

Inclined to agree with fauxpark that the top-level configuration shouldn't have USB_VBUS_PIN defined.
The "reference" Pi Pico pin (GP24) would be configured in a raspi subfolder (...I think this might be a better name than pico, since there are so many different "Pi Pico"s) and the WeAct Pi Pico pin (GP29) would be configured in a weact subfolder—e.g.:

piantor/
├── no_vbus_sense/
│   └── rules.mk
├── raspi/
│   ├── config.h
│   └── rules.mk
├── weact/
│   ├── config.h
│   └── rules.mk
├── README.md
├── config.h
└── rules.mk

(The no_vbus_sense folder wouldn't be necessary if the default build didn't need to assume a pin.)

[lesshonor]

Suggested change

	# This file intentionally left blank

[lesshonor]

Suggested change

	# This file intentionally left blank

[drashna]

Suggested change

	// When USB_VBUS_PIN is not defined, SPLIT_USB_DETECT is used.
	#define USB_VBUS_PIN GP24 // for Raspberry Pi Pico

[drashna]

Suggested change

#undef USB_VBUS_PIN

[duncanam]

Thanks for the feedback, I'll take a look

[github-actions]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[duncanam]

Status update: I am slow

[github-actions]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[duncanam]

Currently verifying some changes on local hardware.

…

-------- Original Message --------

On Feb 2, 2024, 5:46 PM, github-actions[bot] wrote: Thank you for your contribution! This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready. For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged. — Reply to this email directly, [view it on GitHub](#21452 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFNZ22E4TT67FXQR277MOQDYRWJJFAVCNFSM6AAAAAAZ6D3VOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGAYTANRYGM). You are receiving this because you authored the thread.Message ID: ***@***.***>

[github-actions]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[github-actions]

Thank you for your contribution!
This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready.
// [stale-action-closed]