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.