They are consequently reliable, robust and effective. EPCs support a range of standard peripherals, and are a highly scalable platform. It’s no surprise, then, that they are becoming an increasingly popular answer to many electronics engineering challenges.
Yet, although EPCs do make commercial and engineering sense in many applications, their “quick fix, one size fits all” approach does bring its drawbacks.
An alternative approach, based on the latest generation of 32-bit processors, does address many of these drawbacks and allows the designer the flexibility to truly differentiate his product from the competitors. The customised alternative is becoming increasingly attractive because of both the availability of inexpensive 32-bit devices—now under the “magic” US$10-mark ($14)—and user-friendly software development kits.
One application area where EPC-based design approaches may not be the most suitable, for example, is in real-time applications. Because EPCs are invariably based on x86 type processors, with their Complex Instruction Set Computing (CISC) architecture, they react more slowly to external interrupts, compromising real-time response.
In contrast, a custom design can be based on a Reduced Instruction Set Computing (RISC) architecture processor, such as Motorola ’s PowerPC, which responds far more quickly to interrupts. Such designs offer superior real-time performance compared to the EPC alternative.
In general, when the convenience of an EPC is outweighed by its inflexibility, a custom design should be considered.
Identifying that point, however, is not easy and involves many variables. Here, we consider those variables from both a technical and commercial perspective in order to clarify the breakpoint.
Operating systems
Both an EPC and a 32-bit processor-based custom design require an operating system (OS) to take care of running the application software. For the EPC, the choice typically comes down to ’s Windows, or the open source Linux. In rare instances the EPC may run a specialised proprietary OS. While Linux is free, there is a fee on a board-per-board basis for Windows, and a specialised OS may run to tens of thousand of dollars in non recurring engineering charges.
In the case of the 32-bit processor, the choice of OS is slightly wider with options like ECOS, Linux (of which there are several version including Real Time variants), Windows CE and a number of specialised Real Time OSs (RTOS) that don’t readily extend themselves to an EPC. ECOS and Linux are freely available with no royalties to pay and suit PowerPC, Coldfire, MIPs and ARM core processors. Windows CE also suits the MIPs and ARM cores, and of course gives the final product a Windows look and feel, but with an associated royalty fee. (It is worth noting, however, that Linux applications are available that provide a similar look and feel to Windows.)
Although C Compilers can be used to write simple applications for an EPC, as the complexity increases so does the cost of the Compiler. The price can range from a couple of thousand dollars to tens of thousands. In contrast, OSs running on 32-bit processors can take advantage of relatively cheap software tools for application development even up to a fairly complex level.
It could be, however, that the designer is only really interested in developing a novel software application, and not customised hardware, in which case an EPC offers the advantage of a readily available platform. In this instance, all the designer requires is a desktop PC and the software development tools and he is up and running. This also bestows a number of other advantages: the hardware can be readily upgraded; performance can be scaled, and there is the opportunity for costs savings if a less expensive EPC becomes available. However, it is important to note that the performance of the software will always need to be verified on the target EPC, especially if a customised interface board is employed.
Running an OS demands significant SDRAM on the EPC, and additional memory will be needed for data processing. Alternatively, it’s possible to couple the EPC to an external hard disk or other non-volatile memory, but this can affect the system performance and adds to cost. Adding onboard non-volatile memory to an EPC can be difficult.
Real time applications
Another increasingly important consideration for software applications is security. An EPC is a standard piece of hardware, the only real differentiation is the application software it runs. If the product comprises an EPC plus a software disk, the company runs the risk of a competitor simply copying the software and running it on any EPC and passing the product off as its own.
An embedded approach is far more secure and protects intellectual property (IP). This is because the software is stored in a Flash memory chip, accessed by the processor only on power up. It is far harder to copy software from a Flash chip than it is to copy it from a disk.
EPC platforms running OSs such as Windows are not suitable for running safety critical applications that need real time control. Unfortunately, even some so-called RTOSs, costing thousand of pounds, have their limitation when used in genuine real time applications. The is because Windows, and these other RTOSs, run with disabled interrupts, instead using software schedulers to check for external events before responding accordingly. The resultant delay between the event occurring and the system responding is known as the interrupt latency.
The interrupt latency for Windows, for example, is between 30 and 1000 μs for a Pentium processor running at 200 MHz. The situation improves for the same processor running an RTOS, with the interrupt latency dropping to between 12 and 70 μs. Running the same RTOS on a Coldfire processor clocked at 33 MHz reduces the worst case figure to 1.8 μs; remove the RTOS completely, with the application running directly on the processor, and the interrupt latency drops to about 0.4 μs. In all cases, what’s fundamentally important is that the interrupt latency is less than the duration of the external transient event, otherwise it could be completely missed - disastrous for a safety critical application.
Hardware challenges
EPCs offer scalable performance because they are based on an x86 CISC processor. This genre of processors start with devices running at a few hundred megahertz and continue right up to the latest Pentium 4 running at a few gigahertz. The range of processors means it’s possible to match performance to budget to a certain extent.
Similarly, RISC processors (which use a different architecture to x86 devices) offer a vast range of performance. Examples of 32-bit RISC processors are Motorola’s PowerPC and Coldfire ranges, and AMD’s MIPs-based Alchemy devices.
EPC boards support many hardware peripherals, such as 10/100 Ethernet and GigE Ethernet, USB OTG and audio and video support. In fact, just about anything you might expect to see on a desktop PC. EPCs are usually supplied with low-level software drivers for these standard peripherals.
There may be some customising needed for a particular application, but this can often be taken care of using off-the-shelf standard IO, albeit with added cost and complexity. Note that in the case of telecom features, it does become difficult to find off-the-shelf solutions.
32-bit processors are also typically supplied with varied range of standard IO compatible with those on EPCs. Examples include PCI and PCI-X, 10/100/1000 Ethernet, USB 2.0 Host and Target, and LCD controllers. Many contemporary 32-bit processors are in effect complete System-on-Chip solutions with performances into the gigahertz range.
Apart from the software issues already discussed, an x86-equipped EPC hardware may not be the best choice for running applications demanding genuine real time response. This is primarily because of the CISC architecture. This has its advantages in that the compiler doesn’t have to work very hard to translate a high-level language statement into assembly code. Consequently, because the resulting code is relatively short, little RAM is required to store instructions. The emphasis reverts to building complex instructions directly into the hardware.
The disadvantage is that a simple CISC instruction consumes many processor clock cycles. This is reasonable for non-real time applications where fast response to an external transient event is not critical, but not good when fast processor response is needed to deal with a real-time event.
Fast response
In contrast, 32-bit processors tend to be RISC based. This means they operate using much simpler instructions that can be executed in a single clock cycle. The downside is that the compiler must do much more work to translate high level C language into assembler code, and the instructions use more memory. However, the response to an external event is much faster, because the RISC based processor can stop the current task, store where it is and jump to handling the interrupt, then return to the previous instruction, all within a few clock cycles. A ColdFire processor, for example, responds to an interrupt in 0.4 μs, compared with 1.3 μs for an x86 processor running at 100 MHz. Note that these delays are in addition to the interrupt latency inherent in the OS.
x86 processors are relatively power-hungry (more clock cycles correlates to higher power consumption) and tend to run hot. Unfortunately, purchasing a proprietary EPC leaves the designer with no control over power-consumption and heat generation. Apart from becoming a critical issue in a battery-powered application, it increases the cost of the design by complicating the PSU and cooling. This in turn adds cost.
In comparison, several 32-bit processors are specifically designed to run at low power consumption, with the mobile product market in mind. Good examples are AMD’s AU1100 device or Motorola’s Dragonball ARM processors, which have some of the best performance to power consumption figures on the market.
Time-to-market
Much of the profit for a new product comes from being first to market. Consequently, the longer the product is available to the consumer before the competition, the greater the profit.
A proprietary EPC significantly shortens the design cycle, as the engineer doesn’t have to worry about the hardware.
The difference in time-to-market between an EPC and a custom design based on a 32-bit controller, however, is not as long as it may first appear. Designing a 32-bit processor has been simplified considerably with the silicon vendors providing reference designs and development boards to aid the design engineer. Nowadays, the most significant factor in designing with a 32-bit device is the software application development.
Because the development tools are so user-friendly, the hardware design can actually run in parallel to the software development, as the software engineer can use a development board to work on the application software. The only extension to the design cycle comes when the software has to be integrated with the hardware.
Experience shows that the effect on a typical project would be to add around three months to a design cycle; this is not a huge overhead when compared to the long term cost savings and flexibility of owning a customised design.
Another significant cost saving of the custom design is a simplified supply chain.
All that is required is a single stock item (the 32-bit processor) from one vendor. Of course, it could be argued that an EPC is a “single stock item”. This is true in a sense, nonetheless it’s a complex assembly and that could compromise long-term supply, as manufacturers tend to frequently update the product as PC technology moves forward.
It is possible to multi-source an EPC by standardising on an ATX footprint product, but that means a standard enclosure that may not suit the end application. Moreover, there is no guarantee that alternative EPC will be a drop-in replacement.
The choice between an EPC and a custom solution is not a simple one. It depends on a combination of factors such as software, hardware and commercial implications. Each has its advantages and drawbacks.
Fortunately, Australia is endowed with several first-class distributors of both embedded PCs and 32-bit processors. Each will be able to offer reliable advice on the best approach for your application. As always, it is best to weigh up all the options before committing to a particular technology.