![[INTEL NAVIGATION HEADER]](../../PIX/HEADER.GIF){kind=small}
The embedded PC can help reduce the time to develop embedded systems by simplifying or eliminating steps in the development cycle
Written by:
David Shear Senior Analyst
embedded systems research
The embedded PC, leveraging off of the ubiquitous desktop and notebook PC's, allows embedded system developers to reduce the time it takes to get a product out the door. Though the embedded PC is not appropriate for all embedded systems applications, many systems can benefit from the reduction and possible elimination of development steps. The reduction or elimination directly impacts development time.
Claims of reducing the time to develop embedded systems have been around since the first microprocessor was programmed. Most of these claims are long on promise and short on reality. The embedded PC will not reduce all development times by some huge percentage, but it can significantly reduce the time to develop many embedded systems. In some cases, it can completely eliminate almost all of the traditional development steps.
This article investigates the impact of the embedded PC on development time. Many in the industry have been feeling the pressure to develop systems in ever shorter times. The 1995 Embedded Systems Survey Report found that the median time to develop an embedded system is 7.5 months. The same report revealed that this median is expected to shrink to 6 months within 2 years. Even more startling is that within 2 years, 20% of developers feel that they will have only 3 months to develop a product. The most direct way to reduce time to market is to cut as much out of the development process as possible. If you don't have to do something, you have saved time. One advantage of the embedded PC is that many of the steps normally associated with design can be skipped.
Figure 1 - The range of the embedded PC. An embedded system can be based on
anything from a chip to a desktop PC and still maintain PC compatibility.
There is no single definition of the embedded PC. In general, an embedded system is regarded as an embedded PC if some of its architecture resembles the architecture of the IBM/PC. These computers are X86 based and use an interrupt, memory, and I/O map that is consistent with the IBM/PCs. On the desktop, the IBM/PC-based computers look very much the same. In the embedded world it is not as easy to identify the embedded PC. Figure 1 shows the range of what is considered an embedded PC.
An embedded PC can be a single chip (such as the Intel 80386EX) that has a subset of the entire PC architecture. It can also be a chipset surrounding the X86 microprocessor that is placed on a proprietary board. Or it can be a PC on a credit card sized board from S-MOS. Or a PC on an STD-bus card from Ziatech or a proprietary card like those from Radisys. An embedded PC can be based on the ISA bus but not look like an ISA card, like the PC/104 bus from Ampro.
Many embedded PCs are based on ISA cards just like those used on the desktop. They just don't look like the desktop PC in that the enclosures they use are industrial strength and mount on a wall or in a rack.
Whatever the form of the embedded PC, they all can take advantage of the fact that they are, in varying degrees, PCs. They can all benefit from the reduction in development time brought about by the ubiquitous PC. Though the embedded PC is not perfect for everything, it has a number of advantages over other approaches. If the application can't take advantage of what the PC has to offer, the X86 is just another microprocessor option. But if the application can ride the coattails of the consumer PC products, you can reap significant savings in development time and cost (see sidebar, "The reasons to embed a PC").
Each embedded system follows a similar development cycle. After the requirement is defined, the steps are: system design, detailed design (hardware and software), prototype creation, system integration, debugging, and maintenance.
These same steps are carried out when using an embedded PC. Though some steps can be skipped with any development, this article addresses each step and discusses how the use of the embedded PC can shorten or eliminate them. Figure 2 depicts the embedded system design cycle and summarizes how the embedded PC can shorten the steps.
Besides shortening each step, using an embedded PC may allow leapfrogging over nearly all the steps. For example, consider creating a system which must read 8 sensors, perform a calculation on the read data, and then set 3 analog outputs and 4 alarms. The normal approach is to create the system with each step of the development cycle.
Figure 2 - The design cycle, and how the embedded PC can shorten steps.
An alternate approach uses Lotus 123, a spreadsheet program. Lotus 123 reads data from an RS-232 port and automatically inserts the data into a cell in the spreadsheet. The calculated results can also be taken from a cell and automatically sent to RS-232 ports. The entire development is reduced to connecting PC-based components together and configuring a spreadsheet.
Only certain embedded systems can take advantage of Lotus 123, but it is an example of the types of tools available in the PC world. Another example is LabView from National Instruments. This tool allows the developer to select needed functions as block diagrams and then connect them together graphically. Then the tool creates the program to perform the selected functions
Other companies like Keithley Metrabyte and Data Translation have similar tools. As these tools become more powerful, they will significantly reduce development time.
Digital signal processing (DSP) can also benefit from the PC. Tools are now available that allow complex algorithms and instruments to be implemented by just connecting desired blocks on a PC's screen. An instrument that acquires data, presents the data on the screen, performs complex algorithms like an FFT, and displays frequency data in another window is easily created. Tools from Hyperception or Signalogic allow a complex DSP based instrument with a graphical interface to be created in a matter of hours.
When the automated tools can't enable a jump from system design to final test, the standard development steps must be followed (Fig 2). The first step in developing any embedded system is the system design.
During system design, the microprocessor must be chosen, memory, interrupt and I/O maps must be created and many other details must be dealt with. When using the embedded PC, the developer can skip most of these decisions as the system design of the embedded PC is already defined. They merely have to choose the X86 processor which provides the needed performance and determine how much memory is required. Then the appropriate boards and peripherals are selected.
The Reasons to Embed a PC
|
The time to create a system design from scratch can vary from a few hours for a simple system that doesn't require the approval of others, to weeks for more complex designs that must go through committee reviews. Once the embedded PC is selected, the time to go through the approval process is reduced since the number of options are reduced.
Once the system design is accomplished, the detailed hardware and software design begins. The design process is commonly split into hardware and software design. Then, once the hardware is ready, both parts are integrated and the debugging process begins.
The embedded PC provides a simplified hardware design since more options exist for the PC architecture than any other architecture. Fewer custom devices are required. The software design is also simplified with readily available off-the-shelf software modules.
The world is moving towards graphical user interfaces (GUI) in a big way. In the not too distant future, most embedded systems will need a GUI. Cash registers, copy machines, industrial controls, and test equipment are examples of systems that have already moved to GUIs.
GUIs are not easy to create. They take a lot of time and are difficult to maintain. Normally a GUI is created by making complex calls to a graphical library or an operating system. Creating the code for these calls is very time consuming and tedious. Also, it is very difficult to make changes to the code.
Once a GUI is finally created and seen on the screen, the layout is often less than optimum and a process of moving and modifying begins. To move something on the screen, it is necessary to modify the function call. Making the modification by changing the code with a text editor is very time consuming. The ideal approach is to just grab the object and move it or resize it. To change the operation of an active object on the screen, you want to just click on it and modify its definition.
To speed up this snail-like process and eliminate some of the tedium, GUI development tools are used. GUI development tools are moving quickly in the PC environment. They exist in other environments, but the high quality and low price of the PC-based tools makes them very attractive. Tools such as Visual C++, Visual Basic, and Delphi allow complete GUIs to be developed in a very short time. The savings can add up to weeks or even months compared to developing a GUI without these tools.
The desired result of the development process is a working product. At some stage in the development, the system must be integrated where the software is run on the hardware and the system is proven.
Integration is the high anxiety step in the development process. Here is where costly mistakes are found and must be fixed. Unfortunately, system integration usually happens near the end of the development cycle, when mistakes are most expensive to fix.
Depending upon the type of embedded system, the added cost to fix a mistake goes up by 2 to 10 times at each step. System integration is one of the most costly places to find and fix mistakes. This is also where schedules often fall apart since this is the first time the design gets tested.
There are many ways to reduce the integration time. One of the best ways is to create a prototype early in the development process to prove the hardware and allow software testing. Development progresses without having to waste time creating test routines to make up for the lack of hardware.
Prototyping is another area where the embedded PC really shines. Once the system design is accomplished, a functionally exact prototype can be made in a few days. Just about any interface imaginable is available for the PC. If the system must read voltages, run motors, read GPS position, synthesize waveforms, log data to a DAT drive, use a modem, control digital lines, send data on a network, or whatever, the card most likely exists. Moreover, the drivers for the board are also often available.
The time and expertise it takes to create a PC-based prototype is very low. Now, as the software is being created, a fully functioning prototype is available for testing. The hardware is also easily checked. The time and money needed to change the system at this stage, right after the system design is created, is much less than at the end of the project when system integration is normally attempted.
The code development step mostly fits into two categories, native-development and cross-development. When developing in a native environment, the code is developed and run on the same hardware. In a cross-development environment the application is developed on a host computer and must be loaded into target hardware to run. In many cases, the processor on the host and on the target are different so the application code can't run on the host at all.
Each approach has advantages and disadvantages. The native approach is often simpler since there is no need to connect and communicate between the host and the target. The cross-development approach allows more flexibility in the design of the target and allows the target to be monitored more easily.
A significant difference is cost. When developing in the native environment, the development hardware already exists, the computer on the desk. The cross development environment requires additional resources.
The PC thrives in both development approaches. As a native-development tool, the PC on the desk is used to develop and debug the application. Then the code is moved to the embedded PC-based product where it runs just like it did on the desktop.
The PC is also becoming the host of choice for cross-development. In this case the PC provides an easy to use and familiar environment. Most available development tools that once used workstations are now available for Windows-based PCs.
When using the native environment there may be problems that can't be fixed with a native debugger. In these cases, an in-circuit emulator (ice) or logic analyzer can be used to monitor the system's operation.
The PC affords another interesting option from the desktop world. A full function in-circuit emulator (costing from $8,000 to $30,000) can help find the really tough problems. Or Periscope's real-time hardware debugger can be used. This $3,000 debugger provides trace and debugging functions that work with PC-based tools like Phar Lap Software's TNT Embedded Tool Suite.
As next generation X86s emerge, the on-chip debugging port becomes an interesting option. A very low cost board could sit in the desktop PC and interface to the internal registers in the microprocessor. Now the difference between native- and cross-development begins to blur.
Embedded systems are usually difficult products to maintain. Once a product is shipped, the expertise within the company often drops quickly. The designers are assigned to new projects or leave the company. Eventually, maintenance is required and few remain who understand the design. When using the embedded PC, the hardware design is already well understood and the learning curve to get someone up to speed is reduced.
Documentation is a real problem in the embedded systems community. Many attempts have been made to address the problem. The common approach to documentation is to ignore the problem and hope it's never needed. When the PC is used, much of the hardware and lower level software is well documented. All that has to be documented is the higher level portions of the software.
The embedded PC can significantly reduce time to develop on projects where the application is able to take advantage of what the PC has to offer. The potential savings for each design step are summarized in Table 1. A comparison between a PC-based project and one without the advantages of the PC is made for each design step. The table provides insight into how much of a savings you could realize when using an embedded PC.
Whether the development cycle is reduced by just one week or by a year, it is still worth trying to achieve a reduction.
Table 1 - Potential savings at each design step
| Design Step | Traditional | Embedded PC | Potential Savings |
| System Design | Start with blank paper and define the entire
system. (2 hours to 2 months) | Start with PC architecture and select from available
options (2 hours to 2 days) | No savings with very simple systems. Up to 6 weeks on complex designs. |
| Detailed Hardware Design | If using off-the-shelf products, select the
appropriate boards. If designing from scratch,
begin a long and tedious process of design. (2 days to 2 years) | If using off-the-shelf products, select the
appropriate boards. More options available to the
PC then any other architecture. Less chance of
requiring custom design. If designing custom board,
many options from single chip to chip sets get you
going quickly. (2 days to 2 months) | If all needed boards are available to both options, no savings. If needed components exist in the PC world and not in other approaches, can save months. |
| Detailed Software Design | Write code, often from scratch. (1 week to 2 years) | Use as much off-the-shelf software as possible.
Use inexpensive but high quality tools. GUIs are
much easier to create. Easier to find programmers
familiar with the PC then some proprietary or lower
volume approach. Can also use very high level
tools like LabView or Lotus to quickly develop
software without writing any code. (2 days to 6 months) | If the application fits within the capabilities of the high level tools, the savings can be many months. If the application requires all code written from scratch, the savings is marginal. Still, many more low level drivers are available for PC products than any other architecture. |
| Prototype | Must finish the detailed design before a
prototype can be made. If using only available
boards, the prototype is quickly assembled. If
building from scratch, a prototype can be built
only after the components are acquired and a
board is laid out and fabricated. (1 week to 6 months) | Get any PC and select the boards that provide the
functions needed. It doesn't have to look like the
final product as long as it works like it. (2 days to 1 week) | Significant savings since the embedded versions of the PC work like the desktop versions. Almost any conceivable interface or peripheral is available for the PC. The prototype is assembled quickly and will work just like the final product. Savings from days to months. |
| System Integration | First time the entire system is tested. Very late
in the design cycle. Hardware/software issues
now must be worked out. (2 weeks to 6 months) | Final system integration consists of moving tested
software from the desktop prototype to the final
product. The software has already been tested with
nearly identical hardware. (2 days to 2 weeks) | Savings from days to months. Serious problems already detected and fixed on the prototype. |
| Maintenance | If the system is properly documented,
maintenance personnel must study the
documentation and perform any required
maintenance. Typically, the available
documentation is very poor. (Doesn't affect product development time, costs later) | The PC is well known and documented. Easier to find knowledgeable maintenance personnel. When documentation is not adequately provided (as is typical) maintenance personnel can use other sources of PC documentation. | No savings to the development process. Cost comes later, if (when) problems surface. Also, the time to create new versions of older products is reduced if using a standard PC architecture. |
Legal Stuff © 1997 Intel Corporation
