Making embedded processing development easy

by Henry Wiechman , TechOnline India - August 10, 2011

Welcome to a six-part series on “Making embedded processing development easy.” Over the next six weeks, we’ll introduce you to considerations to aid with embedded processor design.

Welcome to a six-part series on “Making embedded processing development easy.”  Over the next six weeks, we’ll introduce you to considerations to aid with embedded processor design.  This series is derived from the expertise of embedded processor software experts from Texas Instruments (TI) and is meant to provide an objective view of easing software design. 

This week’s edition is brought to you by Henry Wiechman, software product manager, embedded processing, TI.
 
Q:  I’ve not spent a lot of time developing in an embedded processing environment.  How should I get started with this?

A:  Embedded development is not as complex as some perceive.  In fact, some of the most advanced development kits can be evaluated in minutes, and full installation and development can be underway in less than an hour.  The first question you need to ask yourself is, “What level of differentiation do I expect to achieve from software development on this project?”  Based upon your level of experience and the goals of your end product, you may be able to obtain nearly all of the required software from the semiconductor vendor or a third party with only minor modifications.  Or you may have to develop new algorithms yourself or with partners to truly differentiate your solution.  With an understanding of the level of development required to achieve your desired differentiation, you’ll be able to better grasp the factors and decisions you’ll need to make to drive your design. 

For example, the amount of differentiated software development a project requires can have an impact on the product’s time to market and price point. And both of these factors will affect the decisions made by the software development team regarding use of an operating system (high-level, real-time or none at all), the
type of development tools and integrated development environment (IDE) adopted for the project, whether open source or commercially licensed software
components will be integrated into the system, and many others. Without the
solid foundation of a thorough understanding of the project’s goals, such a list

of software considerations, software development can be overwhelming.

But, before we get ahead of ourselves, embedded software design must first begin with the type of processor you select. Considering there are microprocessors and microcontrollers with a variety of proprietary and industry licensed CPU architectures, some with coprocessors for special functions or applications such as audio and/or video compression, image or signal processing, as well as stand-alone digital signal processors and other specialized processors, all with a variety of memory and peripheral interfaces, you’ll have to discover which of these options best meets your needs. 

After the evaluation of the power, performance, peripherals, security and other important features of the device you select, you need to ensure the hardware you select has adequate development tools and software to easily begin development at your desired level of differentiation.  Software development is greatly impacted by the types of tooling available for a processor. As a result, the starting point for the typical embedded processing software development project is usually the tools and other types of resources that the development team will employ.

Key elements and considerations for beginning your embedded design:

Integrated development environments:

Integrated development environments (IDEs) have become quite prevalent in the software design industry. An IDE will gather a number of tools into one environment. Learning the multiple tools that will be required is simplified since the tools in an IDE usually share the same user interface, naming and command conventions, and other aspects of their overall operations. Moving data from one tool to another should be easier and more intuitive.

Unfortunately, not all IDEs are created equally. Most probably have the basic code generation tools for assembling and compiling software, but the performance and code size of the generated code can vary greatly from one vendor to another.  More complete IDEs add features to speed development and improve debugging through increased visibility of the code under development.  Greater visibility enables faster and more efficient code development by programmers.  The tools in some IDEs may not be as tightly integrated with each other as they are in the more functional IDEs. If the transition from one tool to the next is very time consuming, the efficiency of the entire software development process can be adversely affected.

The software development team could decide to adopt an open source IDE or a commercially available environment.  An IDE developed and supported by a single vendor may be limited by the amount of support the vendor devotes to it. Some vendors have chosen to base their IDEs on an open source environment such as Eclipse, which has been developed and is supported by the non-profit Eclipse Foundation.

Funded by membership dues, the Eclipse Foundation oversees the evolution of the environment and its ecosystem of open source resources. Several leading
technology providers have adopted Eclipse as the basis for their IDEs. For
example, Android tools from Google are based on Eclipse, as is Code Composer

Studio IDE from TI.

Development Boards:

Chip vendors often provide development boards or evaluation modules (EVM) either directly or via third-party developers to jump-start software development.  These EVMs are most often accompanied by free software and can be utilized with an IDE.  Most EVMs are comprised of a small printed circuit board (PCB) incorporating the device or devices that are being evaluated and a modicum of software resources. The software resources supporting an EVM can vary greatly. EVMs with more comprehensive software support are able to be set up quickly, enabling designers to experience a demonstration soon after the EVM has been removed from its box, and include all resources necessarily to start embedded systems development. The more complete EVMs come with access to code libraries and support for high-level operating systems (HLOS) such as Linux, Android or Windows Embedded CE.


• Software Development Kits:

Most times, hardware vendors provide some type of software development kit (SDK) free of charge with their EVMs.  The baseline components in an SDK are usually a board support package, including drivers for an operating system, and a code generation tool.  The more extensive SDKs can resemble a complete software reference design for a particular application. With this type of SDK, many of the constituent parts of system software, such as extensive input/output stacks for USB, PCI Express, and Ethernet, a multimedia framework with a long list of audio and video codecs, graphics libraries, and application examples such as video decoding over Ethernet, will already be in place. In this type of scenario, the software development team is able to focus on the development of their differentiated application software and its integration into the system and will often be able to create an initial prototype quickly.

The downside of an extensive SDK or reference design like this is often limited access to source code for the underlying components.  Without such access, modifications and customized improvements to the components are not possible and the level of differentiation that is possible in an end product may be limited.

Top-level applications created by a developer may be difficult or impossible to integrate if application programming interfaces (APIs) are too limited and cannot be changed.  In contrast, an SDK made up of more source code can afford developers the opportunity to modify and customize the code, as long as the licensing agreement grants developers the right to do so.

An SDK that would enable easy customization should also include structured and well- documented APIs at each level of the system software. An effective API will facilitate and simplify the programmability and re-configurability of the supporting software architecture. The API should provide ‘hooks’ at each layer of the system’s software so that developers can easily plug software modules into the system without having to write entirely new modules. This reduces software development time significantly and accelerates a new product’s time to market.

Next week, we’ll cover operating systems to help you understand whether one is needed for your system and which type (high-level or real-time) is best for your
design. And future topics include the pros and cons of utilizing the open
source community, multimedia and graphics development, as well as how to make
your software investments/code reusable for future product developments.

About the author:

Henry Wiechman is a software product manager in the embedded processing team at Texas Instruments.  He has served in a variety of product line and business management roles in TI’s catalog and emerging end equipment businesses.  Wiechman received his bachelor’s in electrical engineering from Kansas State University and his master’s of business administration from the University of Texas at Austin. He is a member of the Institute of Electric and Electronics Engineers (IEEE).


If you found this article to be of interest, visit the Microcontroller Designline where you will find links to relevant technical articles, blogs, new products and news.

You can also get a weekly newsletter highlighting the latest developments in this sector - just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register.


About Author

Comments

blog comments powered by Disqus