aboutsummaryrefslogtreecommitdiff
path: root/docs/platformdev_selecting_arm_mcu.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/platformdev_selecting_arm_mcu.md')
-rw-r--r--docs/platformdev_selecting_arm_mcu.md10
1 files changed, 5 insertions, 5 deletions
diff --git a/docs/platformdev_selecting_arm_mcu.md b/docs/platformdev_selecting_arm_mcu.md
index c115aa6e0f..95a88536ec 100644
--- a/docs/platformdev_selecting_arm_mcu.md
+++ b/docs/platformdev_selecting_arm_mcu.md
@@ -1,4 +1,4 @@
-# Choosing an Arm MCU :id=choose-arm-mcu
+# Choosing an Arm MCU {#choose-arm-mcu}
This page outlines the selection criteria to ensure compatibility with Arm/ChibiOS.
@@ -8,7 +8,7 @@ Adding support for new MCU families must go through ChibiOS or ChibiOS-Contrib -
To be clear: this also includes commercial boards -- unless agreed upon by all parties, QMK will not take over maintenance of a bespoke MCU support package. Even if MCU support is upstreamed into ChibiOS/ChibiOS-Contrib, QMK reserves the right to deprecate and/or remove keyboards utilising support packages that aren't kept up to date with upstream ChibiOS itself.
-## Selecting an already-supported MCU :id=selecting-already-supported-mcu
+## Selecting an already-supported MCU {#selecting-already-supported-mcu}
### STM32 families
@@ -43,16 +43,16 @@ ChibiOS does have support for a handful of non-STM32 devices, and the list can b
Do note that there are sometimes licensing restrictions with respect to redistribution. As an example, binaries built for nRF5 are not able to be redistributed via QMK Configurator, due to the licensing of their board support package.
-## Adding support for a new STM32 MCU (for an existing family) :id=add-new-stm32-mcu
+## Adding support for a new STM32 MCU (for an existing family) {#add-new-stm32-mcu}
Usually, one can "masquerade" as an existing MCU of the same family, especially if the only difference is RAM or Flash size. As an example, some MCUs within the same family are virtually identical, with the exception of adding a cryptographic peripheral -- STM32L072 vs. STM32L082 for instance. Given the unlikely use of the cryptographic peripheral, L082 chips can actually run as if they're an L072, and can be targeted accordingly.
Adding proper support for new MCUs within an existing STM32 family should ideally be upstreamed to ChibiOS. In general, this will require modifications of the `stm32_registry.h` file, providing correct responses for the same `#define`s provided for the other MCUs in that family.
-## Adding support for a new STM32 Family :id=add-new-stm32-family
+## Adding support for a new STM32 Family {#add-new-stm32-family}
If this is a requirement, this needs to go through upstream ChibiOS before QMK would consider accepting boards targeting the new family. More information for porting should be sought by approaching ChibiOS directly, rather than through QMK.
-## Adding support for a new MCU Family :id=add-new-mcu-family
+## Adding support for a new MCU Family {#add-new-mcu-family}
As stated earlier, in order for a new MCU family to be supported by QMK, it needs to be upstreamed into ChibiOS-Contrib before QMK will consider accepting boards using it. The same principle applies for development -- you're best approaching the ChibiOS-Contrib maintainers to get a bit more of an idea on what's involved with upstreaming your contribution.