Choosing the Right Software Framework for Your Design

Software Framework

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.

Operating System

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.

Commercial vs Open-Source Solutions

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.

The Candidates

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:

Operating Systems

All the operating systems mentioned in this chapter are real-time capable (RTOS).

Commercial Solutions

• Micrium uC/OS-II and uC/OS-III: These are two of the most popular RTOS in the MCU industry, particularly because of their innovative business model. Micrium allows you to download the full software suite and start developing, and you only start to pay for the solution when you actually have started generating revenue. They have a strong presence in safety-critical systems and most of their software components are well-certified

 

• Segger embOS: A newer entrant to the embedded software market, they aren’t novices by any means. The software products have been developed over the last 20 years to be used in their own hardware products, so the device support is very good and comes with an excellent driver library.

 

• Express Logic ThreadX: Founded by industry veterans, this company is all about performance and squeezing every last clock cycle out of your components. It is often seen as the Rolls-Royce of operating systems and has a lot of certifications for use in safety-critical systems.

Open-Source Solutions

• FreeRTOS: FreeRTOS, along with Micrium uC/OS, is one of the most adopted RTOS’ in the industry. It has a large community of people contributing software like TCP/IP stacks, but being open-source means there is no company that oversees the integration so it requires more work to create an integrated solution

 

• Relating to the FreeRTOS ecosystem there are some companies that specialize in bringing differentiated software components to customers that need help with integration. For example, Wittenstein High Integrity Systems delivers a safety-certified FreeRTOS replacement core called SAFERTOS and HCC embedded delivers USB, Ethernet and file systems that can work with any RTOS.

 

• mbed OS: mbed OS is solving some of the pain-points that you typically get with open-source software, as there is one company; ARM, that is responsible for the integration. It is however still in its nascent phase so only go here if you want to contribute.

 

• RIOT OS: RIOT OS is branded as “the friendly operating system for the internet of things” and is an operating system built from the ground up around the concept of communication. This allows it to be compact and efficient even at difficult communication problems. It is however still in active development, so plan on spending a couple of hours debugging.

Frameworks

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.

• mbed. mbed shows up here as well, this time as a rapid prototyping project. It is written in C++ and has great support for most MCUs and boards, a great component library, and a nice web-based IDE. Currently it still needs a bit of maturity before it’s ready for full-scale deployment, but it’s great for prototyping hardware.

 

• Espruino. Espruino is a live JavaScript interpreter that runs on an MCU. This allows you to change the code on the fly and write code without ever flashing the MCU. Still some time to go before it is production ready, but it is great for hardware prototyping and shows great potential for becoming a software framework to be reckoned with.

 

• microPython. microPython does much of the same as Espruino, only using Python instead of JavaScript. It is developed from the start that you should be able to take these products to production with support for precompiled code and using C-code to write timing-critical code. Still in development.

 

• microEJ. microEJ is a Java based framework that allows you to easily build good-looking graphical applications for your device. It is already used in several smartwatches and other IoT devices.

Summary

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.