ne question I’m often asked is how to pick an embedded system on a chip (SoC) for a given project. It’s a tricky multidimensional optimisation problem, trading off cost, features, availability, and performance. Evaluating an embedded SoC based solely upon its datasheet and price misses one of the most significant hidden costs: firmware. Peripherals are useless without stable drivers and/or good documentation, and a poor compiler can waste significant amounts of memory and performance.
Firmware support can be a significant portion of a chip’s R&D budget. This is why SoCs with good firmware support sometimes seem underwhelming in performance and price: it can take many man-years of effort to mainline a complex SoC into the Linux kernel. At the other extreme, some SoC vendors basically cram as many features as they can into a chip, hoping to lure a big customer. Only after a significant volume order has been inked does the company start throwing resources at fleshing out the firmware.
"Evaluating an SoC based solely upon its datasheet and price misses significant hidden costs"
By economising on firmware developers, these chips can sell at rock-bottom price, and the documentation is strictly NDA. The NDA is important because, as firmware is developed, bugs are eventually identified and the NDA allows the chip vendor to hide the existence of the bugs from new customers, investors, and potential legal actions. This practice of taping out silicon and just-in-time developing the firmware, based on a high-volume customer’s needs, explains why, in general, it’s very hard for small-time makers and startups to access some of the more interesting SoCs.
Thus, my usual advice to folks looking to pick an SoC is to first code up a simple demo representative of the workload and I/O footprint, and then port the demo to development boards provided by the vendor. The difficulty of getting the toolchain up and running, as well as the general maturity of the firmware, will become painfully clear within a couple days of effort. Although repeating this process for a few SoCs will burn a couple of weeks of time, it can save months of fighting with buggy silicon, fixing drivers, and hand-optimising code.
The other important aspect to check is the availability of the specific part number you’ve chosen. Distribution support will be important, especially if your initial builds are smaller than 10 000 units. A single 300 mm wafer might yield several thousand Cortex-M series SoCs, and a fabrication plant typically processes wafers in lots of 25. So, a few thousand units may be a big deal to a startup, but it’s tiny for a silicon vendor.
This story is an excerpt from HackSpace magazine Issue #14. Interested in regular updates from the world of making? Join thousands of other readers in becoming a HackSpace magazine subscriber.