Tackling Linux size, modularity, and GPL issues

Smaller processors including digital signal processors, microcontroller units, and digital signal controllers have until recently not been able to get around Linux modularity, size, and GPL issues, but operating systems which have come on the market recently are addresing these concerns.

Consider a system with one or more Microprocessor Units (MPUs), Microcontroller Units (MCUs), Digital Signal Controllers (DSCs), (DSPs), or at the core, with some functions in hardware and some in software. We will also assume that software drives the main I/O components and that some sort of control software is required. 

Architecture options for the aforementioned processors could include:

·        Single loop of control

·        Proprietary kernel

·        Open-standards-based kernel

·        Proprietary RTOS (kernel with I/O model, documentation, testing, and the like)

·        Open-standards-based RTOS (GPL)

·        Open standards based RTOS (GPL free)


The first case, single loop of control, is very straightforward.  If the system has a single external event to handle, this works well.  A second event may be possible, but past this maintenance is compromised.

The cases of proprietary kernels and proprietary operating systems are very similar. Their proprietary nature leads directly to lock-in to a specific vendor.  Of course, many vendors favor this, but proprietary kernels and OSs substantially limit future architectural choices, driving up costs and reducing profits.

Open-standards-based software architecture

We’ll consider open-standards-based solutions involving a kernel or complete operating system together because one is a subset of the other.  Once limited to larger processors, open-standards-based solutions today support MCUs.

Although many POSIX-compliant systems and even Windows-based versions are essentially standards-based, the clear trend today is to use , the de facto standard.  It offers millions of lines of reusable code, embedded real-time options, and a huge selection of I/O (see Figure 1).  

Figure 1: Software architecture options


MPUs and MCUs with MMU

Larger Memory Management Unit (MMU)-capable processors typically use the .  This choice allows application developers to avoid GPL licensing.  They don't have to share their applications with others, yet these developers can bring to market solutions that benefit from open standards and community development.

Often, on larger MMU-capable processors, there is a push towards . By running legacy operating systems in conjunction with Linux, application redevelopment can be avoided and costs reduced.  This is an often-used migration approach for very large systems.

DSCs, MCUs, and DSPs

Typically DSCs, MCUs, and DSPs don't use an MMU.  For this reason, GPL causes problems for developers. They certainly don't want to give their applications to their competitors. The large size of Linux, its lack of modularity, and GPL concerns have made Linux and Linux variants nonstarters on DSCs, MCUs, and DSPs until very recently, with the introduction of an ultra-tiny pair of operating systems offering modularity, a GPL-free license, open source, and 100 percent Linux and POSIX compatibility for these smaller processors.

DSP pipeline best practices

The core approach to building a DSP pipeline (see Figure 2) in software rests on the following:

·        Build a zero copy DSP pipeline.

·        Allow threads to implement elements of the pipeline as components.

·              Use message queues as inputs and outputs and pass only pointers.

·        Use fixed-size buffer managers, which can be used by any thread.

·        Implement standard algorithms, which receive an initialization message, get blocks of data from the input queue, process in blocks, and post the results to the output queue, managing buffers as required.

·        Allow all threads to run at a priority that works for the system, typically with the I/O-related threads as the highest priority.

·        Output to and input from acceleration hardware such as FPGAs and ASICs to optimize the use of hardware in signal transformation.

Figure 2: DSP pipeline elements

The core building blocks for optimal standards-based DSP component implementation on the software side are: threads; initialization messages; queues for input messages; queues for output messages; ISRs; and fixed-size buffer management. On the hardware side the components are:           FPGAs; ASICs; and Special DSP/DSC/MCU accelerators.

Figure 3 shows a standard software component with its inputs, outputs, and buffer management.

Figure 3: A standard software component with inputs, outputs, and buffer management

Looking at the details of the POSIX- and Linux-compatible features that optimal system-level implementation requires, we see first that message queues with a queue of pointers to buffers is ideal. Ownership of the pointer to the buffer gives ownership of the buffer, and it can be easily passed if required. 

Next, each thread should have an initial message that configures the processing. For example, the initial message will specify the input and output queues, parameters such as coefficients, algorithm details or options, and necessary buffer pools.

Third, fixed-size buffer managers for getting a buffer and freeing a buffer callable from Interrupt Service Routines (ISRs) are key.  Fixed-sized buffer managers allow the components to manage buffers without overhead.  The ability to manage buffers in ISRs eliminates any buffer copying.

Fourth, priority-based thread scheduling assures critical components in the pipeline are processed in the correct order to maximize throughput. Often buffer shortages occur, and temporary data surges should not harm system results.

Fifth, ISRs handle I/O at the end of the pipeline or midway in the pipeline if external hardware is used to accelerate processing.  In the case of external hardware, two ISRs would be used; one to send the data out to the external accelerator and the second to input the processed data.

Message queue post from ISR and message queue try/receive from ISR must be present to ensure that the ISR can get a buffer, fill it, and then pass the data on for processing without copying.  Similarly, an ISR can get an output request from the queue without blocking.

DSP pipelines, POSIX, and Linux

The best practices for and software architectures and DSP pipelines indicate that implementation of DSP pipelines on POSIX or is not only possible, but a one-to-one mapping.  The only calls that are not 100 percent POSIX and Linux compatible are the fixed-size buffer allocators. These allocators can be implemented using malloc or free  subroutines in  ways to make them 100 percent compatible as well. 

No MMU restriction

With regard to  compatibility of DSP pipelines with POSIX and Linux, there is no restriction regarding the MMU. Applications can be developed on Linux- or POSIX-based systems and then ported from one to another.

Using a broad set of Linux- and POSIX-compatible operating systems on processors with MMUs is possible.  As long as the operating system has basic POSIX calls as outlined earlier, the application can be programmed and quickly and easily ported to other systems.


Larger vendors involved in DSP and implementations offer both a proprietary offering and (typically) a Linux offering.  Proprietary offerings try to lock customers into a particular set of chips, and the Linux options can be moved to many different underlying hardware architectures.   With smaller chips, typically there is no operating system.

The choices for implementing standards-based DSP pipelines as components are limited to Linux- and POSIX-compatible operating systems on MPUs or MCUs that have MMUs. 

For DSCs, DSPs, and MCUs, the DSPnano (8-bit/16-bit) and Unison (32-bit) operating systems from RoweBots are examples of OSs that offer the benefits discussed earlier.

Kim Rowe has 30-plus years of experience in business management and systems engineering and holds both an MBA and an MEng. He has been instrumental in the startup of several companies and several business units in the computer systems and services areas. Kim has extensive international experience, having taken a broad set of software and hardware products to market in more than 20 countries. Overall, Kim's focus has been as a technical leader in real-time and embedded systems, software engineering, and signal processing with a goal of maximizing profitability and minimizing time and risk. He has published approximately 35 papers and articles in various journals and magazines and has a collection of industry firsts to his credit.