In this Product How-To article, TI’s Joseph Coombs describes the problems developers have in meeting the strict real-time requirements of embedded systems and how use of the company’s StarterWare set of lightweight OS-independent libraries and utilities will help in designs based on TI’s ARM, DSP and ARM/DSP processors.
Despite the widespread use of high-level operating systems and software in the embedded space, many developers must take a low-level, hands-on approach to meet the strict requirements of real-time systems. In extreme cases, even a real-time operating system (RTOS) may represent unacceptable overhead. Even in more forgiving applications, developers often need low-level software to facilitate using a full OS with a particular embedded platform.
StarterWare is a set of lightweight, OS-independent software libraries and utilities that enable bare metal development on TI’s ARM, ARM + DSP, and DSP-only embedded devices. This article will describe the contents of StarterWare and how they can be used for complete application development with minimal overhead and maximum hardware access. I will also explore how StarterWare can be used in conjunction with an OS to add functionality to an existing application without assuming complete control of the overall system.
The use of high-level software, including full-featured OSes and specialized algorithms, is increasingly ubiquitous in embedded development. In spite of this—or even because of it—access to good, low-level software development tools remains a critical concern.
Even the most sophisticated application relies on a solid foundational layer of software that directly accesses the underlying embedded platform. Conversely, the most demanding embedded applications cannot accept the overhead associated with high-level software stacks; in this case low-level or bare metal software is the only option.
Whether due to tight real-time processing constraints or the simple need for an intermediary between high-level software and embedded hardware, all embedded devices require bare metal software support that satisfies a few key requirements.
First and most obvious, the software must provide direct access to hardware functionality such as CPU interrupts and peripheral I/O with minimal overhead and simple, C-language APIs.
Second, it must minimize its own memory footprint and be modular such that individual developers need only use the bits and pieces that they require. Finally, it must be OS-independent; the same software should be usable in embedded Linux device drivers and stand-alone, bare metal applications without any modification beyond a simple recompile.
One example of low-level embedded development software that meets these requirements is StarterWare from Texas Instruments (TI). TI and other embedded processor vendors commonly provide low-level device support packages, but StarterWare is a new effort to provide a complete solution for more complex system-on-chip (SOC) devices. The contents of the StarterWare package are summarized in Figure 1, below .
The device abstraction layer (DAL) provides support for peripheral devices as well as CPU features including cache management and interrupt handling. Additionally, StarterWare provides protocol stacks for complicated peripherals so that bare metal applications can perform high-level actions, such as enumerating a USB device or rendering sprite fonts to a display peripheral, all without resorting to cumbersome, high-level software stacks.
StarterWare also ports and makes use of open source software, such as the lwIP network stack, where appropriate. Devices supported by StarterWare include ARM-only, DSP-only, and DSP+ARM SOCs. In the latter case, full support for all features is provided for both cores, and lightweight inter-processor communication (IPC) is also included.
Finally, StarterWare provides copious examples showing the use of its various software components. We will examine one of these examples to illustrate how StarterWare can be used to develop standalone, no-OS applications.
Using StarterWare for Bare Metal Development
The “demo” application included with TI’s OMAP-L138 DSP+ARM processor release of StarterWare is a bare metal application that showcases most of the features StarterWare has to offer on that device.
This application makes extensive use of the components listed in the previous section: DAL for peripheral access (including UART, McASP, LCDC, and more) and interrupt support, the USB and EMAC protocol stacks, the graphics library for rendering text and icons, and even a simple utility library that provides UART console support.
The end result, as shown in Figure 2 below , is a bare metal application featuring a simple graphical user interface reminiscent of an application running under a full OS.
Figure 2: Screenshot of OMAP-L138 StarterWare “demo” application
All of the services used by the application—interrupt support, graphics display, USB and EMAC negotiation, and more—are provided by StarterWare and built in to the application itself.
The application entry point jumps directly to the main function; there are no hidden layers or initialization beyond the application source code itself and the standard runtime support library provided by the compiler.
Simple StarterWare APIs register ISRs and handle all peripheral I/O as well as performing more complicated tasks, such as negotiating an IP address on the local network.
Because of this, the complete embedded system is very easy to understand just by looking at the application source code. The overall application flow is illustrated by Figure 3 below.
Obviously, by foregoing the use of an OS, this application also foregoes some of the conveniences afforded by a more high-level approach. There is no local filesystem, so all necessary binary data—including image files and HTML content served by an embedded web server—are “baked in” to the application source and header files.
Additionally, there is no scheduler overseeing the application during execution; instead, there is only a main loop periodically interrupted by calls to various ISRs. This approach is perfect for some embedded systems, but other systems may need these additional features. For that reason, we will consider another application that uses StarterWare in conjunction with an OS.
Using StarterWare for RTOS Development
The second example application that we will consider is also an OMAP-L138 DSP+ARM processor-based application using StarterWare. This is a more focused application; instead of lightly using a variety of peripherals and software components, it uses just a few peripherals and intensive analytic algorithms to perform face detection on an incoming video signal. The output image—the input image with an overlay surrounding the detected face—is then displayed on an LCD screen.
These are significant differences from the previous example, but the most important change is that now StarterWare is just one component of the overall application. The new application is built around the SYS/BIOS RTOS kernel, which handles CPU features such as cache and interrupt support and also provides scheduling services to enable multi-threaded application design.
Using an RTOS has a significant impact on the overall application and how StarterWare can be used. A great deal of the application logic and initialization is hidden away by the RTOS; it's not as easy to follow the application flow just by examining its source code.
The application makes use of RTOS functionality to split its processing into multiple independent threads and ISRs, all of which are managed by the SYS/BIOS scheduler. This is an important change for the overall application and the primary benefit that our previous bare metal application didn't enjoy. The RTOS application flow is illustrated in Figure 4 below.
Since responsibility for interrupt support is assumed by the RTOS, StarterWare is only responsible for handling peripheral access. The various StarterWare stack libraries could also be used, but our face detect application uses only the low-level DAL components. In essence, StarterWare serves as driver code for this application.
This comparison could easily be taken a step farther: StarterWare could serve as the basis for OS-specific driver libraries for use with multiple applications. This more indirect approach would be preferred in an application running under a full OS, such as embedded Linux, which disallows bare metal code in “user” applications.
Clickon image to enlarge.
Using StarterWare to develop device drivers for full OS development is beyond the scope of this article, but Figure 5 above shows some of the differences in system partitioning between full OS applications and our example cases of bare metal and RTOS systems.
StarterWare provides a rich set of libraries and utilities to enable bare metal development on specific SOC embedded devices from TI. These tools can be useful either as the basis for developing complete OS-free applications or as smaller parts of OS-based applications. In this article, we explored how StarterWare is used in two separate example applications showcasing bare metal and RTOS application development.
StarterWare is currently available as a stand-alone package targeting OS-free development, but efforts are already underway to include it in software development kits (SDKs) targeting the SYS/BIOS RTOS kernel.
Additionally, while StarterWare already supports current TI devices such as the OMAP-L138 DSP+ARM processor and the Sitara AM3359 ARM microprocessor, development is ongoing to improve those releases and extend support to future TI SOCs. The embedded space is home to an incredibly diverse set of applications with widely varying features and demands, but StarterWare is a powerful tool that has a place in every embedded developer's toolbox.
Joseph Coombs is an applications engineer at Texas Instruments for the TMS320C6000 Digital Signal Processor (DSP) business, responsible for development, documentation and technical support for StarterWare for DSPs and the C6EZFlo graphical software development tool. Coombs also contributes to other DSP software projects, including the ongoing effort to port the OpenCV library to C6000 DSPs. He received a Bachelor of Science in electrical engineering from the University of Tulsa and a Master of Science in electrical and computer engineering from the University of Illinois at Urbana-Champaign.