We’ve all been there at some point in our career: you’ve played around with an idea for a while and come to the conclusion that it’s viable. Now you want to create a proper project to either explore the idea further or productize it. But from which software framework do you start? Espruino? Arduino? microPython? Segger embOS? Micrium uC/OS-II? And what’s the difference between uC/OS-II and uC/OS-III? Should you settle for an open-source framework with low initial cost or pay up-front for a commercial solution that will accelerate your design process?In this whitepaper, we discuss the parameters you need to consider for making a good software selection for your MCU or wireless MCU project.
Throughout this document we will be using the phrase “software framework” quite a bit. Before we start, we should take a look at what that really means. In this document it is used as “one specific way of writing software”. For example, Arduino offers one specific way of writing code that allows pieces of software to be re-used across multiple projects.A software framework is comprised of several different pieces and is defined by the following: the programming language, the APIs, and the coupling with a certain set of tools. It can, for example, be tightly coupled to the tools, such as in the case of Arduino and Espruino, or decoupled, like in the case for Micrium and FreeRTOS.
So, selecting a software framework? First we need to clarify a bit of terminology, and we’re starting with the term operating system (OS). What you really want to write is the code that runs your special sauce, the code that differentiates your product from the rest. However, you will need to rely on other pieces of software, like drivers for the ADC or a file system stack for the SD-card. These pieces of software are generally referred to as software components.
An effective analogy might be to think of your software components as bricks, and you can view the OS as the cement. The operating system defines the shape of the bricks and how they are going to interact with other bricks, so that as you add more components to the software, they will continue to work flawlessly together. Sounds great, but do you really need an OS? Adding an OS does come with an overhead. It will consume a couple of kilobytes of flash, add some delay to event responses, and there is a small investment in learning how to program an in an OS-environment.
The general rule of thumb is that if you’re targeting a flash size 128 KB or higher and/or are doing communication that requires a stack (USB, Ethernet, SDIO, CAN, Wi-Fi, BLE) you will be better off using an OS in the long term.
One of the most important things in an operating system is the scheduler. The scheduler is the component that allocates resources and processing time for different tasks that might be competing for the same resources. In general, there are two ways a scheduler can work, and this is where the ‘RT’ in real-time operating system (RTOS) comes in. Real-time means there is a consistent time that a certain task will take to execute. Let’s say you get a radio package that you need to take care of no matter what your device is currently doing. An RTOS kernel will then leave the other tasks it is doing and complete this high-priority task instead. This type of behavior is not the most efficient in terms of processor utilization, but it is required for communication stacks and applications where response-time matters, such as motor-control.
Let’s say you’ve figured out whether you need an RTOS or not, and are starting to assemble the software requirements. You might know that you need a USB stack and an Ethernet stack, together with a driver for an external MAC/PHY to connect your device to the internet. But where do you go from there? Do you just download the latest FreeRTOS example for your preferred MCU and continue to download open-source software to plug into it? Or do you just go to a commercial vendor that has the software you need and acquire the full portfolio?
To make an educated decision about this, we are often talking about total cost of ownership (TCO) for a given solution. The TCO is not only the monetary value you pay for software but includes the work hours spent searching for solutions, assembling the different components, integrating the different components into your project as well as development, testing, and production.
In general, what we see is that the total cost of ownership (TCO) is lower with a commercial solution than assembling the solution yourself with open-source components. But being a commercial solution it comes at an initial cost. These vendors often require you to pay between $10k and $100k up-front for using the solution, depending on what components you need. On the other hand, downloading FreeRTOS and starting to assemble the solution yourself is cheaper in terms of money while certainly more resource intensive.
So, you’ve come this far and your brain is probably screaming “just give me a framework I can start using!”
Not so fast. While there are certainly some options that are better than other, MCU applications are so diverse that there are no on-size fits all solutions. We’ll go over the most popular operating systems and software frameworks and discuss each one in detail:
All the operating systems mentioned in this chapter are real-time capable (RTOS).
Some of the operating systems or cement for gluing bricks together are so tightly coupled with the development framework that you in general cannot use the software itself as part of a project, but you have to base your entire development flow around it. These frameworks are often written in a higher-level language than C++ and can usually run on top of an RTOS.
Frameworks like mbed and microPython are a good way of getting started if you want to get down to device development without installing a single program. However, if you’re going to create bigger deployments, a pure RTOS would be a better option. Non-commercial solutions like FreeRTOS or RIOT have the edge if it’s easier for your company to do the software investment using work hours rather than money. If your company can afford the up-front investment, commercial solutions like Segger, Express Logic, and Micrium would greatly reduce your software development risk and time-to-market. Of the commercial solutions, what sets Micrium apart in particular is their stable and certified code base, wide spread deployment, good part support, open source code, and a business model that will suit most wallets.