[Controller] Added board config for custom controller STeMCell #16287

megamind4089 · 2022-02-09T17:55:30Z

Description

This PR adds support for the open source controller STeMCell based on STM32F411 mcu, designed by myself.
STeMCell

Tested the controller with ADux, Lily58 and Swoop keyboard

Types of Changes

Issues Fixed or Closed by This PR

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

quantum/matrix.c

filterpaper · 2022-03-04T01:00:57Z

@megamind4089 Can you rebase against the latest breaking change to resolve the conflicts?

megamind4089 · 2022-03-08T11:31:28Z

@filterpaper Done. Rebased against the develop branch

filterpaper

Tested and confirmed that these changes work correctly on the current develop branch with STeMCell hardware version 1.0.1.

tzarc

Do the board definitions need a copy of their own board.(c|h) files? Can they piggyback off existing ones in ChibiOS?

Ideally we should be attempting to leverage as much existing stuff in ChibiOS as possible, providing overrides -- this ensures we've got version independence and allows simpler upgrades for new hardware support. I've got a strong preference to removing these and overriding if we can possibly do so.

builddefs/build_keyboard.mk

platforms/chibios/boards/STEMCELL/configs/config.h

platforms/chibios/boards/STEMCELL/configs/halconf.h

tzarc · 2022-03-09T02:22:00Z

platforms/chibios/boards/STEMCELL/configs/mcuconf.h

+#define STM32_PLLM_VALUE 8
+#define STM32_PLLN_VALUE 336
+#define STM32_PLLP_VALUE 4
+#define STM32_PLLQ_VALUE 7
+#define STM32_HPRE STM32_HPRE_DIV1
+#define STM32_PPRE1 STM32_PPRE1_DIV4
+#define STM32_PPRE2 STM32_PPRE2_DIV2


These result in a 21MHz APB1 clock and a 42MHz APB2 clock.

Unsure if there was a specific rationale for this, but for max speed what about:

Suggested change

#define STM32_PLLM_VALUE 8

#define STM32_PLLN_VALUE 336

#define STM32_PLLP_VALUE 4

#define STM32_PLLQ_VALUE 7

#define STM32_HPRE STM32_HPRE_DIV1

#define STM32_PPRE1 STM32_PPRE1_DIV4

#define STM32_PPRE2 STM32_PPRE2_DIV2

#define STM32_PLLM_VALUE 4

#define STM32_PLLN_VALUE 96

#define STM32_PLLP_VALUE 2

#define STM32_PLLQ_VALUE 4

#define STM32_HPRE STM32_HPRE_DIV1

#define STM32_PPRE1 STM32_PPRE1_DIV2

#define STM32_PPRE2 STM32_PPRE2_DIV1

This gets APB1 to 48MHz and APB2 to 96MHz.

I have reverted the old clock settings to make sure firmware runs in both F401 and F411 chips since f411 is unobtanium now

tzarc · 2022-03-09T02:23:42Z

platforms/chibios/boards/STEMCELL/ld/STEMCELL_tinyuf2.ld

+MEMORY
+{
+ flash0 (rx) : org = 0x08000000, len = 32k /* Sector 0,1 - TinyUF2 bootloader */
+ flash1 (rx) : org = 0x08008000, len = 32k /* Sector 2,3 - Emulated eeprom */


Unfortunately the way the emulated EEPROM is written, it's going to be situated at the 16kB boundary instead of 32kB.
This makes it difficult to support tinyuf2, given that the bootloader binary is 14kB already and doesn't leave us with a lot of wiggle room.

Pardon me, I did not understand this clearly.

tinyuf2 binary size is around 28 Kb and tinyuf2 linker file uses 32kb (first two sectors)
https://github.com/adafruit/tinyuf2/blob/master/ports/stm32f4/linker/stm32f4.ld#L47

I tried to use the next two sectors of each 16KB for EEPROM.
So I defined the EEPROM_BASE_ADDRESS here appropriately:
https://github.com/qmk/qmk_firmware/pull/16287/files#diff-acf2e3a1560d0c323e6c1fce4f5625c68242220a6968c69f175e1df985d1b03eR106

So actual qmk code start from Sector 4(5th sector). Do you foresee any issues with this memory arrangement ?

As I stated, the way that the code is written is that it's hard-coded to use the 2nd 16k page:

qmk_firmware/platforms/chibios/eeprom_stm32_defs.h

Lines 64 to 66 in edd1f33

# ifndef FEE_PAGE_BASE_ADDRESS

# define FEE_PAGE_BASE_ADDRESS 0x08004000 // bodge to force 2nd 16k page

# endif

Defining the location in only the ldscript will not change the implementation using the second page.

The above code uses the hard coded value, only if users does not define their own FEE_PAGE_BASE_ADDRESS
And i defined the FEE_PAGE_BASE_ADDRESS manually here
https://github.com/qmk/qmk_firmware/pull/16287/files#diff-acf2e3a1560d0c323e6c1fce4f5625c68242220a6968c69f175e1df985d1b03eR106

Is it not sufficient? I have tested the EEPROM config with via and rgb and did not see any issues with it.

BTW, #16586 also attempts to enable EEPROM emulation together with tinyuf2; maybe the default value of FEE_PAGE_BASE_ADDRESS should depend on the bootloader. Changing FEE_PAGE_BASE_ADDRESS for the default case (DFU bootloader in system memory) is probably not desired, because it wastes some flash and increases the apparent firmware size (QMK does not use the DfuSe format extensions which would allow the firmware to be sparse, therefore the whole area reserved for EEPROM and whatever else would need to be flashed together with the rest of the firmware).

I have removed the hard coded FEE_PAGE_BASE_ADDRESS and moved it to use WEAR_LEVELING_DRIVER with legacy backend.

platforms/chibios/pin_defs.h

tzarc · 2022-03-09T02:25:56Z

platforms/chibios/boards/STEMCELL/convert_to_stemcell.mk

+BOARD := STEMCELL
+BOOTLOADER := tinyuf2
+OPT_DEFS += -DCONVERT_TO_STEMCELL
+MCU_LDSCRIPT := STEMCELL_tinyuf2


Should it always require tinyuf2? Are they coming with it preloaded? Do people need to flash it as a bootloader first?
Given that DFU isn't problematic for F4xx, should the default still be DFU, with UF2 as an option?

Yes, STeMCell does not have fancy circuit for reset/bootloader logic.
The reset pinout is directly connected to STM32 NRST pin and Boot0 pin is connected to onboard switch.

With this setup, the normal reset button in keyboard, can only reset. To go to DFU, one has to click Boot0 and then reset button.
Since most of the keyboards will have controllers face down or have OLEDs on top, will be inconvenient to use STM32 inbuilt DFU
TinyUF2 as default, will remove this nuisance and regular user can still single click for reset and double click for bootloader just like promicro

STeMCell after PCBA does not have tiny-uf2 bootloader, We need to load the tinyuf2 bootloader from below using STM32 DFU bootloader.
https://github.com/megamind4089/STeMCell/tree/main/bootloader

megamind4089 · 2022-03-09T06:19:39Z

builddefs/common_features.mk

@@ -183,7 +183,7 @@ else
 ifeq ($(PLATFORM),AVR)
 # Automatically provided by avr-libc, nothing required
 else ifeq ($(PLATFORM),CHIBIOS)
- ifneq ($(filter STM32F3xx_% STM32F1xx_% %_STM32F401xC %_STM32F401xE %_STM32F405xG %_STM32F411xE %_STM32F072xB %_STM32F042x6 %_GD32VF103xB %_GD32VF103x8, $(MCU_SERIES)_$(MCU_LDSCRIPT)),)
+ ifneq ($(filter STM32F3xx_% STM32F1xx_% STM32F4xx_% %_STM32F401xC %_STM32F401xE %_STM32F405xG %_STM32F411xE %_STM32F072xB %_STM32F042x6 %_GD32VF103xB %_GD32VF103x8, $(MCU_SERIES)_$(MCU_LDSCRIPT)),)


I missed this changes with my last rebase.

Also i find see other checks for mcus below as redundant, since all of these mcus define MCU_SERIES as STM32F4xx
_STM32F401xC %_STM32F401xE %_STM32F405xG %_STM32F411xE

Shall i change remove the above checks and keep only STM32F4xx_% ?
Or should i use my ld script value to enable EEPROM_DRIVER

I may be missing something here. Please advise

megamind4089 · 2022-03-09T15:38:21Z

Do the board definitions need a copy of their own board.(c|h) files? Can they piggyback off existing ones in ChibiOS?

Initially i tried to use the same board config files as black pill which is
BOARDSRC = $(CHIBIOS)/os/hal/boards/ST_STM32F401C_DISCOVERY/board.c

But I faced an issue when using existing boards board.c/h files, which sigprof helped me to resolve.
STeMCell use pins B6 and B7 as I2C SCL and SDA, but ST_STM32F401C_DISCOVERY board files define B9 as SDA pin.

https://github.com/qmk/ChibiOS/blob/master/os/hal/boards/ST_STM32F401C_DISCOVERY/board.h#L91

Due to this, I2C was not working, since there are two pins mapped to same I2Cs SDA.

The board.c/h are tweaked for the particular discovery board and its not a generic one.
IMHO, each custom board should have separate board files, specific to the board setup.

tzarc · 2022-03-09T21:16:19Z

each custom board should have separate board files, specific to the board setup

Whilst that would be fine in a world where there's infinite resources to maintain software, the simplest solution is to not have the code in QMK in the first place.

The intent behind the removal of board files is to gain version-independence from ChibiOS. This is why keyboards have configuration override includes rather than full config includes, and why there's a very strong preference to using the board definitions already maintained as part of ChibiOS itself.

Before any of the above refactoring there were more than 650 board definition and configuration files that needed modifications in order to upgrade ChibiOS -- now we're down to fewer than 30. If we'd ignored the refactoring, we'd probably still be stuck with ChibiOS 17.x, and any potential upgrade would now require modifications of well in excess of 1200 files.

So yeah, from a maintenance perspective, there's a very strong preference to leveraging the upstream-maintained copies.

megamind4089 · 2022-03-10T00:00:39Z

@tzarc Yes, I understand the concern now and I agree with that.
Does it makes sense to create a one generic board files inside QMK and make all other boards derived from it ?
Generic board files will declare all pins as input pins, which should avoid the above problem i mentioned.

0xcharly · 2022-04-04T03:35:15Z

Tested and confirmed that it works correctly with the 1.0.1 STeMCell. Currently running on my main build. Thanks, @megamind4089 !

The PR does need to be updated after the recent changes pertaining to pin_defs.h, IIUC.

Deemen17 · 2022-05-31T03:11:17Z

Confirmed STeMCell v1.0.1 worked with reviung41, crkbd. Thank you, @megamind4089!

github-actions · 2022-07-16T02:17:07Z

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.

sadekbaroudi · 2022-07-17T20:04:04Z

I have a lot of people who are using the stemcell on fingerpunch keyboards at this point, so I'm very interested in what it would take to get this into develop at this point.

I am by no means a QMK expert, but if there is anything I can do to help, I'd be more than happy to.

keyboard-magpie · 2022-07-20T17:53:27Z

A similar daughterboard, the bonsai-c4, has just had a converter merged into develop; #17711

sadekbaroudi · 2022-08-07T19:06:16Z

Tested on a couple of fingerpunch boards (Faux Fox Keyboard, Rock On). No issues after using for a couple of hours.

keyboard-magpie

Have also been testing this on my stemcell board, no issues.

filterpaper · 2022-08-07T23:29:53Z

Test and confirmed OLED and RGB functionality on CRKBD.

platforms/chibios/converters/promicro_to_stemcell/converter.mk

platforms/chibios/converters/promicro_to_stemcell/_pin_defs.h

platforms/chibios/boards/STEMCELL/configs/chconf.h

zvecr · 2022-08-08T03:09:28Z

docs/feature_converters.md

+The default version selected is v1.0.1. To compile for v1.0.0, use the following flag while compiling.
+
+```make
+-e STMC_VERSION=1


Not a fan of these compile time flags, feels a lot like the previous CTPC short hand which was removed. (Though im not sure right now on how best to handle the case)

I also have some concerns on versioning being implemented as defines, but thats going to take some time to increment within the current framework.

Do you have any suggestion on how to improve this ?
Or shall I remove the old version to support only current version for now ?

Looks like the pin swap was to better accommodate SPI pinout, correct? Normally when an external interface changes in an incompatible way (like for a pin swap) you would increment the major version number (e.g. 1.0.0 -> 2.0.0) to signify that backwards compatibility is broken.

Since that isn't what happened here, I would lean towards supporting only the current version in the QMK official repo, yet also providing a separate branch in your QMK fork to support anyone using the older version of the board. As it currently stands, anyone using the old version board has already had to make do without the converter being in the QMK repo, so basically, nothing much would change for them: they can just keep on using a branch in your fork that is dedicated to the older version.

Yep, make sense, Also I guess most people have 1.0.1/1.0.2 version.
So i will remove the code supporting older version 1.0.0

We'll have to think up a solution w.r.t. the compile-time flags... but for now it shouldn't hold this PR up.

platforms/chibios/converters/promicro_to_stemcell/_pin_defs.h

…mper settings

drashna · 2022-08-14T01:05:48Z

Has some merge conflicts.

megamind4089 · 2022-08-14T02:58:46Z

Has some merge conflicts.

Thanks @drashna Fixed it.

…6287) Co-authored-by: Mariappan Ramasamy <[email protected]> Co-authored-by: Mariappan Ramasamy <[email protected]> Co-authored-by: Sadek Baroudi <[email protected]>

github-actions bot added core keymap via Adds via keymap and/or updates keyboard for via support labels Feb 9, 2022

megamind4089 changed the title ~~[Controller] Added board config for custom controller using STM32F4 chip~~ [Controller] Added board config for custom controller STeMCell Feb 9, 2022

megamind4089 commented Feb 10, 2022

View reviewed changes

quantum/matrix.c Outdated Show resolved Hide resolved

zvecr mentioned this pull request Feb 10, 2022

Various fixes for matrix _RIGHT handling #16292

Merged

14 tasks

zvecr changed the base branch from master to develop February 12, 2022 13:04

github-actions bot added dependencies and removed dependencies labels Mar 8, 2022

drashna approved these changes Mar 8, 2022

View reviewed changes

filterpaper approved these changes Mar 9, 2022

View reviewed changes

tzarc requested changes Mar 9, 2022

View reviewed changes

megamind4089 commented Mar 9, 2022

View reviewed changes

github-actions bot removed via Adds via keymap and/or updates keyboard for via support keymap labels Mar 9, 2022

megamind4089 requested a review from tzarc March 9, 2022 15:22

sigprof mentioned this pull request Mar 13, 2022

[BUG] Fix tinyuF2 BootLoader make error when emulating EEPROM #16586

Closed

14 tasks

github-actions bot added the stale Issues or pull requests that have become inactive without resolution. label Jul 16, 2022

drashna self-requested a review July 16, 2022 19:25

github-actions bot removed the stale Issues or pull requests that have become inactive without resolution. label Jul 18, 2022

megamind4089 and others added 9 commits August 4, 2022 03:01

Remove now unwanted files

85cd819

use existing board config files from chibios

77ffaa1

Move flash definitions out of pin defs

8e3b39b

Use newer wearleveling driver for EEPROM emulation

0ad07cc

minor refactor

77668f8

Add better defaults and update readme about stemcell converter

92dd21a

update readme

c8c2efa

Fix lint error

9c0d4f9

missing elite-c pins for stemcell (#1)

fd371ae

drashna requested a review from a team August 7, 2022 21:21

keyboard-magpie approved these changes Aug 7, 2022

View reviewed changes

megamind4089 requested review from zvecr and sigprof August 8, 2022 03:12

zvecr requested changes Aug 8, 2022

View reviewed changes

megamind4089 added 2 commits August 8, 2022 11:22

Address comments

d30a976

Move I2C pin defns to configs.h

84bba9c

megamind4089 requested a review from zvecr August 8, 2022 05:06

megamind4089 added 3 commits August 8, 2022 15:47

Remove version support

9bc9b3d

Update license header based on PR checklist

76d0017

Adjusted clock to support F401 chips

f7e8b5c

sadekbaroudi reviewed Aug 11, 2022

View reviewed changes

platforms/chibios/converters/promicro_to_stemcell/_pin_defs.h Show resolved Hide resolved

Revert back the default UART changes, which does not align with HW ju…

5764797

…mper settings

Merge branch 'develop' into stemcell

edc7d40

tzarc approved these changes Aug 14, 2022

View reviewed changes

tzarc merged commit fce99f3 into qmk:develop Aug 14, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Controller] Added board config for custom controller STeMCell #16287

[Controller] Added board config for custom controller STeMCell #16287

megamind4089 commented Feb 9, 2022 •

edited

Loading

filterpaper commented Mar 4, 2022

megamind4089 commented Mar 8, 2022

filterpaper left a comment

tzarc left a comment

tzarc Mar 9, 2022

megamind4089 Aug 11, 2022

tzarc Mar 9, 2022

megamind4089 Mar 9, 2022

tzarc Mar 9, 2022

megamind4089 Mar 10, 2022

sigprof Mar 13, 2022

megamind4089 Aug 8, 2022

tzarc Mar 9, 2022

megamind4089 Mar 9, 2022

megamind4089 Mar 9, 2022

megamind4089 commented Mar 9, 2022

tzarc commented Mar 9, 2022

megamind4089 commented Mar 10, 2022

0xcharly commented Apr 4, 2022 •

edited

Loading

Deemen17 commented May 31, 2022

github-actions bot commented Jul 16, 2022

sadekbaroudi commented Jul 17, 2022

keyboard-magpie commented Jul 20, 2022

sadekbaroudi commented Aug 7, 2022

keyboard-magpie left a comment

filterpaper commented Aug 7, 2022

zvecr Aug 8, 2022

megamind4089 Aug 8, 2022

infinityis Aug 8, 2022

megamind4089 Aug 8, 2022

tzarc Aug 14, 2022

drashna commented Aug 14, 2022

megamind4089 commented Aug 14, 2022

	# ifndef FEE_PAGE_BASE_ADDRESS
	# define FEE_PAGE_BASE_ADDRESS 0x08004000 // bodge to force 2nd 16k page
	# endif

[Controller] Added board config for custom controller STeMCell #16287

[Controller] Added board config for custom controller STeMCell #16287

Conversation

megamind4089 commented Feb 9, 2022 • edited Loading

Description

Types of Changes

Issues Fixed or Closed by This PR

Checklist

filterpaper commented Mar 4, 2022

megamind4089 commented Mar 8, 2022

filterpaper left a comment

Choose a reason for hiding this comment

tzarc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

megamind4089 commented Mar 9, 2022

tzarc commented Mar 9, 2022

megamind4089 commented Mar 10, 2022

0xcharly commented Apr 4, 2022 • edited Loading

Deemen17 commented May 31, 2022

github-actions bot commented Jul 16, 2022

sadekbaroudi commented Jul 17, 2022

keyboard-magpie commented Jul 20, 2022

sadekbaroudi commented Aug 7, 2022

keyboard-magpie left a comment

Choose a reason for hiding this comment

filterpaper commented Aug 7, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

drashna commented Aug 14, 2022

megamind4089 commented Aug 14, 2022

megamind4089 commented Feb 9, 2022 •

edited

Loading

0xcharly commented Apr 4, 2022 •

edited

Loading