By Bill Lamie
President/CEO, PX5
It’s relatively easy to design an embedded system using an excessively powerful microprocessor with a plentiful amount of memory. However, this is generally not the reality in the resource constrained world of deeply embedded devices.
In our world, even the smallest Bill of Materials (BOM) cost is scrutinized, often down to the last fraction of a penny. That said, it’s sometimes easy to overlook the firmware effect on BOM cost. If your firmware consumes excessive memory and/or processing cycles, you could unwittingly be forcing your design into a more expensive processor.
This increased cost amounts to a hidden per-device royalty. As production volume increases, this hidden royalty can become substantial.
Well, this is somewhat hard to calculate given the great diversity of microprocessors as well as application requirements. However, looking at advertised microprocessor prices for some popular semiconductor providers, a modest jump from 256KB FLASH (64KB RAM) to 384KB FLASH (96KB RAM) can cost up to $1 per microprocessor. Similarly, increasing processing power from 84MHz to 168MHz can add up to another $1. So, it’s pretty easy to increase your BOM cost by $2 solely on microprocessor selection. Of course, this cost can really add up – especially if your device has a large production run.
How can you avoid hidden microprocessor royalties? First, make sure there are clear design targets for your firmware memory consumption and performance. Equally important, make sure the entire development team is working towards these design targets. Otherwise, it’s likely your firmware will bloat and unintentionally force your design into a more expensive microprocessor.
The next most important consideration is to make sure you have the best compiler technology, which usually means a commercial compiler. The GCC compiler generates decent non-optimized code, but nobody trusts the highest level of GCC optimization (-O3). Worse, I’ve recently seen problems using the GCC -O2 optimization level. Regardless, the best commercial compiler generates 20% to 30% smaller code images than GCC, often times paying for itself instantly.
What about the RTOS and middleware? You should also look for RTOS and middleware solutions designed for small footprint and low-overhead execution, since these components typically reside in the same firmware image as your application code. I’ve seen cases where a wasteful RTOS caused a design to use a much more expensive microprocessor. Even though the RTOS used was “free”, it was effectively royalty bearing given the hidden royalty it introduced.
Avoiding hidden royalties largely amounts to awareness and planning, which includes due diligence in selecting the best compiler, RTOS, and middleware. Look at the total cost/benefit of each component rather than just the up-front cost – remembering that “free” can actually be expensive in the long run.
With proper planning and tools, your firmware can fit into the smallest possible microprocessor, thereby avoiding hidden royalties.