Build Your Own RTOS in 30 Minutes

Answer: When it’s your own code, acting as if it were an operating system. Sound interesting? Or just confusing? Read on, Dear Programmer.

We’re all familiar with standard embedded operating systems such as Linux, Android, LynxOS, ThreadX, uCOS, and so forth. They’re all great products, and they all have hundreds of loyal and happy users. That’s splendid.

But regardless of your particular OS allegiance, you have to admit that you are limited to a small number of choices. In other words, while there are nearly infinite variations in embedded hardware, there’s a limited number of possibilities for embedded operating systems. There are a zillion different MCUs and CPUs, but only a handful of RTOS options. Hardware spans a continuum, while software is more of a step function. Why is that?

You might argue that this is simply The Way of Things; the inescapable result of RTOS evolution as the myriad choices are winnowed down to a smaller group of suitable candidates.

Or that operating systems require standardization by their nature, and, therefore, only a handful are necessary. After all, there’s a big spread between Linux at one end of the scale and ThreadX at the other. It’s not as though we don’t have choices.

But what if your RTOS was as original and custom-made as your hardware? What if it weren’t just a carbon copy of one of the existing RTOS offerings? What if you could roll your own – but without actually knowing how to do it?

Step inside a little software boutique called Zeidman Technologies, which has an RTOS-generating tool called SynthOS. Now, before we start handling the product, understand that SynthOS is the name of the tool, not the operating system it creates for you.

Creates? Yes, indeed. This is bespoke, custom-tailored software, but without the Savile Row pricing. In fact, it’s free. That’s free as in “free beer,” not “free speech.” Just to be clear, no money changes hands in this transaction. Not unless you want it to.

What the SynthOS tool does is to generate a custom RTOS for you that handles task switching and inter-task communication. It’s not as exotic or full-featured as the brand-name RTOS options, but it handles the basics. And it’s cheap. And it’s custom to your system.

How is this wizardry performed? The SynthOS tool is simply a Java preprocessor that runs on your development system. You feed it your C source code before compiling, and it automagically inserts the necessary code and data structures to call (and return from) the RTOS kernel. The result is your own C source code with a new RTOS woven through it. Each task that you define will have some code appended to it, and there will be an additional block of code that holds the RTOS kernel and other central functions. Source code in, source code out. You then compile and run as normal.

SynthOS lets you choose between priority and round-robin scheduling. And the definition of a “task” is up to you, as with most operating systems. SynthOS understands a grand total of five APIs or “primitives,” which you call out in your C programs. The SynthOS tool recognizes these and generates the appropriate C source code, including task-control blocks, message buffers, queues, semaphores, mutexes, and whatever else it needs. Interestingly, you never need to create (or even understand) things like semaphores in your own code. SynthOS creates those on its own. It’s probably the world’s easiest operating system to learn.

And did we mention it’s free? At least, it is if you don’t mind uploading your source code to Zeidman Technologies’ servers and getting your new RTOS-equipped code back the same way. For programmers who prefer a locally hosted solution, the company also offers a more traditional software license, for a fee.

SynthOS doesn’t create a very elaborate RTOS. There’s no file system to speak of, and it doesn’t include any network stacks. But it does handle task switching, and it’s tiny. Depending on the processor and the type and variety of tasks, the RTOS will occupy only a few KB of code space. In a few cases, it’s smaller than 1024 bytes. That’s smaller than the cache in a lot of processors.

SynthOS doesn’t play in the same league as Linux or Android, but it does fill a niche below what uCOS, FreeRTOS, ThreadX, and other space-efficient embedded operating systems can offer. And it runs on practically anything, including 8-bit MCUs and FPGA cores like Xilinx’s MicroBlaze, Altera’s Nios, and Cypress PSoC. Want an operating system for your Lego Mindstorms? SynthOS can do that, too.

The downsides include total non-standardization. Since each RTOS instantiation is custom-generated, no two implementations will be exactly the same. And there’s no third-party software available, nor much hope for any. If your idea of an operating system is a stable platform for application developers, look elsewhere.

On the other hand, a nonstandard RTOS also means nonstandard security. Which is to say, SynthOS is pretty much malware-proof. There’s no real attack vector because there’s no standard code to exploit. Indeed, it’s hard to tell that SynthOS is being used in a system. It doesn’t have any of the telltale segments of recognizable code. In the same way that DIY processors from ARC and Tensilica allow hardware developers to create custom instructions that thwart code disassembly, SynthOS allows programmers to embed inscrutable OS calls.

Traditional embedded operating systems are popular because they provide a solid service and because programmers develop expertise and get used to them. Most embedded developers grow loyal to their chosen RTOS. Indeed, they’re more likely to change processors and stick with the same OS than vice versa. That continuity makes programmers more effective and efficient.

SynthOS doesn’t really work that way. It doesn’t have the traditional reference manual full of APIs, function calls, and parameter-passing templates. It’s got just five basic primitives that start, stop, and switch tasks. As such, it’s easy to learn and quick to master. But it’s not a platform for outside software. There’s no interface layer that abstracts away the underlying system. It really becomes part of the underlying system.

Millions of people use Microsoft Word every day, and it’s safe to say that not a single one of them uses all of its features. Word (and Excel, and PowerPoint) long ago passed the point of being “good enough” and ran deep into the territory of rampant featurism. It keeps getting bigger and more complex, yet we really only use some small fraction of its total feature set, ignoring and wasting vast chunks of that expensive code.

Embedded operating systems can suffer from that same malady. They’re overkill for some projects, yet they persist because they’re popular or because they provide continuity and compatibility with other systems. That’s fine – that’s part of what an operating system is supposed to do – but it’s not always necessary. If what you want is a simple, straightforward RTOS that’s just your own, SynthOS can make you one to order.

Related

7 thoughts on “Build Your Own RTOS in 30 Minutes”

Well, I don’t consider Linux a real real-time OS. Does SynthOS generate a pre-emptive OS?
What about interrupt latency in terms of something like “number of instructions”?
Task switching time is also an important parameter. Can you supply some numbers on latency and task switching in a few scenarios from the real measurments where you specify MCU, Clock frequency etc.?

Just from SynthOS website:
– “Interrupts are supported. System used forced cooperation for multitasking rather than pre-emption.”
Then look at the figures for interrupt latency, context switch time, etc.
=> pretty slow compared to any other embedded RTOS.
The idea is not bad, but it’s not an RTOS. Preemption is a must. SynthOS uses clearly cooperative scheduling (which allows them to use C only).
Our own RTOS (preemptive an distributed by default) has times like 400 nanosecs interrupt latency on a 50 MHz ARM. Context switch times in the order of microsecs .And we generate the RTOS image for each node in the system (since about 20 years). Down to a few KBytes, maximum code size with all services is around 15 KB. One can also define his own application specific services. See http://www.altreonic.com
As said, the idea is very good. But don’t stick claims on it that are not true. Some other (RT)OS vendor claims he has zero interrupt latency. With such a claim, what can you say about the rest? Never trust such statements in the context of safety critical applications. It might work most of the time, but not all the time.

At the Linley Fall Processor Conference recently, the keynote on the second day was by Cliff Young of Google titled Codesign in Google TPUs: Inference, Training, Performance, and Scalability . The TPU is Google's Tensor Processing Unit. It is actually a family, since, as...

If you aren't from the packaging world, then chances are likely you might think 'packing' refers to objects being placed in to a box instead of packaging integrated circuits (IC's) on a substrate. Packaging has advanced since it began, and as with many areas i...

People of a certain age, who mindfully lived through the early microcomputer revolution during the first half of the 1970s, know about Bill Godbout. He was that guy who sent out crudely photocopied parts catalogs for all kinds of electronic components, sold from a Quon...