Electronic Design

Linux Is A Great Prototyping Tool For Embedded-Hardware Designs

Try Developing Your Hardware And Software In Parallel By Taking Advantage Of A Public-Domain Operating System.

To stay in business, manufacturers of embedded hardware must constantly develop new products. But many designers don't realize that the process can be sped up by taking advantage of an operating system (OS) that's in the public domain—Linux.

With Linux, any hardware manufacturer can create board-support and system-support packages that can be freely shared with partners early in the development cycle. This expedites support for new hardware. Moreover, the popularity of the Linux OS is expanding daily in many different organizations around the world (see "Linux: From Academics To The Real World,"). Here's a firsthand account of some efforts along those lines.

For hardware designers like Motorola Computer Group (MCG), Linux is a boon for obtaining software for constantly changing embedded-hardware platforms. To make these new embedded-hardware platforms fully functional, software (e.g., OSs, firmware, communication software, or enabling tools) must be optimized for the new hardware to show off its capabilities and power. The problem is getting software running on the hardware as soon as the hardware is released. The sooner a customer can use the hardware with functional software, the quicker it is adopted. This, in turn, lets an embedded manufacturer ship hardware in volume sooner—beating its competition to market.

Linux supports a number of microprocessors, such as PowerPC, 68k, and Intel. It also works with multiple bus architectures—VME, PCI, CompactPCI, ISA, and others. Device drivers are readily available for numerous ancillary chips and hardware cards. Using Linux, hardware manufacturers can share early-access hardware, plus prototype or proof-of-concept software, with customers and/or partners without any concerns about software licensing. By sharing this prototype code with real-time-kernel or software vendors, the process of supporting hardware is streamlined. Therefore, when new embeddable hardware becomes available, early-access software is available at the same time. Released software, then, shortly follows.

This article describes how MCG plans to use Linux as a proof-of-concept tool on our new high-availability (HA) CompactPCI-based systems. (HA systems are defined as systems that are running 99.999% of the time.) With the help of MCG's partners, this should provide customers with a total hardware and software solution.

Currently, typical hardware manufacturers need to offer customers solutions that contain hardware and software developed in a sequential process (Fig. 1). The embedded hardware is designed, developed, prototyped, and tested prior to having any software run on it. Re-spins and modifications continue to delay the hardware's final release, which then holds up the software development. Once the hardware is available for alpha and beta testing, software providers (including third-party software companies or hardware manufacturers' software divisions) receive samples for porting software to the device.

As the hardware changes, new hardware is given to the software developers, who adjust their work. After the hardware's final release, the software providers rewrite their projects, perform final testing, and release the software product. The software provider may considerably modify it between the first and last revision, depending upon the changes made to the hardware. The software may be released three to 15 months after the hardware is available.

Of course, the embedded-hardware manufacturer can't sell many hardware devices without the software. Consequently, sales are slow until some software is available. Yet hardware developers want software to be readily available as soon as possible to drive hardware sales. Time-to-market is the key to survival in today's fast-paced high-technology world.

MCG is trying a new method to develop hardware and software in a more parallel process to allow customers the opportunity to use the hardware with some software sooner. The concept is to produce hardware and software simultaneously, and then provide sample hardware with sample software as quickly as possible to third-party software providers and customers (Fig. 2). We believe we can do this using the Linux OS and speed up the process of developing software on new hardware.

When the hardware designers decide on the particular chips needed for their devices, the software engineers can find the appropriate Linux drivers on the Internet. As new chips are developed, drivers are written and placed on the web for use by engineers worldwide. It would be in the best interest of chip manufacturers to ensure that drivers are available. As the hardware is being designed, laid out, and prototyped, the software engineers assemble, write, and test the various drivers in Linux. Many of the drivers are available in source form. In that case, the software engineers could optimize the driver for their particular application. Software components can be integrated to some degree without running hardware.

Linux offers the hardware designer many advantages. The good news is that you get the powerful software and the source code. The bad news is that you, and engineers via the web, support the source code. The initial cost of the software is essentially free. Most versions are available on the web for the cost of download, and CDs can be ordered for less than $100. Plus, you don't have to pay for ongoing royalties for deployed products. The cost, though, comes from ongoing support. If you have a bug in the OS or in a driver, you have access to the source code to make changes. If you can't fix it, you can post your problem on numerous web sites around the world, and someone will help you out. There's a lot to be said for having a number of eyes looking at the software code.

Many hardware developers and customers like to have complete control over the source code. With this, engineers can make the software compact, efficient, and optimized for a particular use. This is extremely helpful for products that have long lives—that is, those that have revision-locked software for more than five to 10 years. You, the hardware designer or user, have complete control over your software product. The disadvantage is that you're also responsible for your own product.

When boards are available, the hardware debugging occurs. The debugging process isn't only testing the physical components, however. Now, software can be run on the device. This may require you to build more prototype devices to allow more people to test it. Software drivers in Linux and the new hardware are debugged simultaneously. An added benefit is that the software may find problems with the hardware that would normally not be found until the hardware is in production, and vice versa. The next hardware revision should be stabler due to simultaneous hardware and software testing. Sharing the sample code written in Linux is easy and royalty-free.

The re-spun board may become a beta or even a final release product, but it's now ready for testing and use by software partners and customers. When these early-access people receive hardware, they receive Linux software that runs on the product. The third-party companies can use the developed Linux code as a template. For example, the real-time-kernel vendors can view the source code in Linux, and determine how software interacts with the hardware. Seeing live code in source form is better than just looking at documentation describing the product. By studying the template code, the new-software designers can better understand how to maximize their projects to run on the new hardware.

How does this work in real life? MCG is writing sample Linux code to take advantage of our new HA systems. We're now sharing this code with select real-time-kernel developers, other OS vendors, key third-party vendors (both hardware and software), and with customers. The Linux code jump-starts their efforts, and they can turn out a marketable product faster. More software vendors can develop code sooner. Instead of just working with one OS provider and writing the software ourselves, we can work with a larger number of vendors and let them adapt, with our assistance, their software to the hardware.

Today, we're sharing Linux-based software drivers for our new hot-swap controller with select vendors. The hardware is patent pending. But to be useful, we must have software using this device. These partners are utilizing the Linux sample code to jump-start their efforts. Instead of simply sharing APIs or ABIs, we can offer working Linux software. This Linux code doesn't need to go through a complete "productization" cycle, because it's designed as a proof-of-concept tool. Software, then, is ready sooner. We're also finding that some customers are asking us to make our Linux code a product. They would then buy Linux from us and deploy with Linux-based products. This could be a large upside to our Linux efforts.

Our hardware is now ready, but the software isn't there yet. We started the Linux work right before we released our first hardware product. We envisioned the software arriving in logical steps, allowing customers a chance to initially develop with it. Now these same steps are being accomplished by several real-time-kernel vendors. As the hardware evolves, the software under Linux will be ready soon after the prototype boards come from the labs. Then, our partners can see some software running on the boards and system prior to the hardware's final release.

Once we have OSs on the hardware, we'll need communication software and enabling tools. Also, because of our new HA system, we'll have to teach some software providers—third-party vendors and customers—how to write applications that can take advantage of the new HA features. Again, we plan to write sample Linux code for these partners and then share it with them.

As the software becomes freely available under Linux, more developers will look at, examine, and critique the code. Additional people will add features and correct bugs, too. This will result in a stabler software product and more efficient code. Also, software will be produced more quickly.

Instead of writing code specifically for one RTOS, we're writing Linux code and sharing it with five to 10 times as many software companies. These firms then support our new hardware and features. The end result is that our customers can start developing sooner with hardware and software that has been designed together.

Our process is sparking a revolution within our company. We're now considering offering all of our board-support and system-support packages with Linux to our partners and customers. Software and hardware engineers can work closely on debugging and producing more efficient products.

A side benefit will be for us to use Linux in our factory as part of our testing on the assembly line. Since the Linux code was produced in conjunction with the hardware, hardware tests with software can be readily available. The software moves from the lab to the factory to ensure quality products off the factory floor.

Another advantage is the cost of the operating environment. With Linux, the software is essentially free, but we incur the ongoing costs of supporting the Linux environment. Because we are constantly changing the Linux code for new hardware, the burden of supporting the OS, in addition to the proof-of-concept software, is minor. Our out-of-pocket cost for OSs should drastically decrease.

Using Linux as a development tool that follows the hardware-development process, we hope to produce better hardware and allow more of our software partners and customers to write software for our boards and systems more rapidly. So they can deploy a final solution sooner. That means they can sell their product faster. So can the hardware manufacturer.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish