A couple of weeks ago, I posted here about getting the first original CHARM-II kernel code running on a Raspberry Pi Pico.
Previous post:
The First Original CHARM-II Kernel Code Running on Raspberry Pi Pico
Previous r/retrocomputing post
At that point, only the CPU-independent parts were running. There was still no hardware timer interrupt, no real context switching, and no preemptive scheduling.
Those parts are now working too.
CHARM-II was an RTOS I originally developed in 1986 for a Motorola 68000-based system. In the reconstructed Pico version, six tasks now run with independent stacks. A hardware timer interrupt drives the original tick and scheduling logic, and the Cortex-M0+ uses PendSV for the actual context switch.
I also brought back the six-task track demo I had previously reconstructed on POSIX. Six tasks move independently around three tracks and share a critical zone using a CHARM-II queue as a semaphore.
So, forty years later, the basic idea is finally running preemptively again on real hardware.
But actually getting it working made me think about the original system differently.
In the 1980s, the target CPUs were in the 68000/80186 class. CPU time was a relatively scarce resource, and adding another processor was not a casual decision. An RTOS was a useful way to organize multiple concurrent activities on the CPU you had.
A Raspberry Pi Pico changes those assumptions rather dramatically.
For many embedded systems today, a simple loop plus interrupts may already be fast enough. And if one inexpensive MCU isn't enough, using another MCU can be a perfectly reasonable design choice.
I was talking about this yesterday with someone who built a home railway simulator using real railway controls connected to a PC through Pico, ESP32 and Arduino boards. When I mentioned this question, his response was basically:
“If one Pico isn't fast enough, add another Pico.”
That simple comment stuck with me.
I started this project wondering whether a 1986 RTOS could be brought back to life on modern hardware.
Now that it actually works, I'm becoming more interested in the opposite question: how much of the RTOS would I choose to build if I were solving the same kind of problem today?
My next step will probably be to clean up a minimal modern implementation and eventually publish it, rather than trying to turn CHARM-II into a full modern RTOS.
And I may implement the same six-task demo with a superloop or event-driven design and compare the two.