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 the embedded world, cost is scrutinized in even the smallest bill of materials (BOM), often down to a fraction of a penny per device. That said, it’s sometimes easy to overlook the effect of bloated firmware on BOM cost. If your firmware consumes excessive memory and/or processing cycles, you could unwittingly be forcing your hardware design into a more expensive processor.
This increased hardware cost amounts to a hidden per-device royalty. As production volume increases, this hidden royalty for hardware 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 caused by firmware bloat? 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 for embedded systems, 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 paying for itself instantly.
What about the RTOS and middleware? You should also look for embedded 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 an embedded system design to use a much more expensive microprocessor. Even though the RTOS used was “free”, it was effectively royalty bearing given the hidden hardware royalty it introduced.
Avoiding hidden royalties largely amounts to awareness and planning, which includes due diligence in selecting the best compiler, the best embedded RTOS, and the best embedded middleware. Look at the total cost/benefit of each component rather than just the up-front cost – remembering that “free” software can actually result in expensive hardware in the long run.
With proper planning and embedded software tools, your firmware can fit into the smallest possible microprocessor, thereby avoiding hidden hardware royalties.