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!
That looks awesome.
Everything is better with a CLI.
Agreed! :D I can hardly wait to give it a spin.
How does it compare to Zephyr, which also has a shell?
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!
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.
What problem does this solve when we are talking about RP2040?
Surely per the article – quick prototyping with a neat colour command line interface.
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 :)
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.
“after the break”
You mean the break that doesn’t exist?
Sending USB packets for each of GPIO toggling is horribly slow, is there a way to send a list of GPIO toggling commands?
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)
ssh , mc work?
I’m not see any ‘sh’ on /bin , this video show it is rather slowly
Can’t you already do all this with the Python CLI?
Sorry, I didn’t mean to reply to this specific comment.
ssh would make it run even slower, that’s not what this is for
Are there similar tools for the STM32? MicroPython kinda does this, but would like to see some others!
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)
Can this be used with pi pico w to wifi enable a Older generation laser or inkjet printer? Its been done with pi zero and pi 2 zero.
“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?
“Researchers Discover 40,000-Strong EOL Router, IoT Botnet”
https://www.securityweek.com/researchers-discover-40000-strong-eol-router-iot-botnet/
There are already similar Micropython shells such as mipyshell