<spanclass="line"><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;">#define</span><spanstyle="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> STM32_HAS_OTG2</span><spanstyle="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> TRUE</span></span></code></pre></div><p>For the most part, this is the bare minimum to be able to have a high confidence that QMK will be able to run on your MCU. After that, it's all up to configuration.</p><h3id="non-stm32-families"tabindex="-1">Non-STM32 families <aclass="header-anchor"href="#non-stm32-families"aria-label="Permalink to "Non-STM32 families""></a></h3><p>ChibiOS does have support for a handful of non-STM32 devices, and the list can be found in QMK's <ahref="https://github.com/qmk/ChibiOS/tree/master/os/hal/ports"target="_blank"rel="noreferrer">ChibiOS fork</a> and <ahref="https://github.com/qmk/ChibiOS-Contrib/tree/master/os/hal/ports"target="_blank"rel="noreferrer">ChibiOS-Contrib fork</a>. Non-STM32 support is likely out of date, and only supports ancient MCUs -- whilst it might be possible to use these, it's not recommended.</p><p>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.</p><h2id="add-new-stm32-mcu"tabindex="-1">Adding support for a new STM32 MCU (for an existing family) <aclass="header-anchor"href="#add-new-stm32-mcu"aria-label="Permalink to "Adding support for a new STM32 MCU (for an existing family) {#add-new-stm32-mcu}""></a></h2><p>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.</p><p>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 <code>stm32_registry.h</code> file, providing correct responses for the same <code>#define</code>s provided for the other MCUs in that family.</p><h2id="add-new-stm32-family"tabindex="-1">Adding support for a new STM32 Family <aclass="header-anchor"href="#add-new-stm32-family"aria-label="Permalink to "Adding support for a new STM32 Family {#add-new-stm32-family}""></a></h2><p>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.</p><h2id="add-new-mcu-family"tabindex="-1">Adding support for a new MCU Family <aclass="header-anchor"href="#add-new-mcu-family"aria-label="Permalink to "Adding support for a new MCU Family {#add-new-mcu-family}""></a></h2><p>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.</p></div></div></main><footerclass="VPDocFooter"data-v-39a288b8data-v-09de1c0f><!--[--><!--]--><!----><navclass="prev-next"data-v-09de1c0f><divclass="pager"data-v-09de1c0f><aclass="VPLink link pager-link prev"href="/api_development_overview"data-v-09de1c0f><!--[--><spanclass="desc"data-v-09de1c0f>Previous page</span><spanclass="title"data-v-09de1c0f>Architecture Overview</span><!--]--></a></div><divclass="pager"data-v-09de1c0f><aclass="VPLink link pager-link next"href="/platformdev_chibios_earlyinit"data-v-09de1c0f><!--[--><spanclas
