Programmable logic added yet another development tool to the coding process. Most programmable logic vendors provided free or low cost logic compilers. Development tools such as PALASM and ABLE were distributed freely by silicon vendors or developers could purchase a tool such as CUPL from Logical Devices. CUPL was not vendor specific so one could target different vendor’s devices during the development phase.
Back in these early days, schematics were drawn on paper using pencil, schematic symbol templates, and lettering machines. Most good engineers, when using a microprocessor/microcontroller, would actually add the hex addresses to the devices connected to the microcontroller bus. This was a useful aid for the engineers ultimately responsible for developing the firmware.
Hand-drawn paper-based schematics served their purpose but posed a number of problems. Mistakes had to be erased and redrawn. Sometimes a majority of the schematic had to be redrawn just to fit the updated circuit change. Then, once a schematic was completed, reviewed, and signed off by a peer review group, a set of blue lines were made and then distributed to the appropriate groups.
PCB layouts were typically done by placing pads down on clear vellum and connections made between pads with black tape of various widths. While the printed circuit boards were being laid out, prototype circuits were built using point-to-point wiring or wire-wrapping techniques – a long and tedious task. (Obviously not a good method for building reliable high-speed circuits.)
While the prototype hardware was being built and the printed circuit boards were in layout, firmware and software developers could, for the most part, begin developing boot code, hardware drivers, power-up self-diagnostics, and application code. This was the fun part since no true method of instruction set simulation or in-circuit emulation existed. Debugging was accomplished using the crash-and-burn method. Code was burned to an EPROM (a windowed programmable memory device that could be erased after exposure to ultraviolet light). Once a firmware bug was found, the designer would attempt a fix, re-assemble the code, burn another EPROM, and test the system again. If it hit another bug and the system crashed, the designer would perform another round of crash-and-burn testing. A firmware developer would keep a rail of erased EPROM’s on hand to speed up crash-and-burn testing given how long they took to erase.
To read the entire article, click here.