The pico-sdk code is BSD-3 which is compatible with libhal's Apache 2 license. We should make a 3P library for the pico-sdk, have libhal-rp2040 require it and use it to implement the libhal interfaces. Unlike NXP and STM software with restrictive licenses, we can simply borrow code from the pico sdk. Note that I strongly feel that the libhal team should implement drivers for SDKs with problematic code. But if the software is shown to work well and is stable, then we should opt for the faster option of utilizing the software that already exists.

Note about ST's license. I plan to use the libhal-stm32f1 and any others that we support with copycat hardware from gigadevice to the others. From ARM to RISC-V. The drivers work as expected, but need to be mapped to different locations. If we had used the original st software, we wouldn't be able to do this and their SDK wouldn't be designed in a way that makes it easy for us to port to the copy cats.

Using a package to download the binaries for clang and llvm will prove very helpful in the future as currently, users tend to have issues with ensuring that the correct version of clang or llvm is used. Even with the path to the c and c++ compilers set in the profiles, they still need to ensure that the compiler is preinstalled on their machine. We could elevate this need and move everything to conan to make the setup requirements simpler.

Devs using libhal may still want to install llvm and clang on their machines simply to use clangd. But if we could figure out a way to use the clangd from our package in a way that doesn't get nuked when the the .conan2/ folder gets deleted. Or if possible, somehow ensure that the path to llvm/clang package is the same between installs.

So users can use FatFS with any of their storage devices.

libhal does not have a low power story which means that libhal cannot provide a consistent pattern for putting devices into low power. This should be investigated to determine the categories of low power states and how those could be applied to libhal libraries. I could imagine that there are the following low power categories:

• low_power(): Put the device into an idle mode that requires very little work to reactivate
• deep_sleep(): Like low power but a bit deeper and may require some startup time before the APIs resolve themselves.
• shutdown(): Completely turn off the device. The assumption is that the device loses all state in this mode and would need to be reinitialized to allow APIs to work.

Should include issues for adding drivers for the:

1. Ethernet devices: https://www.wch-ic.com/products/categories/78.html?pid=4
2. Keyboard & Mouse: https://www.wch-ic.com/products/categories/61.html?pid=1
3. UART expanders: https://www.wch-ic.com/products/categories/57.html?pid=3
4. Io expanders: https://www.wch-ic.com/products/categories/58.html?pid=3
5. Bluetooth Ble: https://www.wch-ic.com/products/categories/54.html?pid=63

Rather than a new yaml script for each deployment version, just have a single one that reads the tag version it is launched against. If a different version of CI is required to work with this, then an additional yaml script can be made just for those older versions.

We get the same benefit as we did before without needing to make a new file each time which is tedious. I'm not sure why I didn't think of doing this originally.

libhal-doom takes the portable doom code and implements it using libhal interfaces and drivers. A suitable MVP for this project is the ability to use libhal-micromod, a display following libhal's display interface, and the wii classic controller and play doom. With the libhal-micromod project you should be able to compile for every single MicroMod libhal supports so long as it has the components to drive the display and i2c to talk to the controller.