March 15, 2025

Black Pill boards - F411 USB -- names and history

I am working with this USB code that I got from someplace. It is marked with ST micro copyrights. As I remember, I got it from the Arduino_STM32 project.

I used the "locate" command on one of the files I work on and found other copies that I have on my system: 

/u1/Projects/STM32/F429/libs_stm32f429/00-STM32F429_LIBRARIES/usb_cdc_device/usbd_cdc_vcp.c
/u1/Projects/STM32/Arduino_STM32/STM32F4/cores/maple/libmaple/usbF4/VCP/usbd_cdc_vcp.c
/u1/Projects/USB/usbF4/vcp/usbd_cdc_vcp.c
/u1/Projects/STM32/Hydra/usbF4/vcp/usbd_cdc_vcp.c
So, there we have it. 3 other copies, and the second to last is another copy I made in what looks like and abandoned project in my USB directory. Looking at it, I see dates on the files from December of 2020 and it is just an old copy of what I now call usbF4 inside my Hydra project. It probably should just be deleted.

I want to comment on filenames themselves. Consider filenames like usb_core.c and usbd_core.c, as well as usbh_core.c. Clearly in someone's scheme the first letters of the filename were intended to convey information, and perhaps avoid name collisions if files were looked at by themselves or mistakenly copied into the same directory. I would not do things this way. I could call these all "core.c" and let them be distinguished by the directory they are found in. The file usb_core.c would be driver/core.c. The files usbd_core.c would be library/core.c and usbh_core.c would be host/core.c.

To my way of thinking, short names are quicker and easier to type, and why duplicate information that is conveyed already by what directory they are found in. On my system I can type "locate init.c" and get well over 100 files in various projects and directories.

Maple

This is just a side note, though both relevant and interesting. "Maple" was one of the first STM32 boards, designed by Leaf labs. They use the F103 chip and were a lot like one of the current "blue pills" but much more nicely done. You will see mention of Maple and libmaple in what follows. There is a maple code base and I did a lot of work with it. It has a usb subsystem that looks like some very ancient (and not very nice) code from ST.
Here is my page on these boards:

/u1/Projects/STM32/Arduino_STM32/STM32F4/cores/maple/libmaple/usbF4/VCP/usbd_cdc_vcp.c

The Arduino_STM32 directory dates from September 2020 and is clearly a clone of that project. "maple" is the only core under core. "libmaple" includes a lot of drivers for all kinds of stm32F4 hardware. A directory "usbF4" holds all the USB code.

Some imbecile decided that it was smart (but it wasn't) to separate .h files into "inc" directories and .c files into "src" directories. This is just a stupid annoyance and it is annoying enough (as well as stupid and pointless) that I don't hesitate to complain about it.

Under Arduino_STM32/STM32F4/cores/maple/libmaple/usbF4/Library/Class I find several directories and get excited: audio cdc dfu hid msc.
However, the only one of these with a "src" directory is "cdc" -- the others have only "inc" directories. The "cdc" directory has 3 files, and we recognize these: 

inc/usbd_cdc_core.h
inc/usbd_cdc_if_template.h
src/usbd_cdc_core.c
In our case, I moved these into our "library" directory.

Doing a "locate" on usbd_cdc_core.h yields some other potential sources of source files for study: 

/u1/Projects/Photon/firmware-0.5.3-rc.1/platform/MCU/STM32F2xx/STM32_USB_Device_Driver/inc/usbd_cdc_core.h
/u1/Projects/STM32/Arduino_STM32/STM32F4/cores/maple/libmaple/usbF4/STM32_USB_Device_Library/Class/cdc/inc/usbd_cdc_core.h
/u1/Projects/STM32/F429/Demo/STM32F429I-Discovery_FW_V1.0.3/Libraries/STM32_USB_Device_Library/Class/cdc/inc/usbd_cdc_core.h
/u1/Projects/STM32/F429/libs_stm32f429/00-STM32F429_LIBRARIES/usb_cdc_device/usbd_cdc_core.h

/u1/Projects/STM32/Arduino_STM32/STM32F4/cores/maple/libmaple/usbF4/STM32_USB_Device_Library/Class/cdc/inc/usbd_cdc_core.h

This is just another path (via a symbolic link) into what we already just looked at.

/u1/Projects/STM32/F429/libs_stm32f429/00-STM32F429_LIBRARIES/usb_cdc_device/usbd_cdc_vcp.c

/u1/Projects/STM32/F429/libs_stm32f429/00-STM32F429_LIBRARIES/usb_cdc_device/usbd_cdc_core.h

This is a clone of: There is a huge amount of code here, and USB code is only a small part of it. There is both device and host mode USB code for the F429, and also something I hoped to find, namely an HID device driver under: 
/u1/Projects/STM32/F429/libs_stm32f429/00-STM32F429_LIBRARIES/usb_hid_device
This will be worth taking a look at someday. I will note in passing that this fellow is intelligent and does not continue the stupid business of inc and src directories.

/u1/Projects/STM32/F429/Demo/STM32F429I-Discovery_FW_V1.0.3/Libraries/STM32_USB_Device_Library/Class/cdc/inc/usbd_cdc_core.h

Dates on these files are March, 2021. These look like files distributed by ST. In the "Libraries" directory, we find: 
CMSIS
STemWinLibrary522_4x9i
STM32F4xx_StdPeriph_Driver
STM32_USB_Device_Library
STM32_USB_HOST_Library
STM32_USB_OTG_Driver
So we have both host and device code, as well as a driver, alongside of code and drivers for things other than USB. We do have the brain damage with inc and src directories here, so that originated at ST. Inside STM32_USB_Device_Library we have Core and Class. Here "Core" looks exactly like what I have called "library", but Class is quite interesting. Unlike what we found in Arduino_STM32, we have "audio cdc dfu hid msc" and each of these has both src and inc directories with files.
For example under "audio", I see: 
inc/usbd_audio_core.h
inc/usbd_audio_out_if.h
src/usbd_audio_core.c
src/usbd_audio_out_if.c
Under "hid", I see: 
inc/usbd_hid_core.h
src/usbd_hid_core.c
Under "msc", I see: 
inc/usbd_msc_bot.h
inc/usbd_msc_core.h
inc/usbd_msc_data.h
inc/usbd_msc_mem.h
inc/usbd_msc_scsi.h

src/usbd_msc_bot.c
src/usbd_msc_core.c
src/usbd_msc_data.c
src/usbd_msc_scsi.c
src/usbd_storage_template.c
So, I have finally found classes for things other than cdc. Where are VCP files? I do a "locate" on usbd_cdc_vcp.c and find: 
/u1/Projects/STM32/F429/libs_stm32f429/00-STM32F429_LIBRARIES/usb_cdc_device/usbd_cdc_vcp.c
This is not part of this distribution, but is part of the collection from Majerle above.

/u1/Projects/Photon/firmware-0.5.3-rc.1/platform/MCU/STM32F2xx/STM32_USB_Device_Driver/inc/usbd_cdc_core.h

The "Photon" is some kind of STM32f205 based board. I think I even have one or two of these somewhere. The dates on these files are August, 2016. The MCU directory has both F2xx and F1xx support directories. In the F2xx directory, we see: 
CMSIS
SPARK_Firmware_Driver
STM32_StdPeriph_Driver
STM32_USB_Device_Driver
STM32_USB_Host_Driver
STM32_USB_OTG_Driver
So this looks like the distribution from ST (but from 2016 and for STM32F2xx parts). The organization is simpler (cleaner?) with audio, cdc, dfu, msc all together in the same directory.

It is hard to know whether this is good or bad. This is older code and for the F2xx parts, but if the class code is device independent, this old 2016 code could be simpler for study.

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org