Embedded system development can be a bit like reinventing the wheel. Many embedded systems vary only by interface requirements. Given that customers are not willing to pay or compromise the product for functionality they don't want, designers have learned to reuse software. While PC/104 provides off-the-shelf hardware, designers sometimes must look for other form factors when customer requirements call for a battery-powered system that must fit into a matchbox, not a shoebox.

The Compact Computer was the outcome of a customer requirement, although at the time the customer did not know it. This computer is similar to the calculator chip Busicom commissioned Intel to design. Intel called it the 4004, which later became the first microprocessor.

The customer’s requirement was simple: Take a real-time data acquisition system for a wind tunnel model and send the data out for analysis either on a single wire or wirelessly. The main problem was that the company only wanted two devices, thus precluding a custom design. The design team could have invested to develop this as a product, but it was not the right time.

Choosing a form factor

So the designers went on a hunt for an appropriate commercially available solution. Many SBCs were available but lacked the right mix of input or output for the application. This search eventually led to PC/104. The team built a suitable PC/104 stack but quickly determined it was too big to fit in the model.

Then the eureka moment arrived when the designers realized that several commercially available boards smaller than PC/104 – PC-Card, CardBus, and CompactFlash, to name a few – ship in the millions of units. However, these boards are normally used in laptop computers, no more than two at a time. Adding the laptop to the equation made the final design too big and too expensive as an embedded system.

At that point, the designers considered how difficult it would be to develop a processor that could talk to several of these cards. It sounded pretty straightforward, as long as all the cards were the same type, not mixing PC-Card with CompactFlash or CardBus. (PC-Card and CardBus have the same form factor, making it hard to determine which is which.) If the designers built a system that could only use PC-Card or CardBus, numerous users would populate the system with the wrong type of cards, creating a support nightmare.

CompactFlash eventually stood out as the optimal form factor for the system. A quick search on the types of CompactFlash cards available produced a list of cards that supported Ethernet, Bluetooth, ZigBee, 802.11, mass storage, GPS, GPRS/GSM, and Analog-to-Digital Converter (ADC)/Digital-to-Analog Converter (DAC). So it appeared that miniature embedded systems could be developed using standard CompactFlash cards just like PC/104 cards, but one-thirtieth the size. The team aimed to build these miniature embedded systems (4 cm x 4 cm x 2 cm) using commonly available low-cost cards with minimal hardware development and nonrecurring engineering costs.

Knowing that they could easily build rapid product prototypes of these systems in hours or days, the designers wondered why no one else had made them. A manager explained that there are two reasons certain products don’t exist: it is a stupid idea or nobody has thought of it yet. The designers went with the latter reason as they proceeded with product development.

Software, application considerations

To achieve wide-scale adoption, the CompactFlash computer’s software had to be based on a standard Operating System (OS) such as Windows CE or Linux to minimize the learning curve. The goal was to be able to plug in any CompactFlash card and let the system run. The ability to swap Ethernet cards for wireless cards and not make any software modifications was appealing. Since it was possible that the drivers for the CompactFlash cards would need to be modified to support the architecture, the designers chose open source Linux.

At that time, some small Linux systems were on the market, but none as small as 42 mm x 37 mm. After making a few compromises, the team created the first CompactFlash Computer. The rapid prototype with two Ethernet ports and wireless capability is shown in Figure 1. Based on a Freescale MCF5272 microprocessor running at 40 MHz with 8 MB flash and 32 MB SDRAM, the system acted as a CompactFlash host (it controlled other CompactFlash cards) and was originally supplied with a 10-slot motherboard measuring 52 mm x 42 mm. A low-cost 4-slot carrier board was added later. Figure 2 shows the system’s carrier board with three CompactFlash expansion slots.

While some companies used the CompactFlash system for rapid prototyping and proof-of-concept engineering, others used it to develop small systems. Projects ranged from wireless-based health-monitoring systems to GPS logging to data storage.

Other designers wanted the ability to plug the system into a CompactFlash card slot in existing devices such as cameras and PDAs. Applications included:

• Secure applications for PDAs
• Accelerators for existing devices to allow new functionality within the original processing budget
• Emulating storage cards in existing equipment and accessing files via wireless or serial communications, cameras, data loggers, and so on
• Additional digital I/O for systems with a CompactFlash slot through a connector on the top; tiny add-on cards could contain ADC or DAC clips with a custom connector

Though these were reasonable applications, the first Compact Computer was designed as a CompactFlash host and could not be plugged into a CompactFlash socket. One of the compromises made in the design was using a small programmable logic device to generate the CompactFlash bus signals, ensuring that the board layout could be achieved in a reasonable number of layer and line widths.

Adding an FPGA

The simple solution was to replace the programmable array logic with an FPGA, which allowed the CompactFlash processor module to manage the bus as a host or slave device and made the bus reconfigurable. Using an FPGA also made it possible to quickly add other features to the module. Multiprocessor systems could be developed with custom communication systems, shared memory, or message passing. In essence, this was an electronic LEGO.

FPGA selection became the critical design decision as the board space had shrunk to 37 mm x 25 mm with the inclusion of a top connector for I/O. An FPGA with a soft-core processor would allow one part to do the work of two. But the 100 MHz performance claimed by vendors with soft-core processor FPGAs quickly decreased to 50 MHz when the FPGA was loaded with other functions. Going from 40 MHz to 50 MHz was no wow factor, especially when similar systems were already at 400 MHz. The new system had to have a processor plus an FPGA.

With a 12 mm x 12 mm package and 500, 600, and 750 MHz clock options, the Analog Devices Blackfin processor gave the new system an easily upgradeable future. It had 0.8 mm solder ball spacing, which simplified layout and manufacturing. Figure 3 shows the latest system with a 500 MHz Blackfin processor.

The designers then turned to the layout problem, iterating through different FPGA, SDRAM, and flash devices until finding a board layout that could be manufactured at reasonable costs. All the computers in the company were running PCB routing programs 24 hours a day, 7 days a week for a long time.

Revolutionary prototype development

Built with commercial hardware at a fraction of the size of existing industrial systems, the Compact Computer worked, meeting the customer’s requirements and providing a starting point for future designers. To reap the benefits of this system, designers must not to be constrained by a “nobody else does that” attitude. Instead, designers should change the way prototypes are developed by taking advantage of true plug-and-play embedded systems. After all, you don’t win races by following the leader.

Paul Zawalnyski is the managing director and acting technical director of C Data Solutions, an Exeter, England-based company that was formed in late 2004 specifically to develop the Compact Computer and modular embedded systems. He has 25 years of experience developing hardware and software in the military, medical, and networking industries. Paul earned his 2.1 Degree in Electronics from the Dundee College of Technology in Dundee, Scotland, and his Diploma in Digital Techniques from Heriot-Watt University in Edinburgh, Scotland.

C Data Solutions
+44 1392 277 202
[email protected]
www.cdatas.com