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

[mcknly]

Found the "convert to discussion" button

[biot]

Didn't know about the discussion feature, looks good.

Re splitting the build, I've done this. Take a look at my depico branch (https://github.com/biot/breadboard-os/tree/depico). Ignore the "local env" patch, and the microshell styles patch is also unrelated. Feel free to squash the other commits, just wanted to document the process. It's probably not as elegant as it could be (first time using cmake), but it works well.

Minimal build option sounds good, the question is how should a user add stuff to it? A project.cmap that is minimal but has drivers/services commented out? This won't scale when drivers etc get added.

WRT FreeRTOS/pico-sdk, how about having it both ways? If there's a "FreeRTOS-Kernel"/"pico-sdk" directory present in the top-level BBOS directory, set FREERTOS_KERNEL_PATH/PICO_SDK_PATH env vars to them automagically from CMakeLists.txt. That way you don't have to do anything once you have them set up for your environment, and you keep the current flexibility.

One thing I forgot to mention: the pico stuff has crept into the cli code as well, of course. This stuff is hard, unless you start with two platforms! In any case the cli needs to be super modular IMHO, as I expect platforms will need platform-specific commands added to the cli -- setting some hardware-specific flags and such.
The way I see it, every platform and driver should be able to have a cli/ subdirectory where commands can be added from.
cmake seems plenty flexible enough to do that, and it would make for a very powerful environment -- imagine any platform/driver/service in its own subdirectory with optional subdir cli/, an entirely self-contained module that is instantly available for compiling in.

[mcknly]

I've had a look at your changes and tested your branch, overall looks really good. I like the direction you are taking it. Couple notes:

• The FreeRTOS port path is still hard-coded to RP2040, it would be hard to automatically figure out where to look based on platform name, but maybe we can have a path lookup table based on your PLATFORM definition in project.cmake
• The 'target_link_libraries' in the top-level CMakeLists.txt has hardware libraries from pico-sdk, these could also move to the hardware-specific cmake file
• proc/mcuinfo references RP2040... could use your new PLATFORM cmake variable to pass the name

Regarding your idea for platform-specific CLI menus contained within the hardware folder, I like it. Makes sense to have a base set of menus in root cli/ and then optional custom menus. Could easily be done within 'shell_init()' function in shell.c, maybe using #ifdef to see if any platform-specific menus exist (somehow). As you mentioned before the dev/ and lib/ folders should also be populated modularly based on the platform-specific interfaces and drivers that were optionally compiled in.

Nice work so far.

[biot]

How about detecting FreeRTOS-Kernel in the root dir and setting FREERTOS_KERNEL_PATH as needed, and in hardware/rp2040/CMakeLists.txt adding portable/ThirdParty... to it? That way the env var should always just point at the FreeRTOS root, which is needed for portability anyway.

Glad you like the build patchset, but as I said I think it's perhaps unelegant. I hope you'll merge it and use it as a base for improvements. I'm really not that familiar with cmake.

[mcknly]

That's a good idea to have the path relative to the base FREERTOS_KERNEL_PATH within the platform-specific cmake. I still haven't wrapped my head around how to detect if FreeRTOS already exists somewhere and preventing it from cloning as a sub-module (and Pico SDK for that matter).... maybe cmake can do the clone if they don't exist and the env variable is not already set?

This is the first project I've used cmake on as well, and I'm hardly scratching the surface of it. Anyways I like the patches and would be happy to merge them in if you prepare a PR. BTW, do you have any other platforms in mind that you're considering porting to?

[biot]

I've just created PR #6 for the build split.

The sooner you get another platform in, the better -- it's what's really needed to shake out pico-specific things. I think it should be a non-ARM platform, to shake out ARM-specific things as well (looking at you, cmsis-core). So something like a RISC-V or ESP32 MCU would be ideal.

[mcknly]

ESP32 probably makes sense due to ubiquity in the hobbyist realm.... I've a few ESP32-S3 boards but have not done a whole lot other than build some examples. ESP-IDF by default wants to use its own cmake build system and Espressif has their own flavor of FreeRTOS, but it appears from a quick search that you can decouple those things and include individual ESP-IDF components as cmake libraries.

[biot]

You don't have to use the vendor SDK, of course. All in all BBOS doesn't/won't use all of an MCU's feature, and supporting only the basics (GPIOs, UART etc) isn't THAT hard to do directly on the hardware.

[mcknly]

Point taken; however I think if a particular MCU family like ESP32 is someone's platform of choice, these days they will likely already be using the SDK, so having a method for out-of-the-box integration would help with project adoption.

[mcknly]

#6 merged - also created hw-decouple branch to implement the rest of the cleanup.

[mcknly]

Created #8 to track