USB drivers and "events" library added to bare metal profile

[evedon]

Summary of changes

USB drivers source files are moved under drivers/source/ removing the need for a specific “drivers-usb” library.
This means that USB drivers will be built by default in bare metal.

The "events" library is added to bare metal profile because USB drivers depend on it.
This library provides functionality to schedule events without relying on a RTOS
and so it is useful to have it enabled by default in the bare metal profile.

Impact of changes

USB drivers are built by default in bare metal.
The "events" library is added to the bare metal profile.

Migration actions required

None

Documentation

The following page needs to be updated: https://os.mbed.com/docs/mbed-os/v6.3/bare-metal/using-the-bare-metal-profile.html#2-adding-apis

---

Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[X] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

---

[evedon]

FYI @jeromecoutant

[ciarmcom]

@evedon, thank you for your changes.
@ARMmbed/mbed-os-core @ARMmbed/mbed-os-maintainers please review.

[0xc0170]

How USB can work in baremetal ? I found storage dependency when working with CMake. Some of the USB drivers like MSD depend on blockdevice. We had to disable USB with drivers and make it own library that depends on storage, otherwise it did not compile.

This is how we made USB compile (depends on storage):

target_link_libraries(mbed-os-usb INTERFACE mbed-os-storage)

[evedon]

The USB drivers library compiles in bare metal. The USBMSD driver has a dependency on blockdevice but the blockdevice library is compiled by default in bare metal because it does not have a mbed_lib.json file. This is inconsistent with the rest of the code and I don't know the history behind it.

But you are right that if an application uses the USBMSD driver, it will have to compile with one of the underlying storage driver, for example SPIF.

This PR is raised to remove some inconsistencies in the drivers library: USB drivers include files are part of the drivers public API but their associated source files are not compiled by default in bare metal.
It was also noted #13406 (comment) that "drivers-usb" library can be built in bare metal.

[LDong-Arm]

LGTM.

If we want to resolve the inconsistency of missing mbed_lib.json for blockdevice, we can create one there (may be named "blockdevice-api" to avoid the impression of dragging the whole stack into bare metal) and remember to add it to bare metal.

[0xc0170]

The USB drivers library compiles in bare metal. The USBMSD driver has a dependency on blockdevice but the blockdevice library is compiled by default in bare metal because it does not have a mbed_lib.json file. This is inconsistent with the rest of the code and I don't know the history behind it.

That explains it. The docs even state (can be manually enabled) but this is rather set as "auto enabled". I'll need to review how to fix this in cmake.

[LDong-Arm]

That explains it. The docs even state (can be manually enabled) but this is rather set as "auto enabled". I'll need to review how to fix this in cmake.

IMO blockdevice should not be auto-enabled - even platform and drivers which are more basic are not auto-enabled. Adding mbed_lib.json makes it more consistent and avoids the trouble in CMake.

[evedon]

That explains it. The docs even state (can be manually enabled) but this is rather set as "auto enabled". I'll need to review how to fix this in cmake.

IMO blockdevice should not be auto-enabled - even platform and drivers which are more basic are not auto-enabled. Adding mbed_lib.json makes it more consistent and avoids the trouble in CMake.

Agreed. I will add the missing mbed_lib.json

[LDong-Arm]

LGTM

[0xc0170]

Before I approve, I would like to assure myself everyone is on board with adding these new deps ( as it has implications for a lot of users).

Because of usb, we are pulling in events and blockdevice to baremetal. I would understand events to be useful library but usb or storage for baremetal, their use is specific. My understanding of baremetal is the basic functionality and people can add more if they want to. Where we draw a line what is in Mbed Os vs Mbed baremetal?

Taken from CMake:
mbed-baremetal (hal, rtos-api, targets, cmsis) - 167 files (for k64f target)
mbed-baremetal with usb - pulling in events, blockdevice and usb - 212 files (for k64f target)

In the new CMake world we go to, a user would do target_link_libraries(mbed-baremetal) for simple applications, if they want usb they add mbed-usb (it would pull in automatically storage and events due to dependencies).

Note to myself: I need to get the CMake branch to master, we would see here how it changes what it's building.

[ladislas]

My understanding of baremetal is the basic functionality and people can add more if they want to. Where we draw a line what is in Mbed Os vs Mbed baremetal?

@0xc0170 If I may add my $0.02, I completely agree with you.

IMHO, baremetal, as the name suggests, shoud be as stripped naked as possible. The bar to add things as default should be very high so that people can really rely on the baremetal idea of building from the ground up and adding only what you really need.

The corollary to this idea is that documentation on how to do so should be cristal clear and gather all the informations needed to follow this process.

Based on my personal experience, I tend to add things because I think it would be difficult for people to add them on their own.

But if it is, the solution is not to add things, but to rethink the way the system works and make it easy for people to add the things they need for their specific use case.

I've never used USB in my projects so I cannot say in which category it falls, but IMHO it's worth asking the question.

[evedon]

Because of usb, we are pulling in events and blockdevice to baremetal. I would understand events to be useful library but usb or storage for baremetal, their use is specific.

As noted in a previous comment, blockdevice was already in bare metal so it is not added by this PR.

[evedon]

Note that I don't have a strong opinion on moving USB drivers under drivers/source. As an alternative, we could create a drivers/usb folder for consistency with the rest of the directory structure.

[rajkan01]

@evedon I even agree with @0xc0170 @laides that baremetal profile should have minimum required stuff and moving USB source under drivers/source and gets included into the build will increase overall size as previously this was controlled via drivers-usb JSON configuration

[evedon]

I will raise two separate PRs then. One to add the missing mbed_lib.json for blockdevie. One to move USB drivers under drivers/source.