@cladmi: I implemented the split of boards as suggested in the email list

Murdock thinks you should update some BOARD_INSUFFICIENT_MEMORY lists.
Looks pretty clean otherwise.

@maribu Thank you, I will look at it :)

@MrKevinWeiss you are a big user of the bluepill I think you may be interested to check

From a first quick look, I think the symlinks could be removed.
It is not a pattern we use that much in RIOT.

The easy ones are:

• INCLUDES += -I$(RIOTBOARD)/bluepill/include for the headers
• export OPENOCD_CONFIG = $(RIOTBOARD)/common/stm32f103c8/dist/openocd.cfg

For board.c, I can think of another hack to still use the bluepill board.
I did one in #12183 for the tests/external_board_native/external_boards/native/Makefile file.
Defining the bluepill-128k/Makefile that it is defining the boards_bluepill_128k module and set DIRS to go in the bluepill.

@MrKevinWeiss you are a big user of the bluepill I think you may be interested to check

Slander and lies!!! 😆

I use bluepills for PHiLIP but not in RIOT. I do, however, have them and would be happy to help test and give an opinion.

@cladmi: I rewrote the whole thing and moved more code to the common module, which I renamed to boards/common/blxxxpill to account for being bluepill/blackpill specific. That way no symlinks or Makefiles hacks should be required. I updated the Makefile.include as you suggested to point to the shared openocd.cfg instead of using a symlink.

Overall I like the idea. I don't think I have a 128KB bluepill but I can look around.

I don't think I have a 128KB bluepill but I can look around.

All but the BluePill I gave you in Helsinki have 128 KiB ;-) They just claim to only have 64 KiB ;-)

With the development version of OpenOCD you'll be able to flash them with firmwares up to 128KiB out of the box. (Hopefully they do a release soon...)

Ahh I thought that was the 32KB one. Perfect! such beautiful LEDs 😆

I take a look at the updated version today.

Tested on the bluepills! I will wait to see if @cladmi has any additional comments on the code design.

Ahh I thought that was the 32KB one. Perfect! such beautiful LEDs 😆

Like the regular bluepills, it only claims to have half of the flash it is actually equipped with. So regular BluePills come with 128KiB, but report 64KiB to the programmer. The beautiful LED BluePill comes with 64 KiB flash, but reports only 32 KiB to the programmer.

This indeed solves the issue I raised on the mailing list with the special CPU_MODEL handling for #11477
I will do a PR that moves the CPU/CPU_MODEL after this one.

The refactoring with the board_common.h like this removed a lot of the previous duplication.

If I understand correctly, the blackpill is the same as the bluepill but with only a different LED0 gpio. Is that correct?

If you want to make it a bit more clear and remove duplication of the value in the blackpill* boards, you could define both values in board_common.h and in the blackpill headers say #define BLACKPILL_LED_MAPPING 1 or something. It would give only one definition and also document what are the default values.
But that is optimization and is not required in this PR.

Building example/default with all 4 boards in this PR give the same size as bluepill and blackpill in master as expected (considering the difference is only a gpio mapping).
The 128kib versions can link examples/gnrc_networking when the bluepill could not.

The handling for openocd with duplication is currently the normal way of doing it in RIOT.
There could be a common file if we were using --search to give the config directory instead of an absolute path to the file as we do now, but it is not the case, so good to duplicate.

The documentation moved to common/blxxxpill now contains information for both boards and has been updated to remove the FLASH_HACK.
The documentation for using the st-flash has been removed, but it is not needed anymore as openocd is now used for flashing the 128KiB directly.

However, I am not sure the common naming works, bluepill does not have the same number of letters as blxxxpill :p (just kidding of course)

Some optional personal preference, I would prefer to default definition with OPENOCD_CONFIG ?= for all the 4 values and include $(RIOTBOARD)/common/blxxxpill/Makefile.include at the end of the file.

It is a minor thing, but reflects a bit more how "common" boards are mainly currently implemented as a list of directories that are evaluated one after the other. And the "common" only sets if it was not overwritten by a main board.

This is nitpicking though, and would currently not change anything.
Ignore if you want :)

This is looking good, as far as I can tell @cladmi comments where addressed and @MrKevinWeiss tested this, any reasons to keep staling?

OK. Then squash, rebase, and update board insufficient memory?

(Updating the board insufficient memory lists will result in merge conflicts with a chance of 99%, as the makefiles are touched often to update just that list)

I think it would be a good idea to add the RAM and ROM size to Makefile.features and then just have the applications say how much they need instead of maintaining those lists.

@benpicco: I'm all in for reducing maintenance effort here. There is already an issue discussing ways to get rid of these pain-in-the-ass lists, but with no conclusion yet.

The problem with with the application-wise RAM/ROM requirements is, that these not only greatly depend on the architecture (e.g. in AVR all const arrays have to be kept in RAM, as it is a Harvard architecture) and even on the board (e.g. number of SPI config structs, board init code, etc.). I think that this might require so fine-grained control, that this might end up being similar effort.

Well then, just go ahead and squash (and update the insufficient memory lists while doing so).
Then we can swiftly merge this before any new conflicts creep in 😉

rebased

squashed

I just tested this with a blackpill-128kib board and it's working fine.

Let's go with this one. I'll open just after the change about the definition of CPU/CPU_MODEL in Makefile.features (was waiting for this).

Thanks everyone for the review and help!