BreadboardOS, A Command Line Interface For The Pico

Operating systems! They’re everywhere these days, from your smart TV to your smartphone. And even in your microcontrollers! Enter BreadboardOS for the Raspberry Pi Pico.

BreadboardOS is built on top of FreeRTOS. It’s aim is to enable quick prototyping with the Pi Pico. Don’t confuse operating system with a graphical environment — BreadboardOS is command-line based. You’d typically interface with it via a serial terminal emulator, but joy of joys, it does support color!

Using BreadboardOS is a little different than typical microcontroller development. Creating an application involves adding a “service” which is basically a task in FreeRTOS parlance. The OS handles running your service for you. Via the text interface, you can query running services, and start or kill them at will.

Meanwhile, running df will happily give you stats on the flash usage of the Pi Pico, and free will tell you how full the memory is doing. If you really want to get raw, you can make calls to control GPIO pins, the SPI hardware, or other peripherals, and do it right on the command line.

BreadboardOS isn’t for everyone, but it could prove a useful tool if you like that way of doing things. It’s not the only OS out there for the Pi Pico, either!

22 thoughts on “BreadboardOS, A Command Line Interface For The Pico

    1. Zephyr shell is something built to fit inside an existing firmware project (one using Zephyr).
      So that you get a few commands right from the debug UART used for logging.

      This shell looks more focused on RP2040 and on bringing tooling that help with poking at things, and mimics UNIX commands (“cat /dev/gpio” instead of “gpio show”). Less easy to inject *inside* your existing firmware project, more meant as a lab bench equipment.

      Zephyr shell can still be used as a “breadboard tool”, in particular if you wish to drive an external peripheral that is supported by Zephyr. I use it this way. I work a lot more with Zephyr and different MCUs than the RP2040 so for me it fits. A matter of taste too I guess!

      1. Ah: namely: Zephyr (everything contributed back upstream by design) vs FreeRTOS (abundantly using 3rd-party projects rather than writing something in-tree).

        Different folks will have different preferences. I appreciate both approaches for different reasons.

    1. if you’re trying to deploy an rp2040 embedded into a product with a fixed function, i don’t know if it helps you even a little bit. unless you want to use the rtos in your finished product.

      but i have an rp2040 hanging off the back of my PC that i use whenever i feel like i wish my PC had GPIO. so i need a way to send a unique one-off program (a hack) to the rp2040, ideally without going through repeated plug/unplug cycle or holding down the little usb bootloader button. for me, i’ve solved this problem by only programming the SRAM (not the flash), so that it always reboots into the USB bootloader. and the other half of my solution is i always use the watchdog timer so that it reboots after a while, so i don’t have to manually reset it.

      but dang if i don’t look at this with envy. it’s not really how i would solve the problem, because in small processors i still indulge my disgust for large SDKs and so on. i haven’t even looked into it but i just assuming that the underlying rtos is gonna tie me to a specific set of development tools and libraries. on the rp2040, i want to do bare metal programming.

      but this project makes me feel like my ‘not invented here’ syndrome might actually be a disease :)

      1. For both of us: At a glance it’s just gcc, the freertos kernel itself, and the pi pico sdk. Obviously that list could be shorter, but not without drastically increasing maintenance overhead. If anything it’s just overkill and I think this is a good effort.

    1. yeah you would just develop your own freertos service and upload it, and breadboard would just be a shell for overseeing that process. your service would be able to use the full I/O capabilities. (at least that’s what it looks like from the article)

  1. I’m currently working on an engine swap in an older vehicle and need to translate the signals from the ECU to the dash board to make the gauges work. Would I be able to use this OS with a Pico to do the basic remapping of these signals to drive the original dash cluster? (1984 vintage)

  2. “Operating systems! They’re everywhere these days …”

    Costs to TRY TO repair damages caused by these c/c++ 1 buggy 2 malware vulnerable 3 uncertified OSs may cause lots of bankruptcies?

    UnitedHealthcare hack attacks damage repair bill?

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.