In 2012, I wrote about how mobile application processors were becoming increasingly popular in embedded systems. Since then, this trend has accelerated, fueled in part by low-cost development boards aimed at enabling embedded system developers to evaluate these chips and quickly create prototype products.
For embedded systems developers, these boards (some developed by chip suppliers and some from their partners) can seem like a dream come true: they're inexpensive and energy-efficient, and they offer impressive features and performance. But working with these boards often puts me in the mind of Dickens' famous passage "It was the best of times, it was the worst of times." On the one hand, these boards are easy to obtain and easy to get started with. (Where "getting started" is typically defined as compiling some code to run on the CPU.)
On the other hand, developers trying to do more-sophisticated work with these boards can easily find themselves stymied. I see this most frequently in two areas: compute acceleration and I/O interfaces.
One of the keys to mobile application processors' impressive performance/cost ratios and energy efficiency is the extensive use of heterogeneous processing: In addition to a multi-core CPU, mobile application processors include a bevy of more-specialized programmable and fixed-function processing blocks. These include GPUs that can be used as general-purpose parallel processors, video encode/decode engines, DSPs (often used for audio and sensor signal processing), and image signal processors (used to improve images captured by the image sensors).
By virtue of their specialization, these co-processors deliver much better cost-performance and energy efficiency than the main CPU (for certain sets of tasks). Therefore, utilizing the full capabilities of mobile processor chips (or anything approaching their full capabilities) requires harnessing these special-purpose engines. But doing so typically requires specialized knowledge, development tools and APIs. Unfortunately, mobile application processors often don't make the necessary software and documentation generally available.
Similar challenges abound when developers utilize sophisticated I/O interfaces and system control capabilities on mobile application processors. For example, in the past few weeks, one BDTI client has struggled with an incompatible USB3 port on one mobile SoC development board, and buggy power-management firmware on another.
So, while building code for the CPU (which is usually a multi-core ARM) on a mobile SoC tends to be straightforward, building and integrating code that uses specialized co-processors and I/O interfaces is often an exercise in guesswork and frustration. This problem is exacerbated by the fact that while Linux is the default operating system of choice for many kinds of embedded systems, Android is the most important operating system in mobile devices. As a result, software development infrastructure for mobile processors is excellent for Android, but often spotty for Linux.
Why aren't mobile SoCs better supported for embedded systems? That's a tale of two industries: the mobile chip business is driven by huge volumes, and is extremely concentrated (a few huge customers dominate demand). In contrast, the embedded systems business is driven by lower volumes (though with higher margins) spread across thousands of customers. Mobile chip suppliers are simply not staffed and organized to provide support for thousands of customers pursuing diverse applications.
As growth opportunities shrink in mobile phones and tablets, however, some mobile processor suppliers are investing in embedded applications. Rather than try to quickly ramp up to engage with hundreds or thousands of customers, some suppliers are carefully choosing a modest number of embedded systems customers to support. That's an understandable strategy – but to succeed with just a handful customers requires being able to pick the winners well ahead of the finish line – a difficult proposition.
In contrast, suppliers with the fortitude to make the larger investments required to support large numbers of customers will be planting many seeds – and some of those seeds will grow into big opportunities.