Big Protos for Small Systems

  • Page 1 of 1
    Bookmark and Share

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 / back-up 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.