Anatomy of a Small Open-Source Kernel for DSPs


This article discusses dsp_K software, an open-source, real-time kernel and library for digital signal processors (DSPs). It covers both technical and historical ground, paying particular attention to the board support package (BSP) layer that is at the kernel's heart. I also address the use of open source within deeply embedded systems and hope to encourage you to consider such projects of your own, dsp_K-based or otherwise.

The source code and existing documentation that describes the dsp_K software can be found at the project home page. I also maintain a small collection of related bits, including some links to other DSP and Linux sites that you might find interesting (see Resources).

The purpose of the dsp_K project is to provide developers with a small real-time kernel suitable for DSPs, serve as an illustration of embedded open-source software, propose and implement an EL/IX profile for DSPs and serve as an exercise in porting pieces of Linux code to DSPs.

At the lower-most layer of dsp_K, the BSP aims to provide a set of runtime services designed to be as simple as possible and still constitute a functional software platform, while affording some personality. Staying small also makes it easier to port the BSP to other DSPs, while currently there is only one version for the analog device's SHARC family. Why the SHARC? Well, simply because that was the hardware available when I started the project. Actually, the term BSP is a kind of a misnomer because there is no specific board support; rather, the software can run on various boards. It might help you to think of it as a chip (family) support package.

The BSP can be sublayered, and at the bottom, sublayer 1-0 provides the minimal functional services required at runtime: interrupts including a PIT (periodic interval timer or tick) and basic task control and context switching (i.e., CPU sharing).

You can find the software that implements these functional services in the files dsp_Ki.asm and dsp_K.c. It may be useful for you to download them for reference as we go along.

Sublayer 1-1 consists of the kernel personality services, the main task functions and the scheduler sanity checker. This sublayer of the BSP personalizes the kernel, and the software that implements it is mainly found in the files dsp_Kt.c and dsp_K.c.

If you fancy starting a kernel-based project of your own, you can choose a personality other than tasks. For example, objects make your kernel be seen as an object manager but still use the functional sublayer below it. In fact, early followers of dsp_K could see such experimenting with the kernel personality through the dsp_MK (monolithic) and dsp_EK (experimental) kernels, now evolved into the layer 2 APIs monolith and process, respectively. It turns out to be constructive to present programmers with moderately different personalities through layer 2, based upon common kernel personality services in layer 1.

I will return to the nitty gritty of each of these sublayer BSP services later; now I want to introduce the second project objective. The dsp_K project is open source, which concerns both business and technical qualifications. As technical and open-minded people, we are sometimes asked by our professional colleagues how money can be made using the open-source model. It is a point we might discuss at length, but when asked (and with embedded systems in mind) I would probably start by suggesting good business might be made by providing proprietary products, service and support, complemented by development partnerships.

In the context of a dsp_K-based project, the benefits of a hybrid method of embedded software development for DSPs are simple to illustrate--proprietary applications also require the hardware on which they run, but the software kernel is a necessary nonprofit component for all concerned.

EL/IX and Linux

The third dsp_K project objective is to propose and implement an EL/IX profile for DSPs. EL/IX is a Linux-based, evolving open standard for embedded systems programming interface (see Resources). An EL/IX implementation is defined basically through a profile that identifies those POSIX components to be included. Through its wealth and profiles, EL/IX mainly targets processors with a rich hardware capability. But lesser profiles might also be provided for poorer cousins, like DSPs, which have a role in embedded systems. I hope that through providing an implementation, dsp_K can contribute to exploring the EL/IX specification for small profiles. We're registered as a nonelecting project on the EL/IX home page, accordingly.

The dsp_K software is designed to be a minimal application-specific embedded subsystem with no I/O, filesystem or network capability. Although it is possible to do otherwise, I recommend you consider functionally partitioning your dsp_K-based design to provide such peripheral functions elsewhere in your system architecture. A high-specification processor running RTLinux (see Resources), for example, can provide you with peripheral and user interface functions alongside a DSP running dsp_K (where the two could communicate using RTfifos).

In multiprocessor systems, and as engineers, we might think interoperability is key to good software design and would want to use a similar API across the processor subsystems. For this reason, the dsp_K project looks to EL/IX for guidance.

We live in interesting times with GNU/Linux real-time derivatives quickly being adopted by embedded systems designers. But there are many cases where embedding Linux doesn't make sense. You will undoubtedly have encountered Linux ports, like µClinux (see Resources), which is a subset for processors lacking MMU (memory management unit) support with reduced support in the programmer interface, such as fork. But being borne of x86 lineage, the Linux kernel weighs in heavily where we might consider ports to lesser devices like DSP cores. Sadly, it seems Linux is too rich for the SHARC and DSP cores in general (e.g., it would never squeeze on-chip in 10k RAM), so you can see why the dsp_K project does not attempt a Linux port.

How then, can the fourth project objective be satisfied? Well, Linux on a PC provides a handy program testing environment and good documentation in addition to making its source code available for reference. Linux also aims at POSIX compliance, which through EL/IX is a goal shared by dsp_K, so various components and supporting libraries can and have been ported (such as signals). From the embedded world, RTLinux has some useful modules that have been ported to dsp_K device drivers (namely fifos) that enable a host CPU to exchange data with a DSP across a dual-port memory interface. So, I like to say dsp_K satisfies the fourth objective by being Linux friendly.


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot