Middleware Implementation Good Practices

I am having issues on a project for STM32F070RB platform. Working on the issue has raised a question that I struggle to find answer to. I’ll introduce the question by explaining what’s happening.

Back at mbed OS 5.14 version, I implemented a custom middleware for the USBPhyHw for STM32F0 family. I made a new file where I literally implemented the UsbPhyHw class all over again. Matter is, I didn’t want to modify OS source, in order to maintain compatibility across versions. So, instead of touching mbed-os folder, I created a .cpp file under the root of the project, included the neeeded headers from the mbed-os HAL and made my own implementation, that actually ended up working fine (at least for USB HID).

Last week, with Mbed Studio and mbed OS 5.15 update, I decided to keep all the source up to date. After the OS update, code would still compile, but the linker will always link the original USB implementation (that throw an mbedOS error) instead of loading my custom one, thus throwing the “This board does not have a hardware USB driver” error (that happens because the default USB implementation in mbed-os for F0 devices throws this error even though the MCU itself has the HW USB module).

No matter what I tried so far (for instance I tried to use the .mbedignore file to exclude the original middleware from the compile process), I always end up getting the error generated from the “wrong middleware”, implemented in the stack.

Probably most devs would just modify the original source file, or delete it, but as I said before, I don’t think that modifying the OS, that is usually excluded from Git, is a good plan. Besides, I should be doing it every time I update the OS; and if I fetch the project from a Git repo, I wouldn’t have the changed file tracked.

“Why don’t you make a pull request?” Because the code is still in development, really unorganized, and it doesn’t pass tests due to a couple of issues I left there. Besides, this solution would fit this particular scenario, but wouldn’t be fine for every case in which the dev has a custom middleware.

Generally speaking, is there any good practice when I want to use a self-implemented middleware that “overrides” the standard OS class implementation? A way to modify the linker behaviour to make my custom code “win” against the original, or just a working way to exclude the OS one?

1 Like