BROWSE BY TECHNOLOGY










RTC SUPPLEMENTS


EDITORIAL

COM, Meet Carrier-Not a Speed Dating Scene

TOM WILLIAMS, EDITOR-IN-CHIEF

  • Page 1 of 1
    Bookmark and Share

We in the press make a constant practice of covering the newest developments in processor technology and the newest modules that incorporate their functionality, while often neglecting some of the other issues important to successful system design. Now, it is certainly of central importance to follow the advances in processor technology such as the recent developments in low-power 32-bit devices like the Intel Atom and the VIA Nano. These processors have enabled the creation of extremely small processor modules that make possible the extension of very powerful embedded intelligence into ever smaller and more specialized application areas.

Among the Atom-based modules that have recently appeared on the market, for example, there appear to be more similarities than differences. True, they are available on different form factors such as COM Express, Pico-ITX, ISM and more. The modules offer alternatives in terms of additional connectivity—that is, in addition to what is provided by the main connectors. They offer such things as onboard solid-state storage options, graphics capabilities and the like. But solving the system design issue of the main processor is mostly a process of window shopping, feature selection and price comparison. The hard part comes after that.

As we all know, the job of the CPU is to handle the I/O data by running software. No duh. In the case of ever more diverse embedded applications, that I/O “thingie” can get pretty complicated. It can often involve analog-to-digital and digital-to-analog conversion. It can be targeted toward a host of real-world phenomena such as temperature, rotation speed, acceleration, lumens, color grades, vibration, pH, chemical and gaseous composition, spectral data, volume, and flow rates of liquids. The list goes on. The nature and variety of sensors is growing.

Each of these real-world phenomena must be translated into an electronic digital format the processor and software can deal with. Not only that, it must be done efficiently, at low cost, and, in the case of COM modules, in a form that can be sent over the signals supported by the connector. What we seem to have at present in the COM arena are a lot of processor modules and relatively few carrier I/O modules on the market. That means that the major time and expense in putting together a specialized embedded application needs to focus on getting the I/O right so that it works with the COM module. Oh, yeah—and that little matter of the software.

One of the big selling points of COM modules is that they allow an OEM to concentrate on getting the I/O portion of the design right, and when it comes time to upgrade performance or functionality, to simply plug in a more powerful CPU. My spies tell me this is by far not that straightforward. One issue—certainly to be expected—is engineering a specialized I/O module to input data from sensors that is accurate in terms of the CPU. This has been greatly aided by a generation of intelligent sensors that often convert the units they are measuring to standard electrical signals that can be dealt with on the I/O board and by the processor.

A somewhat trickier issue is presented by the subtle variations between designs of COM modules—even those that incorporate different versions of the same CPU architecture from the same manufacturer. Matching the electrical characteristics of the COM module and the carrier in terms of power-up times and other variables is something that is apparently more difficult than has been assumed. A connector standard between CPU and carrier card does not always completely isolate either from some of these difficulties, particularly when the CPU is powered by connections coming off the carrier card, which is actually connected to the power supply.

Having heard some of these comments from knowledgeable engineers, we at RTC are very interested in finding out more about them and what can be done in design practice to smooth the hoped-for path to easier integration. Are there guidelines that can be established? Are there some additional specifications and/or standards needed? Or does it really just come down to detailed, precise plain old work? You know—engineering.