One of the great things about software, compared with hardware, is the ease with which it may be changed and updated. The big downside of software is also the ease with which it can be changed. This ease can make software developers lazy, as they know that they can always fix things later. This is a sharp contrast to chip developers who are fearful of errors, as an ASIC respin is both time consuming and very expensive.
On a desktop computer, updates to system and application software seem to come thick and fast, giving vendors the opportunity to provide us with new features, fix old bugs and introduce new and interesting ones. For embedded systems, the matter is a little more complex …
Years ago, embedded system software [firmware] was burned into a PROM and inserted into a socket in the target system. Later changes to software simply involved the swapping of PROMs. I say “simply”, but it could be far from simple, as several pitfalls were possible:
- Getting the right PROMs in the right sockets [the right way around].
- Finding PROMs had been soldered on to the board to cut costs.
- The system has shipped to numerous customers …
Nowadays, matters are generally eased because the majority of embedded systems keep their code in flash memory, which can normally be reprogrammed in situ. There are broadly 3 ways that the updated code might be transferred to the device:
If the embedded device is connected to the Internet or even just to a LAN, there are a selection of possible ways to implement software updates. This is somewhat similar to the situation with desktop computers.
Wireless connectivity gives other options. If it is a network connection, the same opportunities are available as with a wired network. But there are also other possibilities. A set top box or video recorder might receive updates via TV transmissions. A spacecraft [on the surface of Mars, for example] might receive updates via the NASA Deep Space Network.
For those of us still on planet Earth, a common connectivity option is USB, topic that I have written on before. There is a USB device class called Device Firmware Upgrade [DFU], which defines a protocol for sending new firmware to a device.
The details of DFU operation are well documented and quite complex, but the basic principle is quite straightforward. If a device supports DFU, it advises the host of this fact during enumeration. The device then operates in two distinct modes: “normal” mode and DFU mode. When the device is connected to the host, it appears to be a normal peripheral. For example, a keyboard would appear to be a normal HID class device and be connected to the appropriate host driver. When the device enters DFU mode, it disconnects from the host, then reconnects as a DFU device and is associated with the host DFU driver, which manages the update transfer.
A small downside of DFU is that no standard Windows driver is provided. However, drivers are available from other sources.