Change to development_board

[dunk2k]

Description

changed keyboard to development_board, where readme.md or public accessible material(s) identify.
Development boards in scope:

• blackpill_f401
• blackpill_f411
• bluepill
• proton_c

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

• n/a

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).

[lesshonor]

Not a good idea to perform this conversion blindly. The very first PCB modified in this submission (Acheron Project Shark, alpha version) cannot use the Proton-C dev board pinout per its schematic.

[dunk2k]

Not a good idea to perform this conversion blindly. The very first PCB modified in this submission (Acheron Project Shark, alpha version) cannot use the Proton-C dev board pinout per its schematic.

appreciate the heads up @lesshonor
On the subject of the acheron/shark/alpha - if it cannot use the Proton-C dev board, then to what purpose is "board": "QMK_PROTON_C" specified in info.json?

[lesshonor]

appreciate the heads up @lesshonor On the subject of the acheron/shark/alpha - if it cannot use the Proton-C dev board, then to what purpose is "board": "QMK_PROTON_C" specified in info.json?

It sets up a bunch of stuff I'll admit I don't fully understand. It seems possible that this is a non-ideal-but-currently-needed value to use for this keyboard, the same way I couldn't get ymdk/id75 to compile without setting board to STM32_F103_STM32DUINO.

[sigprof]

"board": "QMK_PROTON_C" in many STM32F303-based keyboards probably comes from #10976. Before that PR the default ChibiOS configuration for STM32F303 had most peripherals enabled by default; then #10976 introduced the QMK_PROTON_C board, which had most peripherals enabled, and switched the GENERIC_STM32_F303XC board to have all peripherals disabled; however, the same PR also added BOARD = QMK_PROTON_C to all previously existing STM32F303-based keyboards, so that the existing code would continue to work exactly as before. Because of that, there are lots of keyboards which use the Proton C configuration, even though the actual hardware does not use the Proton C controller.

Switching the configuration to "development_board": "proton_c" for boards which don't actually use the Proton C controller still looks wrong (although it won't actually permit nonsensical conversions just yet, because the current converter support cannot handle conversion from Proton C to anything else — only promicro and elite_c controllers are supported as conversion sources).

[dunk2k]

Past history and all, reverting the proton_c development_board change until research denotes which boards are actual proton_c

[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.

[dunk2k]

Bump

[lesshonor]

Conflict resolution aside, I think it would be a good idea to provide supporting evidence for these changes. For example: indicating where you found the information for each keyboard, or perhaps calculating SHAs which indicate the binaries are unchanged from the last commit you end up rebasing on.

The benefit of switching to development_board is currently small compared to the negative impact of getting things wrong. Sharing your research/findings would help others more easily verify their correctness.

[fauxpark]

I went through all of them and they all seemed fine to me.