Software is free and can right any wrong

• Software Development
• Hardware Development
• System Design

An embedded system is comprised of some hardware and some software. These are typically both designed by very talented developers using methodologies that are, superficially at least, quite similar. However, a key difference is that if an error is found in software, it is commonly much easier to fix than a similar hardware bug. Indeed, if a system has a problem and there is a choice between fixing it in software or hardware, more often than not, a software fix is chosen. This always seems unfair on the software developers as their careful design might be compromised because of an error made by their colleagues down the hall.

The idea that software is very easy to create and modify gives rise to a view that it is, effectively, free. After all, adding a new chip to a system would cost $X per unit shipped, whereas a bit more software has no impact on the unit cost. This perspective results in some interesting trade-offs. What hardware can be replaced with some software? It turns out that, if you really need to, many devices can have their functionality provided by some software. For example, if you need a flashing LED [perhaps with a variable rate or duty cycle], you could use a simple oscillator chip [Are 555s still used? I remember when that chip was first announced.] Alternatively, the microprocessor could drive the LED using a timer interrupt service routine and a PIO port, which would introduce minimal overhead. One step greater in complexity would be to replace a UART in the same fashion, having the microprocessor crank out the bit stream. Wind up the complexity even more and perhaps Ethernet signals could be generated by software. However, there are limits!

Many [about 40!] years ago, I was working on a project using one of the first 16-bit microprocessors [the TI9900]. It was an amazing device, with an instruction set based somewhat on the DEC PDP-11 and some built-in multi-tasking support. The system we were working on was a complex hydraulic machine that had traditionally be controlled using a large console, with numerous dials, button, meters and flashing lights. The goal was to reduce the user interface to a screen and a keypad [too early for a trackpad or a mouse] and integrate some automation. When I was learning to program the machine, I heard many jokes about how it looked a lot like a Space Invaders game that was popular at the time. As you might guess, I could not resist the temptation to implement a simple version of the game as an exercise. I was very sternly told that this must never be seen by a customer or they would never take the new approach seriously!

The hardware guys were excited that they could simplify a lot of the system using this advanced design, particularly because, if they decided not to implement something in the hardware, they could “delegate” it to software. The software guys were equally excited - drunk with power - at what the microprocessor could do. As a result, they agreed to almost any request for new functionality. You can probably guess at the outcome. The system reached a point where the software was brought to its knees and could not keep up with the real-time demands of such a control system. A significant design review was necessitated and [I hope!] some lessons learned.

In an electronic world increasingly dominated by programmable logic, the rules change somewhat. Is it faster to tweak the software or reprogram an FPGA … ?

Sign in