Meta

Colin WallsColin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor Embedded [the Mentor Graphics Embedded Software Division], and is based in the UK. « Less

Colin WallsColin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor … More »

The one line RTOS

I like simple things. Excessive complexity tends to annoy me. When I first started working with computers, I thought that mainframes were overly complicated, so I was pleased to discover minicomputers, where I could really understand exactly what was going on. Embedded software was a natural progression, as, again, I could grasp the entire functionality of the software. But that began to change, as commercial real time operating systems and other software IP became more common. Everything became more complex and invisible.

I am not saying that this situation is necessarily a problem or that all complexity is intrinsically bad. It is just that sometimes I yearn for the simple life. It might be suggested that perhaps the world of software is not the best place for me, but I will ignore those murmurings and consider where simplicity might still be appropriate …

This may sound a little naive, but I have always found multi-tasking software fascinating. Whilst I am quite clear that a single CPU cannot really run two or more programs simultaneously, software that makes it look like it can is rather appealing. Way back in the early 1980s, I wrote a kernel for a project and found it very rewarding to have cracked context saving and switching and task scheduling so that it behaved in a predictable way. That code was small and simple – just a couple of K of assembly language.

Nowadays, I would mostly council against writing your own kernel, unless your needs are extremely simple and I will come on to that. If you need a preemptive multi-threading operating system for a hard real time application, it makes most sense to look at a commercial RTOS like Nucleus. If real time and limited memory footprint are not priorities and you want a lot of middleware available off the shelf, perhaps Linux or Android might fit the bill.

Maybe your needs are very simple: just a few tasks; not hard real time; each task has a modest amount of work to do every so often. You could use a commercial RTOS, but perhaps that would be overkill. All you need is a Run to Completion [RTC] scheduler. Here is the code:

#define NTASKS 3

void (*tasklist[NTASKS])() = {alpha, beta, gamma};

int taskcount;

while (1)

{

for (taskcount=0; taskcount<NTASKS; taskcount++)

(*tasklist[taskcount])();

}

This is very simple. The array tasklist contains pointers to three functions, each of which is a “task”. These are each executed in turn and are obliged to complete their work and return in a timely fashion. When all three tasks have been run, the sequence is repeated.

OK, to be strict, this was not one line of code and it is not an RTOS, but it is a simple way to get basic multi-threading.