Originally published:

April 26, 2017

Updated and reformatted for new host, May 20, 2024.

Most of us are doing it…

The Barr Group publishes a survey about Embedded Systems Safety and Security. Every time they do, one question that interests me is “what OS is your system using”. For a while I checked to spot a trending RTOS or if Linux skills would still be a good thing to have in the future. None of us wants to end up searching for a new job with out of date skills.

The results as a PDF for the 2017 survey are online here. Check out page 8, titled “Primary” Operating System. Notice that “none”, “proprietary” and “other” add up to over 32% of the total. There is no number for “other”, but it is a large enough slice to appear on the chart. That is more than Linux, or any one RTOS. What do people mean by “none”?

No Operating System? There is always something

None is a weird answer. More like an engineer saying, “hey, that is a really personal question, so don’t ask.”

I am the first and loudest person to say use an RTOS. Use a Linux. Go to the Yocto project and download something. Don’t write software if you don’t have to.

Why would I say that? There are a lot of reasons. If you need to have a TCP/UDP/IP connection, building something large and complicated like that is not time well spent on a project. Your project is not a special snowflake that needs a hand crafted network stack.

The other reason is, I have seen the result. I have been paid (and paid well) to fix the result. The common way to get something done on a small microcontroller is what we’ll call the Big Loop Operation Worker System. (BLOWS). Here is the psuedo code for BLOWS

int main()
init_isr(); // Initialize the interrupts
isr_disable(); //Turn off the interrupts until we get things going
init_RS232_fifo();
init_some_other_thing();
init_display();
for(;;){
    reading = reread_a2D();
    calculate_measurement(reading);
    isr_enable();
    update_display();
    send_serial();
    if (serial_data())
        recv_serial();
    if(!new_a2d())
    {
        sleep(10ms);
        // TODO: The sleep time seems wrong    }}
return 0; // Should never get here.init_hw();

The above is a mess, not just because of the formatting. Here is a question, how will we test the code? I don’t know either, I hoped you had an answer. Each task we could call a BLOWS chunk. Not a pretty picture.

What’s better

Well, the only way to answer that is by asking what we want.

1. A simple way to do “stuff” on the microcontroller
2. Easy to understand
3. Easy to expand
4. Testable
5. Fix that sleep time thing while we are at it.

The main requirement here is simplicity. The code above is a mess, and it is only doing 6 things. When the product managers ask for another feature, it will blow up. There is nothing wrong with a big loop. The way it is constructed and tends to grow organically is broken.

Can we do better? Yes, but I will save that for the next post.