Over the past few years, the use of open source software in embedded systems has become mainstream. In part, this is due the sheer necessity: Systems just keep getting more complex, incorporating more and more functionality, but design teams aren’t getting larger, and code-writing productivity isn’t improving dramatically. In many cases, this means that the role of embedded software developers has shifted from writing code to integrating components—but finding the needed components can be difficult indeed.
For example, a couple of years ago BDTI was hired by a system design company that was developing a type of tablet computer. The company hired BDTI to help select the best processor for its design. It was a tall order: a succinct list of required features went on for pages, and of course the system had to be small, inexpensive, and low power. Initially we thought the hard part would be finding a processor that delivered enough performance. But we quickly discovered that in reality the hard part was finding a processor that came with most of the necessary software components.
Open source can be a way to help address the growing gap between needed software components and available software components. And the best open source software has been getting steadily more sophisticated and robust. But whereas there are numerous open source operating systems, network stacks, GUI builders, and the like, open source software for digital signal processing has seemed to lag. Multimedia is one bright spot; there are open source codecs such as FFmpeg and x264, and the GStreamer application framework. But open source general-purpose signal processing function libraries, for example, are hard to find.
Is it time for this to change? I think so. Back in the early days of DSP processors, chip vendors differentiated themselves on the amount of proprietary software available for their processors. Texas Instruments, in particular, prided itself on the size of this “third-party developer” network—a set of companies offering optimized DSP software components for TI (and sometimes competing) chips. But as applications became more complex, this model started to show strain. Developers of complex systems weren’t happy about having to deal with five or ten different suppliers to get all of the software components they needed. So TI and its competitors began to bring those software components in-house. When TI introduced its DaVinci multimedia processors in 2005, it bundled together over 20 speech, audio, image, and video codecs, providing one-stop shopping for many of the most commonly used software components.
But it’s becoming very difficult for chip vendors to keep up with customers’ ever-growing demands for software components. Open source software is not a silver bullet, but it can certainly be part of the solution. These days, embedded processor vendors are increasingly differentiating themselves based on the amount and quality of open source software available for their chips. This is a legitimate strategy, but one with its own challenges.
For one thing, much open source development is done by unpaid volunteers who relish technical challenges and enjoy having their work used. This means that developers may not be interested in developing the components that chip companies most need. Another challenge is ongoing viability. For an open source project to be really successful, it needs a critical mass of ongoing development activity. Many open source projects are short-lived. Even if the code is solid, without ongoing maintenance and enhancements, it’s unlikely to be useful for commercial applications. Likewise, having many different open source packages offering the same functionality can be counter-productive.
So, how can chip vendors harness the creativity, talents, and energy of open source developers? I think Texas Instruments has provided a good example with the Beagle Board, its low-cost development board. By providing a very useful and inexpensive board—and making the board design itself open-source—TI has engaged the interest of open source developers. TI also seems to have found an effective middle ground—supporting, organizing, and encouraging open source developers, without trying to dictate their direction.
In the end, open source isn’t going to deliver all off the off-the-shelf software components that embedded developers need. But as the required set of components continues to grow, open source code can be a useful complement to software developed by chip companies, by chip companies’ commercial software partners, and by system developers themselves. As a result, chip companies that are able to constructively engage the open source community stand to reap a significant competitive advantage.
What do you think? Post a comment or send me your feedback at http://www.bdti.com/Contact. I’d love to hear from you!
Add new comment