hardware abstractions and modularity

[biot]

Hi Cavin,

I like Breadboard OS and its stated goals, and thought I might help out. However I noticed some issues with the codebase, and I'd like to see whether you agree with my analysis.

• The README states that "all hardware-specific code resides in a single directory", so as to make porting easier. That's true, but the build system is very much hardcoded to the pico. The top CMakeFiles.txt has build, project and hardware-specifics in it. I think this should be split up, so another top-level file (project.cmake) holds projects stuff, and hardware-specific build stuff should be in that hardware's directory.
• The build is not modular enough -- aside from the hardcoded pico, it also has the driver_lib code always compiled in. You can disable those drivers, but the code is still compiled and linked in to the binary, and that's just not going to scale.
• Speaking of scale, the binary image is huge, already over half the size of RAM in the RP2040, and that's without runtime memory allocation. Seeing as how BBOS's aim is to provide a base OS for people to develop applications on top of, that's not such an attractive option. Combined with the driver situation this is a project killer: add another 20 drivers and there won't be any room for a user application to run at all. The only way to deal with this (IMHO) is:
  • Drop the two ASCII art logos, they're huge. OS output on boot shoud be minimal.
  • Drivers should be modular, and not actually compiled unless specifically selected.
  • Even the top-level modules should be optional in this way, including littlefs and even cli. FreeRTOS gets a pass, but there may be opportunity for thinning down its build.
  • Same for the services.
• I think the build could be made easier by dropping in FreeRTOS and pico-sdk in git submodules, like you're already doing. pico-sdk is a little harder -- it shouldn't be pulled in when a non-pico platform gets added to BBOS.

I have some patches, but I'd really like your opinion on the above before I put in any more effort.

[mcknly]

@biot , thanks for the interest and taking the time to look through the code. I mostly agree with your analysis - here are my comments on each of your points:

1. Absolutely true. I knew the top-level RP2040 specific build recipe would eventually become a problem when a new platform was added; it will need to be re-tooled and your suggestion to split the CMake is the way to do it. There were a number of refactoring cleanups that I deferred in order to release the project into the wild a little faster.
2. This is another one of those cleanups! For sure many things should be more modular through build options (this is after all one of my stated goals!)
3. Dead on, as stated above - there are a lot of things compiled in by default that I just lived with for the time being since Pico has a lot of resources. Needs to have an option to slim it way down, maybe even a blanket "minimal build" which strips out things like the eye candy (the boot logos make for a better YouTube video :)
4. This is one I thought a lot about before releasing. I opted for not including the FreeRTOS kernel or Pico SDK for several reasons: many who are already developing on RP2040 would already have the SDK and possibly FreeRTOS; cloning those repos takes time and disk space (especially Pico SDK with its sub modules, >500MB); and assuming a new BreadboardOS project begins each time with a clone or fork of the repo, someone with many projects would have multiple copies of these which just seems wasteful. Maybe we could come up with a setup script which could be run once to optionally download, setup environment variables, and even configure specific drivers/modules/services and thus build size.

Looking forward to collaborating! FYI, I enabled the "discussions" feature on this repo (should show up on the top tabs now), I've never used it but maybe it makes things easier.

Cheers! Cavin