标签: circuits

A few days ago, I caught a scene of a science-fiction film made in the 1950s. It took place in a factory of the future, with a control room lined with a wall of large, dedicated, single-function switches clearly labeled "furnace on", "main conveyor" and so on, just as real factories were designed and built in the days when that movie was made. A mechanical switch directly controlled a circuit loop which provided power to a corresponding actuator, and the reality would be lots of switches, wires, and control loops. Zip ahead to the 21 st century and control panels didn't quite turn out that way. Even if there is a labeled switch, it most likely is not directly wired into or part of the control loop. Instead, it is sensed by an I/O port on the system controller, a switch press is detected and assessed via software (some debounce is needed here, most likely) and actions are taken based on the control program. Taking it one step further, in many designs, the switch function is actually "soft", and will change depending on what is going on and what a display screen label says that switch is for, at that time. If there are a lot of switches, they may be on some sort of internal, low-end network or matrix rather than having one input pin dedicated to each switch-closure contact. It's not just factory control rooms, either: today's car's no longer have direct loops between functions such as window controls and the window motor; instead, the switch is sensed by a LAN, interpreted by a MCU, and desired actions are sent out by the MCU via the same LAN. This makes sense, since it saves wiring (cost, weight, space) and provides design flexibility in locating switches (and re-locating them if design needs change). Even hobbies such as model railroading have gone "network", via the widely adopted digital command control (DCC) standard. These changes haven't stopped at sensing via I/O lines or networks, either, as the rise of now-ubiquitous touch screen and GUI have given us non-switch-based controls. The screen shows us images or buttons, and we touch it in the appropriate place. It's very efficient in terms of switches (none needed), I/O sensing (none needed), and flexibility (lots). But there's a downside to the indisputable efficiency of the soft key and touch screen approaches: it's a much longer path, functionally, from initiation to final action. Perhaps we feel more removed from the consequences of our actions and how they are implemented; that's a psychological aspect which is hard to assess. Beyond psychology, though, there's more that has to go right and more than can go wrong with these newer approaches, of course. Further, it's hard to really know what is going on and troubleshoot it, if needed (and it will be). In those ancient days, if something didn't work, you could take a basic meter and check out the switch itself, then the loop, the power supply, and the actuator, end of story. It was all basic power and continuity testing, and fairly straightforward. Even better, if something failed, you could either fix it or rig a temporary bypass using another switch, or loop circuit. With today's completely flexible, touch-screen based systems, it's—as the song goes—all or nothing at all. I know we're not going back, nor should we: the wiring virtues of the I/O-port or network-based switch, and flexibility of the touch-screen user interface are simply overwhelming for most products, both at the BOM level and system-design level. But along with virtue comes shortcomings, and we should keep those in mind, as well. I think I'll stick with that big, red, mushroom-topped "kill" switch for critical situations. Where do you think we should retain hardwired, direct-control mechanical switches and controls?  

Younger people are not much interested in electronic-circuit design and hands-on engineering. That's because active and passive components are too small to handle, probe, swap, and generally do much with—unless you are a pick-and-place machine or bed-of-nails prober. Yes, we have seen articles explaining how a skillful amateur can load and solder those high-density PC boards with ICs whose leads are under the package and passives almost too small to see. But reality is that it is fairly hard and unforgiving, and even if you are successful, it's pretty much impossible to poke and probe. And if you decide you want to try a different resistor in that circuit. . . well, good luck on removing and replacing the grain-of-pepper one that is soldered down. But there's still hope out there. The other day, I received a printed—yes, printed—catalog from a company that provides all sorts of electronic and electromechanical components for hobbyists and professional prototypes. Some of these components were new, while others (such as motors and gearboxes) were likely removed from equipment or a supplier's overstock; almost all were interesting. This particular catalog was from All Electronics Corp. (click here ) but there are many other supply houses out there with similar offerings. And what joy it was, to thumb through the pages. There were small and fractional-horsepower motors (AC and DC), gearbox assemblies, rocker and toggle switches, multipole relays, LEDs in various configurations, specialty items such as a switch which trips a tiny amount of air pressure, and much more. The joy wasn't just nostalgia, which is a non-starter in our industry. All the items displayed and detailed on the pages combined to stimulate ideas and remind me of the possibilities of what you could actually build, touch, adjust, poke around in, reconfigure, and more. Almost everything could actually be handled, soldered or wired to, resoldered and rewired, reconfigured, and in general, be real and tangible. So go ahead, go to the web site of this company or others like it, or even better, get your hands on a paper catalog. It will confirm that there is still an opportunity for the joy of discovery. You can plan do-it-yourself construction of circuits and systems with human-sized parts, with motors and switches and lights than do and mean something, and which provide a hard-to-explain—but very real—sense of satisfaction. Just looking at those motors and switches, I could see some potential projects might want to try. Is my point valid? Or am I just longing for a time and type of hands-on project that is gone, and no longer realistic? Do you have a similar supply house/source you use?  

In an article on EET/Embedded.com titled "I Don't Need No Stinkin' Requirements" author Jon Pearson writes about the all-too-real issue of dealing with changing requirements. He goes on to outline some very useful steps for handling such changes as the project proceeds.   But I take issue with the underlying philosophy, which is becoming nearly a universal scream in this industry, that requirements cannot be known more or less up front.   In my 35+ years in the embedded world I've seen that requirements don't change. At least not to the extent experienced by people doing, say, web design. Sure, there are tweaks and additional feature requests. And, yes, rarely a revolutionary twist requires a major redesign. But more often the requirements changes we moan about are a product of poor requirements gathering.   There's a meta-meme at work, one that's ever-more prevalent in today's vicious political arena. As an engineer I'm constantly appalled to listen to some pundit or soon-to-be convicted politician expound on how we should fix X, where X is really a symptom of some problem. Focusing on symptoms is like bailing a leaking boat. Better: plug the hole first.   And that's the issue here. Do a poor job at eliciting requirements and the symptom will be a never-ending scramble to patch up the project. Band-aids instead of avoiding the injury in the first place.   In the embedded world, poor requirements gathering is endemic. We jump in and start writing code and designing circuits far too early. Some agilists commend this practice; I think it's a mistake.   In many cases we blame outside forces. The boss wants us to start today. Marketing keeps making changes ( see my thoughts on that in "Listening to your customers." ).   There are truly forces at work that may be insurmountable, but all-too-often we're culprits as well, either in our zeal to get started or our unwillingness to educate the other stakeholders.   Shockingly, many of us know little about requirements gathering. Have you read a single book on the subject? Few of us have. ( My favorite is Karl Wiegers' " Software Requirements ." ). I scanned the course catalogs of several universities and found not a single CS or EE course title or description that contains the word "requirements."   Yes, of course requirements change, and we need strategies for coping. But we have a responsibility to do a great job on eliciting them at the outset to insure the project doesn't collapse.   I'm reminded of an old parable: In ancient China there was a family of healers, one of whom was known throughout the land and employed as a physician to a great lord. The physician was asked which of his family was the most skillful healer. He replied, " I tend to the sick and dying with drastic and dramatic treatments, and on occasion someone is cured and my name gets out among the lords.   "My elder brother cures sickness when it just begins to take root, and his skills are known among the local peasants and neighbors.   "My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His name is unknown outside our home."   There is no glory in getting the requirements right at the outset, but it's the essence of great engineering.    

In an article on EET/Embedded.com titled "I Don't Need No Stinkin' Requirements" author Jon Pearson writes about the all-too-real issue of dealing with changing requirements. He goes on to outline some very useful steps for handling such changes as the project proceeds.   But I take issue with the underlying philosophy, which is becoming nearly a universal scream in this industry, that requirements cannot be known more or less up front.   In my 35+ years in the embedded world I've seen that requirements don't change. At least not to the extent experienced by people doing, say, web design. Sure, there are tweaks and additional feature requests. And, yes, rarely a revolutionary twist requires a major redesign. But more often the requirements changes we moan about are a product of poor requirements gathering.   There's a meta-meme at work, one that's ever-more prevalent in today's vicious political arena. As an engineer I'm constantly appalled to listen to some pundit or soon-to-be convicted politician expound on how we should fix X, where X is really a symptom of some problem. Focusing on symptoms is like bailing a leaking boat. Better: plug the hole first.   And that's the issue here. Do a poor job at eliciting requirements and the symptom will be a never-ending scramble to patch up the project. Band-aids instead of avoiding the injury in the first place.   In the embedded world, poor requirements gathering is endemic. We jump in and start writing code and designing circuits far too early. Some agilists commend this practice; I think it's a mistake.   In many cases we blame outside forces. The boss wants us to start today. Marketing keeps making changes ( see my thoughts on that in "Listening to your customers." ).   There are truly forces at work that may be insurmountable, but all-too-often we're culprits as well, either in our zeal to get started or our unwillingness to educate the other stakeholders.   Shockingly, many of us know little about requirements gathering. Have you read a single book on the subject? Few of us have. ( My favorite is Karl Wiegers' " Software Requirements ." ). I scanned the course catalogs of several universities and found not a single CS or EE course title or description that contains the word "requirements."   Yes, of course requirements change, and we need strategies for coping. But we have a responsibility to do a great job on eliciting them at the outset to insure the project doesn't collapse.   I'm reminded of an old parable: In ancient China there was a family of healers, one of whom was known throughout the land and employed as a physician to a great lord. The physician was asked which of his family was the most skillful healer. He replied, " I tend to the sick and dying with drastic and dramatic treatments, and on occasion someone is cured and my name gets out among the lords.   "My elder brother cures sickness when it just begins to take root, and his skills are known among the local peasants and neighbors.   "My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His name is unknown outside our home."   There is no glory in getting the requirements right at the outset, but it's the essence of great engineering.