05-26-2021, 06:28 PM
Back in the halcyon days of computing, we had hardware, software, and in between, firmware. Firmware was the programmable aspect of the hardware. Originally, firmware instructions could be written once into programmable parts, and that was that. Programmable Read only Memory was known as PROM. According to Wikipedia, it was invented in the '50s, but it became important in the '70s as the repository of the permanent code for microprocessors. Masked ROM could be manufactured with the programming built in, but that involved big upfront expenses and long lead times. Masked ROM has always been the lowest cost firmware for high volume applications, but it is prohibitively expensive for other uses.
Erasable parts, called EPROMs also appeared in the 70's. These parts could be erased through a quartz window by UV light. Then, the same part could be reprogrammed to suit. To reprogram a part, it was first placed in an eraser, which included a strong UV source, and usually a timer. After many minutes (depending on the part and the intensity of the UV light), the memory would be checked to see if it was blank. If so, it was ready for reprogramming. Parts were capable of only a limited number of program/erase cycles, but the erasable technology made firmware development considerably less stressful. Still, there was a real premium on getting it right in the smallest number of iterations.
Prototype systems would be built with EPROM chips, but they were more expensive, and could lose their data over time. Production systems would use PROM or masked ROM for economy and reliability. This arrangement worked pretty well for a number of years. A PROM or ROM would hold the BIOS for your home computer and a keyboard PROM or ROM would hold the translation between keycodes and pixels for the alphanumeric display.
EEPROM, or Electrically Erasable Read Only Memory, was the next phase of development. Your USB memory stick is the modern form of this rather elegant technology. That USB stick uses flash memory, which is a form of EEPROM that was first commercialized in the '80s. Flash has been improved to the point that electrically erasable memory can replace a hard drive. That is a long way from 20 minutes in the UV eraser before rewriting.
When combined with internet accessibility, EEPROM memory enables field reprogrammability. Our computers are now almost all connected, and more and more of our infrastructure is network-connected, too. We have become accustomed to over-the-air firmware updates for our phones, computers, networking systems, etc. Those updates remove the need to complete product development before beginning production. Once you are close, you know you can fix it later, with an update. The developer can add features and fix bugs long after the product is shipped. The update process can be beneficial, but it is also corrosive. There is no longer a need to get it right the first time, or even the second time. In fact, the constant parade of patched problems has become a feature. It is called software as a service. The product is no longer an entity, it is a continually morphing work in progress.
In the above process, it has become more and more difficult to make the distinction between firmware and software. Maybe that distinction is becoming irrelevant, but the recent increase in the number of malicious hacks into supposedly secured systems makes me think otherwise. Mistakes find their way into the firmware that sits beneath the application code. That firmware is rarely examined. The deeper code is buried, the harder it is to sort out the rules and assumptions for its function. Code at the lower levels should be thoroughly debugged, tested and documented. Only then can it be safely forgotten. When a breach allows that underlying code to be exposed to hackers who can actually change it, good luck ever figuring out what went wrong after you have paid the ransom to recover your data.
Further, when bugs find their way into low-level code, they have a sneaky way of propagating. One of the early BASIC language implementations had a bug in the PEEK statement. PEEK was a command to read an 8-bit byte from a memory address. PEEK mistakenly treated the result as a signed 7-bit integer. Anything over 127 was shown as a negative number. That made a mess when reading A/D converter data. You might think a problem like that would be corrected promptly and permanently. In fact, that same problem turned up in several completely different versions of BASIC from different companies, even five years later. So when problems appear at the lowest levels of embedded code, watch for more trouble in the future. Thanks largely to flash memory, even the hackers don't know all the places their backdoor access may be installed.
Tom Lawson
May 2021
Erasable parts, called EPROMs also appeared in the 70's. These parts could be erased through a quartz window by UV light. Then, the same part could be reprogrammed to suit. To reprogram a part, it was first placed in an eraser, which included a strong UV source, and usually a timer. After many minutes (depending on the part and the intensity of the UV light), the memory would be checked to see if it was blank. If so, it was ready for reprogramming. Parts were capable of only a limited number of program/erase cycles, but the erasable technology made firmware development considerably less stressful. Still, there was a real premium on getting it right in the smallest number of iterations.
Prototype systems would be built with EPROM chips, but they were more expensive, and could lose their data over time. Production systems would use PROM or masked ROM for economy and reliability. This arrangement worked pretty well for a number of years. A PROM or ROM would hold the BIOS for your home computer and a keyboard PROM or ROM would hold the translation between keycodes and pixels for the alphanumeric display.
EEPROM, or Electrically Erasable Read Only Memory, was the next phase of development. Your USB memory stick is the modern form of this rather elegant technology. That USB stick uses flash memory, which is a form of EEPROM that was first commercialized in the '80s. Flash has been improved to the point that electrically erasable memory can replace a hard drive. That is a long way from 20 minutes in the UV eraser before rewriting.
When combined with internet accessibility, EEPROM memory enables field reprogrammability. Our computers are now almost all connected, and more and more of our infrastructure is network-connected, too. We have become accustomed to over-the-air firmware updates for our phones, computers, networking systems, etc. Those updates remove the need to complete product development before beginning production. Once you are close, you know you can fix it later, with an update. The developer can add features and fix bugs long after the product is shipped. The update process can be beneficial, but it is also corrosive. There is no longer a need to get it right the first time, or even the second time. In fact, the constant parade of patched problems has become a feature. It is called software as a service. The product is no longer an entity, it is a continually morphing work in progress.
In the above process, it has become more and more difficult to make the distinction between firmware and software. Maybe that distinction is becoming irrelevant, but the recent increase in the number of malicious hacks into supposedly secured systems makes me think otherwise. Mistakes find their way into the firmware that sits beneath the application code. That firmware is rarely examined. The deeper code is buried, the harder it is to sort out the rules and assumptions for its function. Code at the lower levels should be thoroughly debugged, tested and documented. Only then can it be safely forgotten. When a breach allows that underlying code to be exposed to hackers who can actually change it, good luck ever figuring out what went wrong after you have paid the ransom to recover your data.
Further, when bugs find their way into low-level code, they have a sneaky way of propagating. One of the early BASIC language implementations had a bug in the PEEK statement. PEEK was a command to read an 8-bit byte from a memory address. PEEK mistakenly treated the result as a signed 7-bit integer. Anything over 127 was shown as a negative number. That made a mess when reading A/D converter data. You might think a problem like that would be corrected promptly and permanently. In fact, that same problem turned up in several completely different versions of BASIC from different companies, even five years later. So when problems appear at the lowest levels of embedded code, watch for more trouble in the future. Thanks largely to flash memory, even the hackers don't know all the places their backdoor access may be installed.
Tom Lawson
May 2021