The Hidden Costs of Firmware Flashing
By: Mattia Maldini
Tags: Entrepreneurship, Comparison, Embedded Systems, Hidden Cost, Product Design

First of all, the debugging/programming hardware. ST products are famously paired with the ST-Link series of debuggers; the most common ST-Link V2 comes for 20 € on Mouser, but a knock-off can be found on Aliexpress for prices as low as 1.50 $.

Cheap, but effective

For Microchip products, it’s a different story. Their go-to debugger is the relatively new ICD-4, and the toy costs up to 240 €— quite an investment.

They also offer a more affordable option in the form of the PIC-kit 4: just under 50 €. Still twice as much as the ST counterpart.

Recently, they also released a super-cheap alternative, the Microchip SNAP, but it’s so bare bones (not even a case) I wouldn’t recommend it for a professional setting.

When choosing between those two options, you already have an up front difference of ~30 € in costs for every production unit, which can become even more if you are unlucky. In my experience Microchip programmers are very delicate constructs, and we break at least a couple per year just from normal usage. Also, their device support is often incomplete: it’s not uncommon to find out the the newest processors are not supported by some versions of the debugging tools, forcing you to buy a second one.

For now I’ve only listed one-time kickstarting costs, which are easily covered by the first profits. It sucks, but it’s no big deal. The real problem kicks in when you start flashing your custom boards.

Time is Money

By looking at two similar project I realized Microchip programmers are unbelievably slow at their supposed job. I compared the flashing time of two ELF files about the same size (~100 KB each): one for the PIC24FJ128, the other for a STM32F030.

The results? While my ST-Link V2 is done in a mere 8 seconds delay, the ICD3 needs 25 seconds to finish. That’s a three fold difference. This means that anyone assigned to the task of preparing products to be delivered will cost you thrice as much, weighing heavily on the returns.

As a side note — the actual flashing time is more or less the same, about 5 seconds for both. The problem is MPLABX (Microchip’s development environment) takes 20 damn seconds to handshake with the device. I am unsure about what the hell they are chit chatting about, but apparently it’s so important you have to waste a third of a minute on it.

This means that it took me a minimum of one and an half hours to program 200 PIC24 boards, while I could have been done in just 30 minutes if the product mounted an STM32 counterpart.

This is already a sizeable increase, but it’s not over yet. When handling big orders it is appropriate to build a somewhat automated setup to save as much time as possible; while this is generally achievable for most manufacturers, Microchip seems to make a statement in how you should take things slowly.

Zero Flexibility

ST Microelectronics has the simplest possible approach to develop firmware for their products. Any ARM compiler will do to create a binary image, and then they distribute a command line tool to flash it. This is also paired with a complex Code Generator (STMCubeMx) and IDE, but you are not forced to use those.

Unfortunately MPLABX does not allow to time the flashing procedure.

In this way it is fairly easy to setup a flashing workstation from any small device running Linux (looking at you, Raspberry Pi) and a touch display. You can even build a continuous integration system with an headless Jenkins server connected to a protoboard: the changes pushed to the Git repository are automatically tested and validated on real hardware.

This is simply not possible with a PIC family microcontroller. The only way to develop firmware in Microchip’s world is to use their infamous MPLABX IDE, complete with obsolete GUI and long running bugs. There is just no other option to flash a PIC MCU than to use a full blown personal computer, start up a session and painstaikingly flash each device by hand.

If you really need an automated procedure you can implement a custom bootloader for your application, but guess what?