March 6, 2025

Black Pill boards - F411 USB -- rearrange some BSP routines

I am looking at a file Hydra/usbF4/vcp/usb_bsp.c

I want to get rid of it.

Why? -- is what I hear you ask.

There are several reasons actually. One is that it is out of place. The letters "BSP" are for "board support package" -- at least I think so, and some of the contents fit this description. Some software is arranged with a different "BSP" for different hardware it runs on. For example the BSP may supply (as this one does) a delay() routine that is implemented differently on every board or chip.

I want such routines to be either in Hydra itself (i.e. part of code in some higher directory) or at the very least in the "driver" directory, not the "vcp" directory, which should only have code pertaining to the virtual console port.

Let's take a look, then get started. This file contains only 6 routines: 

void USB_OTG_BSP_Init(USB_OTG_CORE_HANDLE *pdev)
void USB_OTG_BSP_DeInit(USB_OTG_CORE_HANDLE *pdev)
void USB_OTG_BSP_EnableInterrupt(USB_OTG_CORE_HANDLE *pdev)
void USB_OTG_BSP_DisableInterrupt(USB_OTG_CORE_HANDLE *pdev)
void USB_OTG_BSP_uDelay (const uint32_t usec)
void USB_OTG_BSP_mDelay (const uint32_t msec)

The first two are already commented out for Hydra, so we can consider the second pair. Note that we have first Init/DeInit, then Enable/Disable. I can immediately decide to do away with the DeInit and Disable. We set up USB and run it until the end of time. What do we do then about "EnableInterrupt?" The call is in library/usbd_core.c I ensure it is commented out and then dump the first 4 routines in usb_bsp.c I can do this because I have already set up interrupts as well as configured the USB clocks and hardware in my own code (usb.c) so I don't need this code that came from Arduino_STM32.

There is some interesting hardware configuration in the BSP_Init() routine. I move the usb_bsp.c up a level (next to usb.c), but exclude it from the build. This allows me to admire it later at my leisure.

What about those delay routines. I rename them to board_uDelay() and board_mDelay() and put them into usb.c. This also requires me to find and rename all the calls. The calls are all in driver/usb_core.c and driver/usb_dcd.c This makes sense. Only the driver should be dealing with delays and timing details.

After this and some fooling around I get a clean build and I have eliminated two source files (usb_bsp.c and usb_bsp.h)!!

Some improved debugging

Right now I have a bunch of printf statements scattered around in the source code. Some of these are from years ago, and in some cases I have forgotten my original intent. I have learned that putting some organization into debug printout like this pays off in big ways (as compared to random print statements). I am considering a facility like this:

First a variable "debug_mask" that has individual bits to enable/disable certain debug staements. Then each printf needs to be guarded by some conditional statement that looks like: 

	if ( debug_mask & DM_ENUM )
		printf ( "......." );
This works, but requires that the debug_mask variable, as well as the bit definitions, be available to every file that wants to use the facility. My scheme is to put this into hydra_usb.h. I could contemplate some kind of macro to make this less verbose.

What I decided to do instead is to add the following routine to usb.c -- 

usb_debug ( DM_ENUM, "....." );
It is really a conditional printf in disguise.

We could make this a macro in hydra_usb.h. This would allow us to make the macro empty, thus entirely removing generated debug code from a final build. This would be a bit tricky with variable number of arguments.

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org