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.
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide