Is it time for a "Blue Pill" Board Entry?

So based on the POLL I took a while back, the Blue Pill board is the most popular stm32f103c generic board we have. Sadly, fellow Blue Pill fans have to begrudgingly select the “Generic STM32F103C series” in the Arduino IDE. Isn’t it time we create a dedicated “Blue Pill” entry in boards.txt?

Rick,

There has been some chat on the github repo about setting LED_BUILTIN on the generic F103C variant to PC13 so it matches the BluePill, and I think we may as well do that.

But I am not sure about naming the variant as BluePill, as I would then need a variant for the original BlackPill which I think has the LED on a different pin.

But the Robot Dyn , black board is the same as the BluePill

The RedPill is the same as the BluePill

And, there may be others I omitted.

An alternative that I have not tried, is supposedly there is a way to make a Boards Manager package that just adds the data that goes in boards.txt and uses the existing variants folder.
I dont know how to create this file – though I think people have posted links to other AVR boards who have done this.

One potential problem is that my repo is not installed via the boards manager, so this may not work at all.

I am never going to have time to manage a boards manager package, and personally I don’t like the way the IDE hides the cores in an obscure location when installed via the Boards Manager.

I’m just throwing the idea out there to see what other people think about this.

I think there should be acknowledgement that the blue pill is pretty common. If the black pill becomes popular maybe it would deserve its own entry. Right now, the blue pill is king until someone tells me it isn’t. I’m not suggesting we get rid of the generic stm32f103c entry. That should still be there for people who don’t have a blue pill and it wouldn’t be any different for them than what we have today. I’m just suggesting we promote the blue pill from its generic status to “King” status.

I think it is unfair that the Maple gets 2 entries (Rev3/ RET6) and the STM32F103RB NUCLEO gets any mention at all.

FWIW: You can’t buy a red pill and I would think people who have them know they are exactly like a blue pill.

[Rick Kimball – Tue Nov 07, 2017 8:44 pm] –
…

FWIW: You can’t buy a red pill and I would think people who have them know they are exactly like a blue pill.

I thought someone posted that RedPills were still available in China, but perhaps I miss understood

Re: Entry for Blue Pill.

My slight concern is the size of boards.txt as the menus have to be duplicated for each entry.

Shame there isn’t a better modular way to do this.

Re: Multiple entry for Maple’s
Yes. we could drop one of them, I don’t know anyone with the Maple RET board

Maybe one could write a python script that takes a boards.txt.template file and inserts all the duplicate items to automatically generate boards.txt? Then it would be easy to add minor variants. One would, of course, want to make up some semantics for the template file. Maybe allow for lines like:
maple.build.ldscript <= mapleMini.build.ldscript

I just had fun and wrote the little preprocessor I described in the previous comment: https://gist.github.com/arpruss/92fe34c … 64c0ca3c09

[RogerClark – Tue Nov 07, 2017 8:22 pm] –
I am never going to have time to manage a boards manager package, and personally I don’t like the way the IDE hides the cores in an obscure location when installed via the Boards Manager.

I use a portable version of IDE in Windows, so I have a portable folder. I believe that in installed version the corresponding folder is an Arduino folder under AppData folder. All packages are installed there.
The package seems to be downloaded in /staging/packages and it is not deleted after unpacking. You will find there all the older versions you downloaded (in /staging/libraries you will find all zipped libraries you installed from library manager!).
Then the package is unpacked in the /packages folder. I don’t know if there is a file or a database with packages list.
Anyway form me it is very easy to install manually. I believe that managing a boards manager package is a very low low priority task.

[arpruss – Wed Nov 08, 2017 1:32 am] –
By the way, I am a bit surprised at the popularity of the blue pill over the black pill, given the convenience of not having to fix the USB resistor on the blue pill, and the price only being about 30 cents more (the last black pill I ordered was $1.90). I’m on my third black pill and they’ve all been good quality.

The vast majority of blog post speak only of blue pill, I believe that most people don’t know that better board exists.

[RogerClark – Tue Nov 07, 2017 8:22 pm] –
An alternative that I have not tried, is supposedly there is a way to make a Boards Manager package that just adds the data that goes in boards.txt and uses the existing variants folder. I dont know how to create this file – though I think people have posted links to other AVR boards who have done this.

I had checked out your github directory into $(HOME)/Arduino/hardware/stm32duino. To add a board without creating a new variant sub directory you just point the board to build.variant=generic_stm32f103c and build.board=GENERIC_STM32F103C.

I put together a boards.txt entry for my bluepill which I use with a Black Magic Probe:
################################################################################
# — blue pill configured for 128k/72MHz/BMP uploading

bluepill.name=Blue Pill (128k / BMP upload)

bluepill.build.board=GENERIC_STM32F103C
bluepill.build.core=maple
bluepill.build.cpu_flags=-DMCU_STM32F103CB
bluepill.build.f_cpu=72000000L
bluepill.build.flags.ldspecs=
bluepill.build.flags.optimize=-Os
bluepill.build.ldscript=ld/jtag.ld
bluepill.build.upload_flags=-DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG
bluepill.build.variant=generic_stm32f103c
bluepill.build.vect=VECT_TAB_ADDR=0x8000000

bluepill.upload.auto_reset=false
bluepill.upload.file_type=bin
bluepill.upload.maximum_data_size=20480
bluepill.upload.maximum_size=131072
bluepill.upload.protocol=gdb_bmp
bluepill.upload.tool=bmp_upload

Seems to work

Hi Rick

It wouldnt need a variant folder, but it would need a load of lines in boards.txt

e.g.


BluePill.name=Blue Pill
BluePill.vid.0=0x1EAF
BluePill.pid.0=0x0004
BluePill.build.variant=generic_stm32f103c
BluePill.build.vect=VECT_TAB_ADDR=0x8000000
BluePill.build.core=maple
BluePill.build.board=GENERIC_STM32F103C
BluePill.upload.use_1200bps_touch=false
BluePill.upload.file_type=bin
BluePill.upload.auto_reset=true
BluePill.upload.tool=maple_upload
BluePill.upload.protocol=maple_dfu

## STM32F103C8 -------------------------
BluePill.menu.device_variant.STM32F103C8=Published flash size (20k RAM. 64k Flash)
BluePill.menu.device_variant.STM32F103C8.build.cpu_flags=-DMCU_STM32F103C8
BluePill.menu.device_variant.STM32F103C8.build.ldscript=ld/jtag_c8.ld
BluePill.menu.device_variant.STM32F103C8.upload.maximum_size=65536
BluePill.menu.device_variant.STM32F103C8.upload.maximum_data_size=20480

## STM32F103CB -------------------------
BluePill.menu.device_variant.STM32F103CB=Undocumented flash size (20k RAM. 64k Flash)
BluePill.menu.device_variant.STM32F103CB.build.cpu_flags=-DMCU_STM32F103CB
BluePill.menu.device_variant.STM32F103CB.build.ldscript=ld/jtag.ld
BluePill.menu.device_variant.STM32F103CB.upload.maximum_size=131072
BluePill.menu.device_variant.STM32F103CB.upload.maximum_data_size=20480

#---------------------------- UPLOAD METHODS ---------------------------

BluePill.menu.upload_method.DFUUploadMethod=STM32duino bootloader
BluePill.menu.upload_method.DFUUploadMethod.upload.protocol=maple_dfu
BluePill.menu.upload_method.DFUUploadMethod.upload.tool=maple_upload
BluePill.menu.upload_method.DFUUploadMethod.build.upload_flags=-DSERIAL_USB -DGENERIC_BOOTLOADER
BluePill.menu.upload_method.DFUUploadMethod.build.vect=VECT_TAB_ADDR=0x8002000
BluePill.menu.upload_method.DFUUploadMethod.build.ldscript=ld/bootloader_20.ld
BluePill.menu.upload_method.DFUUploadMethod.upload.usbID=1EAF:0003
BluePill.menu.upload_method.DFUUploadMethod.upload.altID=2

BluePill.menu.upload_method.serialMethod=Serial
BluePill.menu.upload_method.serialMethod.upload.protocol=maple_serial
BluePill.menu.upload_method.serialMethod.upload.tool=serial_upload
BluePill.menu.upload_method.serialMethod.build.upload_flags=-DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG

BluePill.menu.upload_method.STLinkMethod=STLink
BluePill.menu.upload_method.STLinkMethod.upload.protocol=STLink
BluePill.menu.upload_method.STLinkMethod.upload.tool=stlink_upload
BluePill.menu.upload_method.STLinkMethod.build.upload_flags=-DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG=1 -DSERIAL_USB -DGENERIC_BOOTLOADER

BluePill.menu.upload_method.BMPMethod=BMP (Black Magic Probe)
BluePill.menu.upload_method.BMPMethod.upload.protocol=gdb_bmp
BluePill.menu.upload_method.BMPMethod.upload.tool=bmp_upload
BluePill.menu.upload_method.BMPMethod.build.upload_flags=-DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG

BluePill.menu.upload_method.jlinkMethod=JLink
BluePill.menu.upload_method.jlinkMethod.upload.protocol=jlink
BluePill.menu.upload_method.jlinkMethod.upload.tool=jlink_upload
BluePill.menu.upload_method.jlinkMethod.build.upload_flags=-DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG=1 -DSERIAL_USB -DGENERIC_BOOTLOADER

#-- CPU Clock frequency
BluePill.menu.cpu_speed.speed_72mhz=72Mhz (Normal)
BluePill.menu.cpu_speed.speed_72mhz.build.f_cpu=72000000L

BluePill.menu.cpu_speed.speed_48mhz=48Mhz (Slow - with USB)
BluePill.menu.cpu_speed.speed_48mhz.build.f_cpu=48000000L

BluePill.menu.cpu_speed.speed_128mhz=Overclocked 128Mhz NO USB SERIAL. MANUAL RESET NEEDED TO UPLOAD
BluePill.menu.cpu_speed.speed_128mhz.build.f_cpu=128000000L

#-- Optimizations
BluePill.menu.opt.osstd=Smallest (default)
BluePill.menu.opt.osstd.build.flags.optimize=-Os
BluePill.menu.opt.osstd.build.flags.ldspecs=
BluePill.menu.opt.oslto=Smallest Code with LTO
BluePill.menu.opt.oslto.build.flags.optimize=-Os -flto
BluePill.menu.opt.oslto.build.flags.ldspecs=-flto
BluePill.menu.opt.o1std=Fast (-O1)
BluePill.menu.opt.o1std.build.flags.optimize=-O1
BluePill.menu.opt.o1std.build.flags.ldspecs=
BluePill.menu.opt.o1lto=Fast (-O1) with LTO
BluePill.menu.opt.o1lto.build.flags.optimize=-O1 -flto
BluePill.menu.opt.o1lto.build.flags.ldspecs=-flto
BluePill.menu.opt.o2std=Faster (-O2)
BluePill.menu.opt.o2std.build.flags.optimize=-O2
BluePill.menu.opt.o2std.build.flags.ldspecs=
BluePill.menu.opt.o2lto=Faster (-O2) with LTO
BluePill.menu.opt.o2lto.build.flags.optimize=-O2 -flto
BluePill.menu.opt.o2lto.build.flags.ldspecs=-flto
BluePill.menu.opt.o3std=Fastest (-O3)
BluePill.menu.opt.o3std.build.flags.optimize=-O3
BluePill.menu.opt.o3std.build.flags.ldspecs=
BluePill.menu.opt.o3lto=Fastest (-O3) with LTO
BluePill.menu.opt.o3lto.build.flags.optimize=-O3 -flto
BluePill.menu.opt.ogstd=Debug (-g)
BluePill.menu.opt.o3lto.build.flags.ldspecs=-flto
BluePill.menu.opt.ogstd.build.flags.optimize=-Og
BluePill.menu.opt.ogstd.build.flags.ldspecs=

i think ‘blue pill’ board as well as the LED_BUILTIN definition is a good thing
one way is perhaps we can have a ‘led tester’ sketch say placed in some examples / library folder which users could send commands over usb-serial to blink particular pins, that would help them identify their led pin if they are after all different from blue pill
a trouble of course is for a total new beginner loading a new sketch, as if their LED_BUILTIN is on a different pin, the device would seem ‘not working’, but i guess total beginners should perhaps start with MM clones or specific BP which has a fixed pre-defined matching LED_BUILTIN

[RogerClark – Wed Nov 08, 2017 11:26 pm] – It wouldnt need a variant folder, but it would need a load of lines in boards.txt

True, but if we adopted my quick and dirty template.py (I just updated the gist), these lines could be automatically generated from a pretty small number of boards.txt.template lines. E.g., I think the following might be all that’s needed:

BluePill.name=Blue Pill
# copy most stuff from MapleMini
BluePill.* <= MapleMini.*
# but override MapleMini.build.* or MapleMini.upload.* or MapleMini.bootloader_version.*
! BluePill.build.*
! BluePill.upload.*
! BluePill.bootloader_version.*

## STM32F103C8 -------------------------
BluePill.menu.device_variant.STM32F103C8=Published flash size (20k RAM. 64k Flash)
BluePill.menu.device_variant.STM32F103C8.build.cpu_flags=-DMCU_STM32F103C8
BluePill.menu.device_variant.STM32F103C8.build.ldscript=ld/jtag_c8.ld
BluePill.menu.device_variant.STM32F103C8.upload.maximum_size=65536
BluePill.menu.device_variant.STM32F103C8.upload.maximum_data_size=20480

## STM32F103CB -------------------------
BluePill.menu.device_variant.STM32F103CB=Undocumented flash size (20k RAM. 64k Flash)
BluePill.menu.device_variant.STM32F103CB.build.cpu_flags=-DMCU_STM32F103CB
BluePill.menu.device_variant.STM32F103CB.build.ldscript=ld/jtag.ld
BluePill.menu.device_variant.STM32F103CB.upload.maximum_size=131072
BluePill.menu.device_variant.STM32F103CB.upload.maximum_data_size=20480


I just checked and the Generic STM32F103C has a define for LED_BUILTIN as PC13 i.e this is correct for he Blue Pill

I was trying to work out a system where it can be defined in Boards.txt and then passed to platform.txt, but I think I’d need to define the flags for every board in boards.txt, e.g.

if I did this in platform.txt

build.extra_flags= -DLED_BUILTIN={build.led_builtin} {build.upload_flags} {build.cpu_flags} {build.hs_flag} {build.common_flags}

I did this in boards.txt of F4:
generic_f407v.build.extra_flags= -DLED_BUILTIN=PA6

Yes. It could be added to the extraflags or any of the other flags