Big Protos for Small Systems
The undeniable benefits of computer-on-modules – multi-sourced x86 and RISC
computing cores with well-defined interfaces to a carrier board – are helping more and
more embedded apps to shrink their system dimensions. Before racing off to design your
own optimized carrier board for such a COM, peruse the variety of off-the-shelf carriers
on the market.
Originally just offering basic PC-style I/O, this growing COTS ecosystem now features
real application I/O or at least expansion connectors to plug into off-the-shelf I/O cards.
Even if readily available carrier boards don’t match your I/O requirements, many of these
suppliers will spin their carrier boards for a very modest, time saving NRE fee.
If nothing comes close, you embark down the custom carrier design path. This road is
well paved by now, but littered with potholes that can’t be anticipated until they are right
in front of you. Or until after you hit one. Then the damage to your schedule and
reputation is done, and it’s too late to go back.
Designing with COMs is increasingly the ideal compromise between full custom and
fully off-the-shelf. But rather than going straight to the final optimized tiny carrier
design, consider designing a large spread out carrier board with all the debug bells and
whistles you can think of. Even better yet, try to build a huge functional mock-up of your
system using your COM supplier’s largest (ATX-style) carrier board with I/O cards you
purchase to fill the expansion slots. Find I/O cards with the exact I/O controller chip that
you want to put on a custom carrier card (e.g., LAN, UARTs, A/D, CAN, 1553, etc.), so
that you can first test the hardware and device drivers before you commit to the carrier
design.
Software engineers are often more predisposed to think in terms of functionally
equivalent models than their hardware counterparts who dive right into schematic
capture. The software folks have earned their scars of experience, such as running into a
device driver or DLL or kernel module that doesn’t behave right and the supplier won’t
fix it. When this pothole is hit and no reliable work-around can be created, the hardware
team must iterate their design until the “off-the-shelf” software works (OS, drivers, etc.).
System OEMs don’t write device drivers or OS kernels, and chip vendors and OS
vendors don’t provide source code or debug your custom carrier board.
Naturally, the pointy-haired bosses want to see a very small prototype that resembles the
final system for their marginally generous project budget. They are a visual species. Back
in their day, through-hole circuit boards with DIP microcontrollers and parallel slow
multi-drop buses were easier to probe and debug. So how can it be so hard to “get it right
the first time” with 1200-ball BGAs and SoCs?
Without bruising their fragile egos, try this explanation. The total cost of developing and
sustaining a device over 10 years can actually be reduced, considering the cost of field
failures and customer down time, by having a known good platform with ample debug
hooks. Simple pin headers and/or logic analyzer connectors, access to critical signals for
scope capture, a slot for an LPC POST Code card, and other expansion slots for similar
off-the-shelf I/O cards cover myriad failure modes and scenarios during initial
development and production phases.
Multiple connectors and circuits for different display types on the carrier board are useful
when something causes the LCD not to work. Finally, connectors for alternative / backup boot devices, for firmware updates, and for local access as well as remote access can
prove invaluable for troubleshooting problems in the lab, on the production floor, at the
contract manufacturer, or at a remote installation.
Bringing up and troubleshooting embedded systems is still a complex endeavor, even
with the vast array of software and hardware building blocks on the market. Sometimes,
these building blocks work individually, yet system integration reveals race conditions,
resource conflicts, interrupts firing for no apparent reason, and the list goes on. The more
you plan ahead with a large prototype, the better prepared you will be to avoid, reduce, or
at least respond quickly to the inevitable potholes along your journey.