For folks who write code professionally, the process of evaluating "other people's code" might seem simple – but it takes more than reading a manual or inspecting source modules. Properly evaluating choices and their long-term impact means looking at various options with a new, broader perspective. Here is a list of do/don't guidelines that can help in the search for more reliable software.

With pressure on embedded designers to produce billions of reliable devices for the Internet of Things, the approach to hardware and software development is changing. The days of picking a part, grabbing a manual, and sitting down to write code are coming to an end – not because of the difficulty, but as a result of the time involved in doing so. By the time a designer with the old approach gets the basics working, competitors might have already released their finished product.

Changing development practices are further spurred by innovation, which is a two-edged sword. More new microcontrollers and FPGA processor cores are being created and introduced in 32-bit ARM architecture every day, bringing more processing power driving advanced peripheral functions many designers are unfamiliar with at a detailed level. This can be particularly tricky where interoperability requirements dictate thorough testing of peripherals, essential for reliable connections of devices with other devices under all operating scenarios.

In this new landscape where user expectations are high and processing technology is evolving rapidly, unlocking the potential for new devices requires better software that can be produced more quickly. Successful teams, building on the model of reusable hardware Intellectual Property (IP), are now pursuing a build-borrow-buy strategy for each block of software IP. Code can be developed in-house, borrowed from the open source community, or purchased from vendors, with everything blended into a solution (Figure 1).

Do’s and don’ts of evaluating software

Beyond specific functional and performance requirements, how should software IP blocks be evaluated? Following are some do/don’t guidelines for teams applying a build-borrow-buy approach.

DO: Consider the entire software stack

The range of 32-bit embedded software IP is much broader than just compilers and debuggers from the 8- and 16-bit world. IP exists across the spectrum including operating systems, protocol stacks, user interface code, and middleware. Choices of operating system and Application Programming Interfaces (APIs) can enable or inhibit other choices, with implications in test, verification, documentation, and support over the life cycle of the product.

DON’T: Assume everything has to be written

Developers historically have had a code-first mindset, purchasing development tools, perhaps obtaining an operating system, and going to work writing the application. While this gives a team a great deal of control over the code, reusing or acquiring code from reliable sources can actually reduce risk, and definitely speeds up development. More and more off-the-shelf software solutions, especially in the context of ARM architecture, are being created and deployed.

DO: Look for code conforming to specifications

Difficult-to-code peripherals and functions usually fall into networking, user interface, and signal processing categories, with specifications that must be adhered to carefully for proper operation. Obtaining code in areas such as Bluetooth, TCP/IP, USB, HTTP web servers, graphics, and DSP libraries – proven in other applications – can make the difference in a project.

DON’T: Fall into the open source value trap

Open source is often a great starting point; a good example for ARM is the Linaro efforts in Linux for the Cortex-A families. Developers should understand that effort will likely be needed to port, extend, and verify the open source code to complete the value equation. For example, the developer of BTstack – open source Bluetooth expert Matthias Ringwald – readily admits that it is a “minimal set of required protocols” on a limited range of processors and operating systems.

“There are short-term and especially long-term advantages for standards. Generally purchased Commercial Off-the-Shelf (COTS) software is a great place to find software that supports standards, whereas often in-house purpose-built software may be less oriented toward standards. Over time companies want to enhance products; by following standards there is a much greater likelihood that other hardware and software components will be available to aid future development.”

– Mike Gee, CEO of Motomic Software

DO: Be open to both object and source modules

Developers often require access to source code, based on a fundamental mistrust of “other people’s code” or a need to comply with a source-centric review process. However, having source code doesn’t necessarily make code any more trustworthy, or provide any more control over the outcome – but it can definitely increase the expense of a project. Object modules proven in fielded applications for self-contained functions can be highly reliable and cost-effective, and documentation can be provided facilitating reviews.

DON’T: Take licensing for granted

Licensing is a hotly debated and highly misunderstood subject. Many engineers don’t even believe there is an issue, suggesting stories of problems with licensing embedded code are urban legends. In an age where lawsuits are flying between mobile manufacturers and the validity of patents for common features is under intense debate, not paying attention to the licensing of IP up front can be a huge and costly mistake. Proper licensing protects both providers and consumers of IP.

DO: Abstract code to APIs where possible

One of the keys to getting the most out of a build-borrow-buy strategy is to work with APIs, abstracting the interfaces between IP blocks. This has two effects: It prevents creating dependencies on implementation-specific code inside a module, and it allows IP blocks to be swapped out as needed for future projects with changing requirements. Another consideration often overlooked is competing timelines in system architecture, where multiple implementations of a functional block are evaluated in parallel and the best approach chosen.

DON’T: Over-engineer to low-level requirements

The temptation to code is so powerful it often leads to a justification: Third-party code doesn’t meet every single one of the detailed requirements, so code must be developed in entirety. Certainly, if a major requirement is uncovered by open source or commercial code, or if a dramatic breakthrough in innovation for a particular feature is the objective, a module of code should be written. In the build-borrow-buy scenario, high-level requirements are well worth the effort, but low-level implementation specifics should be rethought to avoid limiting choice.

“The biggest error I have seen people make when deciding to build is they believe that it is not too difficult to write the code, and in some cases that is true. What they completely overlook is how much time and cost it takes to debug and test so that the software (in our case, TCP/IP and related protocols) works properly in every configuration and every network environment. Not only does this result in greater costs, but the projects are most often late, which results in lost revenue, maybe even a lost market opportunity.”

– Larry Larder, President of InterNiche Technologies

DO: Focus on core expertise of the firm

A key tenet of any build-borrow-buy strategy is focusing on distinctive competence, which should take the bulk of engineering resources and expertise. By focusing on the right in-house development and reuse or integration of open source or commercial modules, return on investment can be optimized. In fact, if a competence becomes outstanding, a block of software IP may become the standard for reuse, opening new opportunities for revenue.

DON’T: Try to do everything in-house

The flip side: Rarely is any company the expert in all areas required to make a complete product, especially as software becomes more varied and complex. The resistance to outside IP used to be jokingly referred to as NIH – “not invented here” – but savvy organizations are changing that mindset.

“Many companies try to go outside their expertise and stretch themselves to do everything in-house. Commercial IP licensing companies exist for a reason – they have their core expertise in specific areas and are able to do a thorough job of developing, testing, and deploying IP modules for use in end products. Ultimately, commercial IP enables developers with lower-cost, robust solutions; faster time-to-market; reduced troubleshooting; and fewer customer rejections.”

– Ashok Setty, CEO of SoftRISC Communication Solutions

Finding software to evaluate

Evaluating code from datasheets isn’t feasible for modules beyond trivial complexity – very little can be gleaned about the quality of the implementation. Most engineers will head straight for the manual, evaluating it as a proxy for code quality, but documentation for many of the advanced microcontrollers is hundreds of pages of time-consuming reading. Evaluation code, coupled with a hardware development kit and perhaps even training, can quickly answer questions and move the process forward.

Not only that, the 32-bit ARM ecosystem provides unifying structure making the search for code easier, and has made the Embedded Software Store (www.embeddedsoftwarestore.com) the primary destination. Many products are available in evaluation versions, with prepackaged configurations and one-click licensing making finding and acquiring code quick, easy, and safe.

Willard Tu is Director of Embedded for ARM, and is based in Detroit, the automotive capital of the world. Willard has focused his career on the embedded market segment, accumulating more than 20 years of knowledge. He has worked for Motorola (Freescale), National Semi (TI), and NEC Electronics (Renesas) in business development roles, and has spent the past six years growing ARM’s embedded market share.

Embedded Software Store www.embeddedsoftwarestore.com

Follow: Twitter Facebook Google+ LinkedIn YouTube