Outside the black box: Focusing designs on I/O
Originally appeared in Small Form Factors magazine
When designing an embedded device, designers should consider the I/O requirements first. Implementing COTS components to assemble proof-of-concept prototypes saves money and time. By using a full-size PC and USB data acquisition modules, designers can prove the functionality of a device and avoid most if not all engineering expenses.
Any embedded system can be described as an algorithmic black box connected to inputs and outputs. In most embedded applications, the inputs consist of digital bits, frequencies, voltages, currents, and similar familiar signals, while the outputs include more digital bits, frequencies, voltages, and currents. More complex embedded devices incorporate RS-422, Ethernet, or NTSC or HDMI connections.
Inside this conceptual black box, the algorithms align to monitor and control the inputs and outputs. All of this algorithmic functionality can be labeled as “software” and set aside. Whether implemented in VHDL, microcode, C, or Java, firmware or software, the algorithms that perform the device’s functionality are capable of running on any available hardware platform.
Before a design can exist, designers must define the inputs and outputs, addressing several questions. Consider the example of a vending machine design. How many buttons will it have? Each button will have associated digital signals. How many vending motors will it need? Each motor needs frequency, voltage, current, and/or pulse-width modulation control outputs. Does it need to be networked for logistics? That would point at POTS or perhaps TCP/UDP. How many blinkenlights will it have?
The answers to these questions are more product-defining than the decisions about which language or processor the device should run – more critical than what is inside the black box. No matter which inputs and outputs are involved, the embedded device design is defined by them.
Consistency throughout the design cycle
Many companies make prototypes using arbitrary hardware and software with no expectation that they might relate to the production unit. These early builds are usually designed on shoestring budgets to get a feel for the system or to sell the idea to management.
Leveraging these expenses into future stages of the production cycle can be costly. However, by integrating interoperable I/O modules, designers can keep using the same modules throughout production and circumvent the need to rewrite code for a new input device (or vendor) while moving through the design cycle.
At each phase in the process, device designs must conform to smaller, lower-power, quieter, cooler, and/or cheaper footprints. Interoperable I/O modules can enable the device to continue working with each iteration of the black box, regardless of the architecture. Instead of running on a desktop full-size PC, the device can be powered by Mini-ITX, Computer-on-Module (COM), Pico-ITXe, or a full custom backplane using the exact same plug-in data acquisition modules.
USB helps ensure longevity
USB is the key to achieving this interoperability. At any scale of custom or COTS design, from desktop PCs purchased online to solid-state fanless Pico-ITXe systems measuring less than 100 mm on one side, USB is present. Every modern interconnect architecture includes USB interfaces. Stackable Unified Modular Interconnect Technology (SUMIT), EPIC, Pico-I/O, ETX, and other standard form factors all include at least one and usually four or more USB ports. Each port can be expanded with off-the-shelf hubs – boxes or chips – to get more than 100 USB devices in a system, per USB controller.
Choosing I/O on USB eliminates the hassle of making changes to the data acquisition module as designers iterate closer to production designs. Use any desktop PC with USB data acquisition modules in the proof-of-concept (Figure 1), then build the engineering prototype using Mini-ITX or ETX, and wrap up the production unit design with Pico-ITXe or a SUMIT – Industry Standard Module (ISM) system – each and every choice will have USB available. Even the IP for FPGA[] or ASIC full custom designs is readily available. Later on, three or five years down the road when the algorithmic black box isn’t available anymore, USB will still be there for the product’s I/O.
Figure 1: Designers can use a desktop PC with USB data acquisition modules in a proof-of-concept design.
One concern worth noting is that USB interconnects vary among embedded platforms, especially when compared to desktop PCs. An ordinary desktop uses USB A connectors to host its USB bus. PC/104, EPIC, ETX, and other “medium”-sized form factors offer a variety of possible connection methods. In some designs, a full USB A is provided. Others only have a 5-pin micro header requiring a cable kit or some other adapter to remain compatible with the off-the-shelf USB I/O selected during the prototyping phase.
This is also a concern as designers progress to the final designs. SUMIT-ISM, Pico-ITXe, and other smaller form factors only provide their USB bus on the embedded (often SUMIT) connector, without offering a cable connection. During the development process, designers can add an adapter to break out these signals, but the long-term solution is to integrate the USB I/O device onto a SUMIT-ISM, Pico-I/O, or similar module. This is simply a layout concern. No real engineering is necessary, as the device retains the same USB bus architecture. Changing the physical layout of the I/O device has little or no impact on its schematic when USB is kept at its heart.
In fact, SUMIT and other connectors used in many embedded platforms allow more than one USB device to be added easily using modern lane-shifting techniques that eliminate setup and configuration headaches.
More cost-effective production runs
Using a PC in a production device can simplify prototyping, particularly when integrating a ubiquitous bus like USB that allows the same I/O devices and the same development effort to be used while proceeding toward production designs.
As production quantities get larger, a full custom solution becomes more appealing; however, engineering costs are very high, so the cost-per-unit versus non-recurring engineering expense must be weighed against production volume. Historically, the break-even point for full custom solutions is measured in hundreds of thousands of pieces.
ETX and other COM systems have lowered that barrier and proven to be cost-effective for production runs measured in mere thousands. By using USB and other interoperable bus I/O modules, designers can squeeze that break-even point down to product runs measured in the hundreds. The right vendor can take the existing schematics for one or more USB data acquisition I/O devices and integrate them onto a single ETX baseboard for far less time and money than any new design can be engineered.
This means designers can build a proof-of-concept using one or more USB or USB/104 data acquisition devices and continue using the same modules while shrinking the black box smaller and smaller (see example in Figure 2). Then, if necessary, those same modules’ underlying designs can be slapped onto a custom ETX baseboard or SUMIT-ISM module, and the software will work the same way it did in the original prototypes.
Figure 2: A 1U rack chassis design uses a PCI-104 CPU and seven USB/104 I/O boards.
As the long-term intended level of integration gets deeper, the form factors of the I/O modules used in the original prototyping phases matter less and less, while the need to choose an interoperable technology such as USB remains. However, if a design will not be integrated beyond a multiboard level, it is important to choose CPU and baseboard form factors that will be available for the long haul – industry-standard, modular, and vendor-neutral specifications like ETX and other COM systems, SUMIT-ISM, and Pico-ITXe (Figure 3). This ensures that designers will be able to fill the black box for years to come.
Figure 3: To help ensure longevity, designers should choose standard form factors like Pico-ITXe, shown here with ACCES Pico-I/O stacking modules using SUMIT.
If quantities justify building a fully integrated PCB, the underlying designs should be available for that situation as well. This reduces engineering expenses because instead of designing in-house, designers can simply integrate vendor IP directly into their system. Using a bus like USB means the software doesn’t need to change.
Open source provides code visibility
To further ensure interoperability, designers should select vendors that embrace open source. USB is a multilayered protocol stack, from the bare serial port interface at its heart to the packetization specification all the way up to high-level APIs from the I/O vendor. When iterating a design to the production-ready stage, it might be useful to eliminate layers in the protocol stack. An I/O module that documents each of these layers of communication provides the requisite information should this become necessary.
Open source designs also enable support for the I/O device in environments both new and old. Does the I/O device support development in COBOL? What about Haskell? Even if the environment the application requires is too old, too exotic, or too new to be supported by the vendor directly, having the source code available to every layer of the software stack ensures that interoperabiity is achievable.
Thus, designers can benefit from using USB data acquisition modules like those offered by ACCES I/O Products that provide a high-level API for OS X, Linux[], and Windows, as well as document all vendor-specific USB Control Requests. These modules supply full source code for every layer of driver, dynamic link library, shared object, sample program, and utility. Some vendors including ACCES I/O Products also provide on-card firmware source code in the cross-platform C language.
The best bus choice
Although this article focuses on USB, much of the discussion to some extent applies to other communication channels on modern module interconnects. SUMIT and other connector specifications include PCI Express and LPC channels in addition to USB. However, despite the possibility of using these other buses across the same connectors, true vendor neutrality and interoperability are currently best achieved by sticking with USB when latency and throughput match the application requirements. For example, the LPC bus, although included, does not have a software layer defined – there is no register map standard, no base address, no protocol for accessing LPC lanes – between vendors.
USB is thus the simplest and most interoperable choice for vendor neutrality, compatibility, and flexibility throughout the design cycle.