标签: rails

Jim Williams, the late and greatly missed analogue-circuit expert, used to say that a good schematic diagram was itself a work of art, which in turn captured and revealed the intricacies and subtleties of a circuit design. He was right, of course, and I realised this the other day when I was looking at the schematic of a basic alarm controller from about 30 years ago (no need to explain here why I was doing this). Due to the application, this design was largely analogue and basic digital ICs, with lots of I/O points and just a small microcontroller function. What struck me about this schematic was how poorly drawn it was: Signal lines and power rails crossed themselves and each other like a bowl of spaghetti. As far as I could tell, it was technically correct, but both visually confusing and hard to use for any sort of troubleshooting. Why was it so poorly done? I have no idea: Perhaps someone with no EE background drew it; perhaps the engineer who did it was in a rush and didn't care; or perhaps it was adapted from a crude hand-drawn sketch. (I won't blame this on a CAD/EDA program, since it did not at all have the look of being computer-sourced.)     This circuit, from a 1992 EDN Design Idea, measures alternating current or voltage and transmits the results on a 4- to 20-mA current loop. One of the reasons I prefer to look at older schematics is that they are mostly analogue and so have little or no processing core. Thus, single-handedly or in conjunction with a block diagram, they can reveal most the circuit's functions and operation. In these schematics , the signal flows like a stream from left to right beginning at the input(s), then gets caught in various eddies and pools of sub-circuits for filtering, calibration, compensation, thresholds, oscillation, mixing, modulation/demodulation, and other functions before it emerges at the right side, going into the open world as an output signal. Look at the schematic of an early six-transistor AM radio , which supplanted the classic 5-tube AM radio ; or check out the much more complex AN/ASQ-1A tube-based magnetometer (pages numbered 9 and 13), and you'll see what I mean. In contrast, in designs that are heavily centred on their processor/software, it's hard to establish any signal-processing flow. Much of the real "action" (functionality) takes place in the mysterious CPU section—which is largely a magical black box, unless you study the code. A well-drawn schematic not only gives you the facts of the circuit, it also tells the story of the circuit. The same guideline applies to software documentation, too, of course: A good code listing not only gives you the instructions to be executed, but tells what the intention of the code is at various blocks and junctions. Hardware and software engineers who don't provide meaningful, well-done documentation are not only hurting themselves and the "next guy" who has to deal with the design—and there usually is a next guy—but they are also making themselves look bad. After all, you wouldn't be impressed by an article or technical paper that was full of misspellings, fractured sentences, and semi-coherent ramblings.