Add minimal STM32F103C6 support #17853
Conversation
Unfortunately, the crippled versions of “Bluepill” boards with STM32F103C6xx chips instead of STM32F103C8xx are now sold all over the place, sometimes advertised in a confusing way to make the difference not noticeable until too late. Add minimal support for these MCUs in the common “Bluepill with stm32duino” configuration, so that it could be possible to make something useful from those boards (although fitting QMK into the available 24 KiB of flash may be rather hard). (In fact, I'm not sure whether the “STM32” part of the chip name is actually correct for those boards of uncertain origin, so the onekey board name is `bluepill_f103c6`; another reason for that name is to match the existing `blackpill_f401` and `blackpill_f411`.) The EEPROM emulation support is not included on purpose, because enabling it without having a working firmware size check would be irresponsible with such flash size (the chance that someone would build a firmware where the EEPROM backing store ends up overlapping some firmware code is really high). Other than that, enabling the EEPROM emulation code is mostly trivial (the `wear_leveling` driver with the `embedded_flash` backing store even works without any custom configuration, although its code is significantly larger than the `vendor` driver, which may also be important for such flash size).
|
@sigprof This works as expected. But since there's no EEPRom emulation, it doesn't support VIA either. Is there a way to turn this on? I have an ST-Link on hand so I could give it a try without worrying about bricking. |
|
You can enable EEPROM in EEPROM_DRIVER = vendorand add this configuration to #define FEE_MCU_FLASH_SIZE 32
#define FEE_PAGE_COUNT 2
#define FEE_PAGE_SIZE 1024(Although that The major issue is that you effectively decrease the available flash size by 2K, but the build system does not know about that, so you would be able to build a firmware that extends into the EEPROM data area without noticing that. |
|
@sigprof It works! Though I have to carefully calculate how many bytes each feature takes, and turn off some heavy ones, e.g. RGB matrix. VIA support is the heaviest among them. |
|
Where is the use of FEE_PAGE_COUNT and FEE_PAGE_SIZE mentioned? I am confused, is it the default that everyone who adjusts eeprom needs to understand the knowledge in chibios? |
|
It's not mentioned, it's usually best left alone as it can have unintended consequences. Here be dragons. |
C6T6 is very limited, you can't do much with only 24K flash. C8 and above would be better. |
Unfortunately, the crippled versions of “Bluepill” boards with STM32F103C6xx chips instead of STM32F103C8xx are now sold all over the place, sometimes advertised in a confusing way to make the difference not noticeable until too late. Add minimal support for these MCUs in the common “Bluepill with stm32duino” configuration, so that it could be possible to make something useful from those boards (although fitting QMK into the available 24 KiB of flash may be rather hard). (In fact, I'm not sure whether the “STM32” part of the chip name is actually correct for those boards of uncertain origin, so the onekey board name is `bluepill_f103c6`; another reason for that name is to match the existing `blackpill_f401` and `blackpill_f411`.) The EEPROM emulation support is not included on purpose, because enabling it without having a working firmware size check would be irresponsible with such flash size (the chance that someone would build a firmware where the EEPROM backing store ends up overlapping some firmware code is really high). Other than that, enabling the EEPROM emulation code is mostly trivial (the `wear_leveling` driver with the `embedded_flash` backing store even works without any custom configuration, although its code is significantly larger than the `vendor` driver, which may also be important for such flash size).
Description
Unfortunately, the crippled versions of “Bluepill” boards with STM32F103C6xx chips instead of STM32F103C8xx are now sold all over the place, sometimes advertised in a confusing way to make the difference not noticeable until too late. Add minimal support for these MCUs in the common “Bluepill with stm32duino” configuration, so that it could be possible to make something useful from those boards (although fitting QMK into the available 24 KiB of flash may be rather hard).
(In fact, I'm not sure whether the “STM32” part of the chip name is actually correct for those boards of uncertain origin, so the onekey board name is
bluepill_f103c6; another reason for that name is to match the existingblackpill_f401andblackpill_f411.)The EEPROM emulation support is not included on purpose, because enabling it without having a working firmware size check would be irresponsible with such flash size (the chance that someone would build a firmware where the EEPROM backing store ends up overlapping some firmware code is really high). Other than that, enabling the EEPROM emulation code is mostly trivial (the
wear_levelingdriver with theembedded_flashbacking store even works without any custom configuration, although its code is significantly larger than thevendordriver, which may also be important for such flash size).Tested onekey keymaps:
defaultadc(needs changes inhalconf.handmcuconf.hto enable ADC)backlightconsoledigitizer(seems to send some events visible insudo evtest)eep_rst(withEEPROM_DRIVER=transientthis just restarts the firmware)hardware_idoled(needs changes inhalconf.handmcuconf.hto enable I2C)quinereboot(works appropriately with stm32duino — the bootloader does not appear during the reboot)reset(works appropriately with stm32duino — the bootloader starts with the 8s timeout disabled)rgbrgb_matrix(needs-e RGB_MATRIX_DRIVER=WS2812 -e CONSOLE_ENABLE=no)Types of Changes
Issues Fixed or Closed by This PR
Checklist