SOM · SBC · Hardware

Raspberry Pi, SOM or chip down? Choosing a compute platform for a product

A Raspberry Pi is a great way to start, but not always the right thing to ship. How we choose between single board computers, system on modules and a chip down design.

When Raspberry Pi boards were impossible to find in 2022 and early 2023, many teams discovered how much of their product depended on one board. Some reworked existing boards by hand, which takes skill and a steady hand. Others moved to compute modules with similar GPIO, such as the Variscite DART MX8M and the CompuLab UCM iMX8M Plus.

Supply has long since recovered, but the question the shortage raised is still worth asking at the start of every project: what should the product actually be built on?

Three ways to build in a processor

Single board computer (SBC). A complete board with the processor, memory, storage, power and connectors, such as a Raspberry Pi. Plug in a cable and it runs. Ideal for proofs of concept, test rigs and low volume equipment.

System on module (SOM). The processor, memory, storage and power management on a small module that plugs into a carrier board you design. The Raspberry Pi Compute Module, Variscite’s DART and CompuLab’s UCM families are all examples. You design the carrier board around your product’s connectors, sensors and enclosure; the hardest part of the design, high speed memory routing, is already done and tested.

Chip down. The processor and memory go directly onto your own board. This gives the lowest unit cost and the most freedom in size and shape, but it is the largest design and validation effort, and it only pays off at volume.

SBC SOM on a carrier Chip down
Time to a working unit Days Months Longest
Hardware design effort Minimal Carrier board Full board, including memory
Unit cost Highest at volume Middle Lowest at volume
Fits your enclosure Rarely Yes Yes
Typical use Prototypes, rigs, low volume Most products High volume products

A common path is to prove the idea on an SBC, ship the product on a SOM, and only move to chip down when volumes justify it.

What we check before choosing

Interfaces. Count what the product needs, not what the board offers: camera lanes, displays, USB 3, PCIe, Ethernet, CAN, and how many of each. A Raspberry Pi has no CAN controller, for example, so an industrial product that needs CAN either adds one or picks a processor that has it built in.

Compute and AI. If the product runs vision or machine learning at the edge, look for a processor with a hardware image signal processor and a neural processing unit. The NXP i.MX 8M Plus has both, which is why we have used it for camera products.

Lifetime and supply. Check the vendor’s stated production lifetime and whether there is a second source. Industrial SOM vendors usually publish long term availability programmes. A product that takes two years to certify needs a module that will still be made long after launch.

Temperature and environment. Consumer boards are rated for the office. Industrial and outdoor products often need modules rated for wider temperature ranges, and some need conformal coating or vibration testing.

Software. The board support package matters as much as the silicon: kernel version, Yocto or Debian support, how quickly security updates arrive, and whether drivers exist for your cameras and peripherals. Raspberry Pi’s software ecosystem is excellent; industrial SOMs usually ship with Yocto based BSPs that you will build on.

Certification. Some modules come with radio approvals you can build on if you follow the vendor’s antenna and layout rules, which can save a great deal of test cost.

The carrier board. A SOM is not the end of hardware design. The carrier still needs clean power, protection, connectors, and correct routing for every high speed signal: MIPI CSI, USB 3 and PCIe all need controlled impedance and length matching.

What we have built

We have designed a custom carrier board and operating system that drive USB and MIPI CSI cameras together on one SOM, and our own Mini and Micro compute modules for embedded camera products, with a custom Yocto Linux and camera drivers written for sensors that had none. You can read about them in our compute platforms case study and our note on embedded vision.

There are a lot of options, and it is easy to get lost. If you want a second opinion on which platform your product should be built on, we are happy to help.

Have a design challenge?