About C. J. Abate

C. J. Abate is Circuit Cellar's Editor in Chief. You can reach him at cabate@circuitcellar.com and @editor_cc.

Infrared Communications for Atmel Microcontrollers

Are you planning an IR communications project? Do you need to choose a microcontroller? Check out the information Cornell University Senior Lecturer Bruce Land sent us about inexpensive IR communication with Atmel ATmega microcontrollers. It’s another example of the sort of indispensable information covered in Cornell’s excellent ECE4760 course.

Land informed us:

I designed a basic packet communication scheme using cheap remote control IR receivers and LED transmitters. The scheme supports 4800 baud transmission,
with transmitter ID and checksum. Throughput is about twenty 20-character packets/sec. The range is at least 3 meters with 99.9% packet receive and moderate (<30 mA) IR LED drive current.

On the ECE4760 project page, Land writes:

I improved Remin’s protocol by setting up the link software so that timing constraints on the IR receiver AGC were guaranteed to be met. It turns out that there are several types of IR reciever, some of which are better at short data bursts, while others are better for sustained data. I chose a Vishay TSOP34156 for its good sustained data characteristics, minimal burst timing requirements, and reasonable data rate. The system I build works solidly at 4800 baud over IR with 5 characters of overhead/packet (start token, transmitter number, 2 char checksum , end token). It works with increasing packet loss up to 9000 baud.

Here is the receiver circuit.

The receiver circuit (Source: B. Land, Cornell University ECE4760 Infrared Communications
for Atmel Mega644/1284 Microcontrollers)

Land explains:

The RC circuit acts a low-pass filter on the power to surpress spike noise and improve receiver performance. The RC circuit should be close to the receiver. The range with a 100 ohm resistor is at least 3 meters with the transmitter roughly pointing at the receiver, and a packet loss of less then 0.1 percent. To manage burst length limitations there is a short pause between characters, and only 7-bit characters are sent, with two stop bits. The 7-bit limit means that you can send all of the printing characters on the US keyboard, but no extended ASCII. All data is therefore sent as printable strings, NOT as raw hexidecimal.

Land’s writeup also includes a list of programs and packet format information.

Electrostatic Cleaning Robot Project

How do you clean a clean-energy generating system? With a microcontroller (and a few other parts, of course). An excellent example is US designer Scott Potter’s award-winning, Renesas RL78 microcontroller-based Electrostatic Cleaning Robot system that cleans heliostats (i.e., solar-tracking mirrors) used in solar energy-harvesting systems. Renesas and Circuit Cellar magazine announced this week at DevCon 2012 in Garden Grove, CA, that Potter’s design won First Prize in the RL78 Green Energy Challenge.

This image depicts two Electrostatic Cleaning Robots set up on two heliostats. (Source: S. Potter)

The nearby image depicts two Electrostatic Cleaning Robots set up vertically in order to clean the two heliostats in a horizontal left-to-right (and vice versa) fashion.

The Electrostatic Cleaning Robot in place to clean

Potter’s design can quickly clean heliostats in Concentrating Solar Power (CSP) plants. The heliostats must be clean in order to maximize steam production, which generates power.

The robot cleaner prototype

Built around an RL78 microcontroller, the Electrostatic Cleaning Robot provides a reliable cleaning solution that’s powered entirely by photovoltaic cells. The robot traverses the surface of the mirror and uses a high-voltage AC electric field to sweep away dust and debris.

Parts and circuitry inside the robot cleaner

Object oriented C++ software, developed with the IAR Embedded Workbench and the RL78 Demonstration Kit, controls the device.

IAR Embedded Workbench IDE

The RL78 microcontroller uses the following for system control:

• 20 Digital I/Os used as system control lines

• 1 ADC monitors solar cell voltage

• 1 Interval timer provides controller time tick

• Timer array unit: 4 timers capture the width of sensor pulses

• Watchdog timer for system reliability

• Low voltage detection for reliable operation in intermittent solar conditions

• RTC used in diagnostic logs

• 1 UART used for diagnostics

• Flash memory for storing diagnostic logs

The complete project (description, schematics, diagrams, and code) is now available on the Challenge website.

 

CC270: Forward Progress

As you might have noticed, parts of this issue look a bit different than the publication you’re used to reading. You can see a slightly updated layout, some different colors, and a few new sections. We’ve made these changes to reflect where we are today and where we’re taking this magazine in the months to come. It’s all about forward progress. Here are the broad strokes:

FRESHENED UP LAYOUT

We’re planning an exciting layout redesign for 2013. The layout will be modern, clean, and engaging, but its fonts and colors won’t distract you from what you’re reading—professional engineering content. Since the new layout is still an issue or two away, we’re presenting you with this freshened up issue to mark the transition to 2013. We hope you like the changes.

CLIENT PROFILES

On page 20 you’ll find a new section that will appear frequently in the coming months. The purpose of our client profiles is to shine a light on one company per month and bring you an exclusive offer for useful products or services.

TECH THE FUTURE

Last month we ran Steve Ciarcia’s final “Priority Interrupt” editorial. This month we’re introducing a new section, “Tech the Future.” The EE/ECE community is on the verge of major breakthroughs in the fields of microcomputing, wireless communication, robotics, and programming. Each month, we’ll use page 80 to present some of the fresh ideas, thought-provoking research projects, and new embedded design-related endeavors from innovators who are working on the groundbreaking technologies of tomorrow.

CC25

You’ll soon have Circuit Cellar’s 25th (“CC25”) anniversary issue in your hands or on your PCs or mobile devices. Here are just a few of the exciting topics in the issue: Circuit Cellar in 1988, design/programming tips, engineers’ thoughts on the future of embedded tech, and much more. It’s going to be a classic.

Well, there’s certainly a lot of publishing-related innovation going on at our headquarters. And I know you’re equally busy at your workbenches. Just be sure to schedule some quiet time this month to read the articles in this issue. Perhaps one of our authors will inspire you to take on your first project of the new year. We feature articles on topics ranging from an MCU-based  helicopter controller to open-source hardware to embedded authentication to ’Net-based tools for energy efficiency. Enjoy!

Electrical Engineering Tools & Preparation (CC 25th Anniversary Issue Preview)

Electrical engineering is frequently about solving problems. Success requires a smart plan of action and the proper tools. But as all designers know, getting started can be difficult. We’re here to help.

You don’t have to procrastinate or spend a fortune on tools to start building your own electronic circuits. As engineer/columnist Jeff Bachiochi has proved countless times during the past 25 years,  there are hardware and software tools that fit any budget. In Circuit Cellar‘s 25th Anniversary issue, he offers some handy tips on building a tool set for successful electrical engineering. Bachiochi writes:

In this essay, I’ll cover the “build” portion of the design process. For instance, I’ll detail various tips for prototyping, circuit wiring, enclosure preparation, and more. I’ll also describe several of the most useful parts and tools (e.g., protoboards, scopes, and design software) for working on successful electronic design projects. When you’re finished with this essay, you’ll be well on your way to completing a successful electronic design project.

The Prototyping Process

Prototyping is an essential part of engineering. Whether you’re working on a complicated embedded system or a simple blinking LED project, building a prototype can save you a lot of time, money, and hassle in the long run. You can choose one of three basic styles of prototyping: solderless breadboard, perfboard, and manufactured PCB. Your project goals, your schedule, and your circuit’s complexity are variables that will influence your choice. (I am not including styles like flying leads and wire-wrapping.)

Prototyping Tools

The building phase of a design might include wiring up your circuit design and altering an enclosure to provide access to any I/O on the PCB. Let’s begin with some tools that you will need for circuit prototyping.

The nearby photo shows a variety of small tools that I use when wiring a perfboard or assembling a manufactured PCB. The needle-nose pliers/cutter is the most useful.

These are my smallest hand tools. With them I can poke, pinch, bend, cut, smooth, clean, and trim parts, boards, and enclosures. I can use the set of special driver tips to open almost any product that uses security screws.

Don’t skimp on this; a good pair will last many years. …

Once everything seems to be in order, you can fill up the sockets. You might need to provide some stimulus if you are building something like a filter. A small waveform generator is great for this. There are even a few hand probes that will provide outputs that can stimulate your circuitry. An oscilloscope might be the first “big ticket” item in which you invest. There are some inexpensive digital scope front ends that use an app running on a PC for display and control, but I suggest a basic analog scope (20 MHz) if you can swing it (starting at less than $500).

If the circuit doesn’t perform the expected task, you should give the wiring job a quick once over. Look to see if something is missing, such as an unconnected or misconnected wire. If you don’t find something obvious, perform a complete continuity check of all the components and their connections using an ohmmeter.

I use a few different meters. One has a transistor checker. Another has a high-current probe. For years I used a small battery-powered hand drill before purchasing the Dremel and drill press. The tweezers are actually an SMT parts measurer. Many are unmarked and impossible to identify without using this device (and the magnifier).

It usually will be a stupid mistake. To do a complete troubleshooting job, you’ll need to know how the circuit is supposed to work. Without that knowledge, you can’t be expected to know where to look and what to look for.

Make a Label

You’ll likely want to label your design… Once printed, you can protect a label by carefully covering it with a single strip of packing tape.

The label for this project came straight off a printer. Using circuit-mount parts made assembling the design a breeze.

A more expensive alternative is to use a laminating machine that puts your label between two thin plastic sheets. There are a number of ways to attach your label to an enclosure. Double-sided tape and spray adhesive (available at craft stores) are viable options.”

Ready to start innovating? There’s no time like now to begin your adventure.

Check out the upcoming anniversary issue for Bachiochi’s complete essay.

The Future of 8-Bit Chips (CC 25th Anniversary Preview)

Ever since the time when a Sony Walkman retailed for around $200, engineers of all backgrounds and skill levels have been prognosticating the imminent death of 8-bit chips. No matter your age, you’ve likely heard the “8-bit is dead” argument more than once. And you’ll likely hear it a few more times over the next several years.

Long-time Circuit Cellar contributor Tom Cantrell has been following the 8-bit saga for the last 25 years. In Circuit Cellar‘s 25th Anniversary issue, he offers his thoughts on 8-bit chips and their future. Here’s a sneak peek. Cantrell writes:

“8-bit is dead.”  Or so I was told by a colleague. In 1979. Ever since then, reports of the demise of 8-bit chips have been greatly, and repeatedly, exaggerated. And ever since then, I’ve been pointing out the folly of premature eulogizing.

I’ll concede the prediction is truer today than in 1979—mainly, because it wasn’t true at all then. Now, some 30-plus years later, let’s reconsider the prospects for our “wee” friends…

Let’s start the analysis by putting on our Biz101 hats. If you Google “Product Life Cycle” and click on “Images,” you’ll see a variety of somewhat similar graphs showing how products pass through stages of growth, maturity, and decline. Though all the graphs tell a rise-and-fall story, it’s interesting to note the variations. Some show a symmetrical life cycle that looks rather like a normal distribution. But the majority of the graphs show a “long-tail” variation in which the maturity phase lasts somewhat longer and the decline is relatively gradual.

Another noteworthy difference is how some graphs define life and death in terms of “sales” and others “profits.” It stands to reason that no business will continue to sell at a loss indefinitely, but the market knows how to fix that. Even if some suppliers wave the white flag, those that remain can raise prices and maintain profitability as long as there is still demand.

One of the more interesting life cycle variations shows that innovation, like a fountain of youth, can stave off death indefinitely. An example that comes to mind is the recent introduction of ferroelectric RAM (FRAM) MCUs. FRAM has real potential to reduce power consumption and also streamlines the supply chain because a single block of FRAM can be arbitrarily partitioned to emulate any mix of read-mostly or random access memory (see Photo 1). They may be “mature” products, but today the Texas Instruments MSP430 and Ramtron 8051 are leading the way with FRAM.

Photo 1: Ongoing innovation, such as the FRAM-based “Wolverine” MCU from Texas Instruments, continues to expand the market for mini-me MCUs. (Source: Cantrell CC25)

And “innovation” isn’t limited to just the chips themselves. For instance, consider the growing popularity of the Arduino SBC. There’s certainly nothing new about the middle-of-the-road, 8-bit Atmel AVR chip it uses. Rather, the innovations are with the “tools” (simplified IDE), “open-source community,” and “sales channel” (e.g., RadioShack). You can teach an old chip new tricks!

Check out the upcoming anniversary issue for the rest of Cantrell’s essay. Be sure to let us know what you think about the future of the 8-bit chip.

The Future of FPGAs (CC 25th Anniversary Preview)

Field-programmable gate arrays (FPGAs) have been around for more than two decades. What does the future hold for this technology? According to Halifax, Canada-based electrical engineering consultant Colin O’Flynn, current FPGA-related research and recent innovations seem to presage a coming revolution in digital system design, and this could lead to striking fast advances in several fields of engineering.

In the upcoming Circuit Cellar 25th Anniversary Issue—which is slated for publication in early 2013—O’Flynn shares his thoughts on the future of FPGA technology. He writes:

Field-programmable gate arrays (FPGAs) provide a powerful means to design digital systems (see Photo 1). Rather than writing a software program, you can design a number of hardware blocks to perform your tasks at blazing speeds…

Photo 1: Source: C. O’Flynn, CC 25th Anniversary issue

Microcontrollers have long played the peripheral game: the integration of easy-to-use dedicated peripherals onto the same physical chip as your digital core. FPGAs, it would seem, have no use for dedicated logic, since you can just design everything exactly as you desire. But dedicated logic has its advantages.

Beyond technical advantages, such as lower power consumption or smaller area with dedicated cores compared to programmable cores, dedicated cores can also reduce development effort. For example, current technology sees FPGAs with integrated high-end ARM cores, capable of running Linux on the integrated hard-core. Anyone familiar with setting up Linux on an ARM-based microprocessor can use this, without needing to learn about how one develops cores and peripherals on the FPGA itself.
Beyond integrating digital cores to simplify development, you can expect to see the integration of analog peripherals. Looking at the microcontroller market, you can find a variety of tightly integrated SoC devices with analog and digital on a single device. For instance, a variety of radio devices contain a complete RF front-end combined with a digital microcontroller. While current FPGA devices offer very limited analog peripherals (most have none), having a FPGA with an integrated high-speed ADC or DAC would be the making of a highly flexible radio-on-a-chip platform. The high development cost and lack of a current market has meant this remains only an interesting idea. To see where this market comes from, let’s look at some applications for such an FPGA.

Software-Defined Radio
Software-defined radio (SDR) takes a curious approach to receiving radio waves: digitize it all, and let software sort it out. The radio front-end is simple. Typically, the center frequency of interest is just downshifted to the baseband, everything else is filtered out, and a high-speed ADC digitizes it. All the demodulation and decoding then can be down in software. Naturally, this can require some fast sampling speeds. Anything from 20 to 500 MSps is fairly typical for these systems. Dealing with this much data is suited to FPGAs, since one can generate blocks to perform all the different functions that operate simultaneously…

Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.

Do Small-RAM Devices Have a Future? (CC 25th Anniversary Preview)

What does the future hold for small-RAM microcontrollers? Will there be any reason to put up with the constraints of parts that have little RAM, no floating point, and 8-bit registers? The answer matters to engineers who have spent years programming small-RAM MCUs. It also matters to designers who are hoping to keep their skills relevant as their careers progress in the 21st century.

In the upcoming Circuit Cellar 25th Anniversary Issue—which is slated for publication in early 2013—University of Utah professor John Regehr shares his thoughts on the future of small-RAM devices. He writes:

For the last several decades, the role of small-RAM microcontrollers has been clear: they are used to perform fixed (though sometimes very sophisticated) functionality in environments where cost, power consumption, and size need to be minimized. They exploit the low marginal cost of additional transistors to integrate volatile RAM, nonvolatile RAM, and numerous peripherals into the same package as the processor core, providing a huge amount of functionality in a small, cheap package. Something that is less clear is the future of small-RAM microcontrollers. The same fabrication economics that make it possible to put numerous peripherals on a single die also permit RAM to be added at little cost. This was brought home to me recently when I started using Raspberry Pi boards in my embedded software class at the University of Utah. These cost $25 to $35 and run a full-sized Linux distribution including GCC, X Windows, Python, and everything else—all on a system-on-chip with 256 MB of RAM that probably costs a few dollars in quantity.

We might ask: Given that it is already the case that a Raspberry Pi costs about the same as an Arduino board, in the future will there be any reason to put up with the constraints of an architecture like Atmel’s AVR, where we have little RAM, no floating point, and 8-bit registers? The answer matters to those of us who enjoy programming small-RAM MCUs and who have spent years fine-tuning our skills to do so. It also matters to those of us who hope to keep our skills relevant through the middle of the 21st century. Can we keep writing C code, or do we need to start learning Java, Python, and Haskell? Can we keep writing stand-alone “while (true)” loops, or will every little MCU support a pile of virtual machines, each with its own OS?

Long & Short Term

In the short term, it is clear that inertia will keep the small-RAM parts around, though increasingly they will be of the more compiler-friendly varieties, such as AVR and MSP430, as opposed to earlier instruction sets like Z80, HC11, and their descendants. But will small-RAM microcontrollers exist in the longer term (e.g., 25 or 50 years)? I’ll attempt to tackle this question by separately discussing the two things that make small-RAM parts attractive today: their low cost and their simplicity.

If we assume a cost model where packaging and soldering costs are fixed but the marginal cost of a transistor (not only in terms of fabrication, but also in terms of power consumption) continues to drop, then small-RAM parts will eventually disappear. In this case, several decades from now even the lowliest eight-pin package, costing a few pennies, will contain a massive amount of RAM and will be capable of running a code base containing billions of lines…

Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.

CC269: Break Through Designer’s Block

Are you experiencing designer’s block? Having a hard time starting a new project? You aren’t alone. After more than 11 months of designing and programming (which invariably involved numerous successes and failures), many engineers are simply spent. But don’t worry. Just like every other year, new projects are just around the corner. Sooner or later you’ll regain your energy and find yourself back in action. Plus, we’re here to give you a boost. The December issue (Circuit Cellar 269) is packed with projects that are sure to inspire your next flurry of innovation.

Turn to page 16 to learn how Dan Karmann built the “EBikeMeter” Atmel ATmega328-P-based bicycle computer. He details the hardware and firmware, as well as the assembly process. The monitoring/logging system can acquire and display data such as Speed/Distance, Power, and Recent Log Files.

The Atmel ATmega328-P-based “EBikeMeter” is mounted on the bike’s handlebar.

Another  interesting project is Joe Pfeiffer’s bell ringer system (p. 26). Although the design is intended for generating sound effects in a theater, you can build a similar system for any number of other uses.

You probably don’t have to be coerced into getting excited about a home control project. Most engineers love them. Check out Scott Weber’s garage door control system (p. 34), which features a MikroElektronika RFid Reader. He built it around a Microchip Technology PIC18F2221.

The reader is connected to a breadboard that reads the data and clock signals. It’s built with two chips—the Microchip 28-pin PIC and the eight-pin DS1487 driver shown above it—to connect it to the network for testing. (Source: S. Weber, CC269)

Once considered a hobby part, Arduino is now implemented in countless innovative ways by professional engineers like Ed Nisley. Read Ed’s article before you start your next Arduino-related project (p. 44). He covers the essential, but often overlooked, topic of the Arduino’s built-in power supply.

A heatsink epoxied atop the linear regulator on this Arduino MEGA board helped reduce the operating temperature to a comfortable level. This is certainly not recommended engineering practice, but it’s an acceptable hack. (Source: E. Nisley, CC269)

Need to extract a signal in a noisy environment? Consider a lock-in amplifier. On page 50, Robert Lacoste describes synchronous detection, which is a useful way to extract a signal.

This month, Bob Japenga continues his series, “Concurrency in Embedded Systems” (p. 58). He covers “the mechanisms to create concurrently in your software through processes and threads.”

On page 64, George Novacek presents the second article in his series, “Product Reliability.” He explains the importance of failure rate data and how to use the information.

Jeff Bachiochi wraps up the issue with a article about using heat to power up electronic devices (p. 68). Fire and a Peltier device can save the day when you need to charge a cell phone!

Set aside time to carefully study the prize-winning projects from the Reneas RL78 Green Energy Challenge (p. 30). Among the noteworthy designs are an electrostatic cleaning robot and a solar energy-harvesting system.

Lastly, I want to take the opportunity to thank Steve Ciarcia for bringing the electrical engineering community 25 years of innovative projects, essential content, and industry insight. Since 1988, he’s devoted himself to the pursuit of EE innovation and publishing excellence, and we’re all better off for it. I encourage you to read Steve’s final “Priority Interrupt” editorial on page 80. I’m sure you’ll agree that there’s no better way to begin the next 25 years of innovation than by taking a moment to understand and celebrate our past. Thanks, Steve.

Pi-Face: A New Raspberry Pi Accessory

Ready for the Pi-Face Digital? What’s that? you ask.

Pi-Face at Electronica 2012 (Source: Elektor.tv)

Pi Interface Digital, or Pi-Face Digital, is a Raspberry Pi accessory board Premier Farnell will begin distributing in early 2013. You can plug it into a Raspberry Pi and start designing immediately. Plus, you can connect sensors to Pi-Face Digital for a variety of purposes, such as temperature- or pressure-monitoring applications.

The following useful information is posted at the University of Manchester’s School of Computer Science site.

Pi-Face Digital is the first of a range of interfaces to allow the Raspberry Pi to control and manipulate the real world. It allows the Raspberry Pi to read switches connected to it – a door sensor or pressure pad perhaps, a microswitch or reed switch, or a hand held button. With appropriate easy to write code, the Raspberry Pi then drives outputs, powering motors, actuator, LEDs, light bulbs or anything you can imagine to respond to the inputs… The hardware provides an easy and consistent programming interface, in Scratch (as shown running on a Raspberry Pi in the photograph) and Python with good observability to promote easy development, and reduce technology barriers.

It will cost approximately €20 to €30. You can register at element14.

Want to see Pi-Face in action? Check it out on Elektor.tv!

CircuitCellar.com is an Elektor International Media publication.

Microcontroller-Based Markov Music Box

Check out the spectrogram for two FM notes produced by FM modulation. Red indicates higher energy at a given time and frequency.

Cornell University senior lecturer Bruce Land had two reasons for developing an Atmel AVR micrcontroller-based music box. One, he wanted to present synthesis/sequencing algorithms to his students. And two, he wanted the challenge of creating an interactive music box. Interactive audio is becoming an increasingly popular topic among engineers and designers, as we recently reported.

Land writes:

Traditional music boxes play one or two tunes very well, but are not very interactive. Put differently, they have a high quality of synthesis, but a fixed-pattern note sequencer and fixed tonal quality. I wanted to build a device which would play an interesting music-like note sequence, which constantly changed and evolved, with settable timbre, tempo, and beat… To synthesize nice sounding musical notes you need to control spectral content of the note, the rise time (attack), fall time (decay), and the change in spectral content during attack and decay.  Also it is nice to have at least two independent musical voices. And all of this has to be done using the modest arithmetic capability of an 8-bit microcontroller.

Land’s students subsequently used the music box for other projects, such as an auto-composing piano, as shown in the following video.

In early 2013 Circuit Cellar will run Land’s in-depth article on the Markov music box project. Stay tuned for more information.

Principles of Embedded System Design (CC 25th Anniversary Preview)

You have an idea an idea for an innovative microcontroller-based design? Once you start start soldering and wiring, you might want to keep an eye on Bob Japenga’s checklist of essential embedded system design principle. His complete list will appear in Circuit Cellar‘s 25th Anniversary issue, which will be available in early 2013. But since many of you will be attempting to complete projects before January 1, we’re giving you a sneak peek.

Japenga writes:

We all know that old adage: “If you don’t have time to do it right the first time, where do you find the time to do it right the second?” But this is the nature of developing robust embedded systems. There are literally thousands of little decisions that we make even in the simplest of projects. How can we minimize repeating mistakes?

So my goal in this article is twofold: to celebrate with Circuit Cellar 25 years of great service to us engineers and to hammer home some of those principles that we so often forget. I will divide the essentials into four categories: general essentials, essentials that exist because things (i.e., us and our designs) fail, essentials about testing, and essentials about memory use.

General Essentials

KISS & No Simpler“Keep it simple stupid (KISS).” How often do I need to hear this? I like the saying about KISS that’s often attributed to Albert Einstein but was actually Roger Session’s paraphrase: “Make things as simple as possible, but no simpler.” I am counting these as our first and second essentials.  Keep it simple is number one and no simpler is the second. I find this an immense challenge. When we are faced with schedule deadlines and tight budgets, it is costly to make a design simple. Some people have a gift at taking a problem and abstracting an elegant and simple solution. I remember giving a design specification to one of my employees a number of years ago when I worked for an aerospace company. After several days he came back with over 20 pages of algorithms and charts defining how the specification should be met in software. I wasn’t smart enough to know why it was too complex, but my gut feeling was: “This is too complex. Make it simpler.” Later, I turned it over to another young man who returned with an elegant two-page algorithm that worked perfectly.

How do we do that? “As simple as possible” can get us in trouble if we make it too simple. For example, just recently we were designing a multi-drop serial interface to be incorporated into a medical device. A strong case could be made for the simplicity of using a single-ended interface. But experience tells us that a differential interface will be more robust in the face of defibrillators and all the various noisy electronic instruments it will to play with. Which meets the KISS principle? The same tough decision comes when you’re trying to decide whether to go with a two-wire or a four-wire interface. Two wires has less cabling, but it’s more complex in the interface and forces single-duplex operation. Again, which meets the principle?

Sometimes the trade-off can come down to what you already have in the house. If you have well-debugged libraries for handling the two-wire 485 protocols, the reduced number of wires reduces the overall system complexity even though the software will in fact be more complex.

Sometimes when dealing with algorithm development, the KISS principle can also present ambiguous alternatives. At times, a straightforward linear programming approach can be many times more lines of code and more complex than an elegant algorithm. But the elegant algorithm may be obscure, difficult to maintain, or take too long to come up with. Therein lies the challenge to Keep It Simple Stupid but No Simpler.

Define the Problem/Create Clear SpecsHaving a clear set of specs is essential to every part of a design. We all know this and we always belly ache about how we don’t have perfect specifications. But get with it. You won’t always have perfect specs from your customer. But it is essential that you make them as good as possible. And in writing. If your customer is willing, keep pushing back and keep writing it down and refining it as you go.

I’ve found that essential for every phase of a project. Whether it is hardware or software, writing out the spec (on the schematic or in the code) is a wonderful act of discipline. Write out the spec for the module. Write out the spec for the algorithm. Write out the spec for the circuit. Writing it out forces you to think it through. End the belly-aching about the lack of good specs. Start creating them.

Don’t Skimp on the ToolsTools are our life blood. If you are a manager and your designers don’t have the best tools, you are wasting your money on their salaries. That said, we are not talking about buying tools you don’t use, tools that don’t pay for themselves, or tools that you can rent more cost effectively. Last week we were discussing a problem where one of our cell modem designs exceeded the limit for the second harmonic in spurious emissions. In talking over the problem with the test lab, I discovered that they had a tool that they brought inside the anechoic chamber that could tell the cell modem to transmit on such and such a frequency at maximum power. Naively, I asked, “Shouldn’t we have such a tool?” Someone responded: “Yes, but they cost almost a million dollars.” Oh. But we found we could rent one for $1,000 a day. So, I am not talking about being unwise with our money.

Many years ago while at the aerospace company, I was recommending an HP64000 system that appeared to be a very powerful tool for our software development team. I wrote up the proposal and presented it to the vice president of engineering. His question has haunted me ever since. “Would you buy it if it were your money?” I said then, and continue to say now, “Get the best tools that will allow you to do the job as quickly as possible. If a 200-man-hour job can be done for 100 hours with a $10,000 instrument, is it worth it. Absolutely.”

Read the DocumentationLast year we had a problem that showed up only after we started making the product in 1,000-piece runs. The problem was that some builds of the system took a very long time to power up. We had built about 10 prototypes, tested the design over thousands of power ups, and it tested just fine (thanks to POC-IT). Then the 1,000-piece run uncovered about a half-dozen units that had variable power-up times—ranging from a few seconds to more than an hour! Replacing the watchdog chip that controlled the RESET line to an ARM9 processor fixed the problem. But why did these half dozen fail? Many hours into the analysis we discovered that the RESET line out of the watchdog chip on the failed units would pulse but stay low for long periods of time. A shot of cold air instantly caused the chip to release the RESET. Was it a faulty chip lot? Nope. Upon a closer read of the documentation, we found that you cannot have a pull-up resister on the RESET line. For years we always had pull-ups on RESET lines. We’d missed that in the documentation.

Like it or not, we have to pour over the documentation of the chips and software library calls we use. We have to digest the content carefully. We cannot rely on what is intuitive.

Finally, and this is much more necessary than in years past, we have to pour over the errata sheets. And we need to do it before we commit the design. A number of years ago, a customer designed a major new product line around an Atmel ARM9. This ARM9 had the capability of directly addressing NOR memory up to 128 MB.  Except for the fact that the errata said that due to a bug it could only address 16 MB.  Ouch! Later we had problems with the I2C bus in the same chip. At times, the bus would lock up and nothing except a power cycle would unlock it. Enter the errata. Under some unmentioned conditions the I2C state machine can lock up. Ouch! In this case, we were able to use a bit-bang algorithm rather than the built-in I2C—but obviously at the cost of money, scheduling, and real time.

If You Can’t Explain it to Mom, It Ain’t ClearThat’s another way to say: “Assume no one reads the user manual.” I recently read a blog post about the City of Boston’s electronic parking meters (http://usabilitylessons.wordpress.com/category/general/). Truly, one wonders who reviewed that user interface. If you want to make robust embedded systems with a user interface, they need to have intuitive interfaces, or you may be surprised at what the user comes up with. This takes time and effort, but it’s well worth it. Try it out on the uninitiated. Engineers are the worst kind of people for testing user interfaces. Try it on kids. My business partner’s one-year-old son found the first bug in our first product.

Be sure to get your hands on the upcoming anniversary issue to learn about the reset of the principles. He covers “Things Fail Essentials,” “Testing Essentials,” “Memory Management Essentials,” and more. Consider using it to create your own design principles checklist that you can keep at your workbench.

Embedded Security Tips (CC 25th Anniversary Preview)

Every few days we you a sneak peek at some of the exciting content that will run in Circuit Cellar‘s Anniversary issue, which is scheduled to be available in early 2013. You’ve read about Ed Nisley’s essay on his most memorable designs—from a hand-held scanner project to an Arduino-based NiMH cell tester—and Robert Lacoste’s tips for preventing embedded design errors. Now it’s time for another preview.

Many engineers know they are building electronic systems for use in dangerous times. They must plan for both hardware and software attacks, which makes embedded security a hot topic for 2013.  In an essay on embedded security risks, Virginia Tech professor Patrick Schaumont looks at the current state of affairs through several examples. His tips and suggestions will help you evaluate the security needs of your next embedded design.

Schaumont writes:

As design engineers, we should understand what can and what cannot be done. If we understand the risks, we can create designs that give the best possible protection at a given level of complexity. Think about the following four observations before you start designing an embedded security implementation.

First, you have to understand the threats that you are facing. If you don’t have a threat model, it makes no sense to design a protection—there’s no threat! A threat model for an embedded system will specify what can attacker can and cannot do. Can she probe components? Control the power supply? Control the inputs of the design? The more precisely you specify the threats, the more robust your defenses will be. Realize that perfect security does not exist, so it doesn’t make sense to try to achieve it. Instead, focus on the threats you are willing to deal with.

Second, make a distinction between what you trust and what you cannot trust. In terms of building protections, you only need to worry about what you don’t trust. The boundary between what you trust and what you don’t trust is suitably called the trust boundary. While trust boundaries where originally logical boundaries in software systems, they also have a physical meaning in embedded context. For example, let’s say that you define the trust boundary to be at the chip-package level of a microcontroller. This implies that you’re assuming an attacker will get as close to the chip as the package pins, but not closer. With such a trust boundary, your defenses should focus on off-chip communication. If there’s nothing or no one to trust, then you’re in trouble. It’s not possible to build a secure solution without trust.

Third, security has a cost. You cannot get it for free. Security has a cost in resources and energy. In a resource-limited embedded system, this means that security will always be in competition with other system features in terms of resources. And because security is typically designed to prevent bad things from happening rather than to enable good things, it may be a difficult trade-off. In feature-rich consumer devices, security may not be a feature for which a customer is willing to pay extra.

The fourth observation, and maybe the most important one, is to realize is that you’re not alone. There are many things to learn from conferences, books, and magazines. Don’t invent your own security. Adapt standards and proven Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.techniques. Learn about the experiences of other designers.

Schaumont then provides lists of helpful embedded security-related resources, such as Flylogic’s Analytics Blog and the Athena website at GMU.

Prevent Embedded Design Errors (CC 25th Anniversary Preview)

Attention, electrical engineers and programmers! Our upcoming 25th Anniversary Issue (available in early 2013) isn’t solely a look back at the history of this publication. Sure, we cover a bit of history. But the issue also features design tips, projects, interviews, and essays on topics ranging from user interface (UI) tips for designers to the future of small RAM devices, FPGAs, and 8-bit chips.

Circuit Cellar’s 25th Anniversary issue … coming in early 2013

Circuit Cellar columnist Robert Lacoste is one of the engineers whose essay will focus on present-day design tips. He explains that electrical engineering projects such as mixed-signal designs can be tedious, tricky, and exhausting. In his essay, Lacoste details 25 errors that once made will surely complicate (at best) or ruin (at worst) an embedded design project. Below are some examples and tips.

Thinking about bringing an electronics design to market? Lacoste highlights a common error many designers make.

Error 3: Not Anticipating Regulatory Constraints

Another common error is forgetting to plan for regulatory requirements from day one. Unless you’re working on a prototype that won’t ever leave your lab, there is a high probability that you will need to comply with some regulations. FCC and CE are the most common, but you’ll also find local regulations as well as product-class requirements for a broad range of products, from toys to safety devices to motor-based machines. (Refer to my article, “CE Marking in a Nutshell,” in Circuit Cellar 257 for more information.)

Let’s say you design a wireless gizmo with the U.S. market and later find that your customers want to use it in Europe. This means you lose years of work, as well as profits, because you overlooked your customers’ needs and the regulations in place in different locals.

When designing a wireless gizmo that will be used outside the U.S., having adequate information from the start will help you make good decisions. An example would be selecting a worldwide-enabled band like the ubiquitous 2.4 GHz. Similarly, don’t forget that EMC/ESD regulations require that nearly all inputs and outputs should be protected against surge transients. If you forget this, your beautiful, expensive prototype may not survive its first day at the test lab.

Watch out for errors

Here’s another common error that could derail a project. Lacoste writes:

Error 10: You Order Only One Set of Parts Before PCB Design

I love this one because I’ve done it plenty of times even though I knew the risk.

Let’s say you design your schematic, route your PCB, manufacture or order the PCB, and then order the parts to populate it. But soon thereafter you discover one of the following situations: You find that some of the required parts aren’t available. (Perhaps no distributor has them. Or maybe they’re available but you must make a minimum order of 10,000 parts and wait six months.) You learn the parts are tagged as obsolete by its manufacturer, which may not be known in advance especially if you are a small customer.

If you are serious about efficiency, you won’t have this problem because you’ll order the required parts for your prototypes in advance. But even then you might have the same issue when you need to order components for the first production batch. This one is tricky to solve, but only two solutions work. Either use only very common parts that are widely available from several sources or early on buy enough parts for a couple of years of production. Unfortunately, the latter is the only reasonable option for certain components like LCDs.

Ok, how about one more? You’ll have to check out the Anniversary Issue for the list of the other 22 errors and tips. Lacoste writes:

Error 12: You Forget About Crosstalk Between Digital and Analog Signals

Full analog designs are rare, so you have probably some noisy digital signals around your sensor input or other low-noise analog lines. Of course, you know that you must separate them as much as possible, but you can be sure that you will forget it more than once.

Let’s consider a real-world example. Some years ago, my company designed a high-tech Hi-Fi audio device. It included an on-board I2C bus linking a remote user interface. Do you know what happened? Of course, we got some audible glitches on the loudspeaker every time there was an I2C transfer. We redesigned the PCB—moving tracks and adding plenty of grounded copper pour and vias between sensitive lines and the problem was resolved. Of course we lost some weeks in between. We knew the risk, but underestimated it because nothing is as sensitive as a pair of ears. Check twice and always put guard-grounded planes between sensitive tracks and noisy ones.

Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.

 

 

 

 

From the IBM PC AT to AVRs & Arduinos (CC 25th Anniversary Preview)

During the last 25 years, hundreds of the world’s most brilliant electrical engineers and embedded developers have published articles in Circuit Cellar magazine. But only a choice few had the skill, focus, creativity, and stamina to consistently publish six or more articles per year. Ed Nisley is a member of that select group. Since Issue 1, Nisley has covered topics ranging from a video hand scanner project to X10 powerline control to Arduino-based designs to crystal characterization.

In the upcoming Circuit Cellar 25th Anniversary Issue—which is slated for publication in early 2013—Nisley describes some of his most memorable projects, such as his hand Scanner design from Issue #1. He writes:

The cable in the upper-left corner went to the serial port of my Genuine IBM PC AT. The hand-wired circuit board in front came from an earlier project: an 8031-based video digitizer that captured single frames and produced, believe it or not, RS-232 serial data. It wasn’t fast, but it worked surprisingly well and, best of all, the board was relatively inexpensive. Having built the board and written the firmware, I modified it to output compressed data from hand images, then wrote a PC program to display the results.

Combining a TV camera, a prototype 8031-based video digitizer, and an IBM PC with custom firmware and software produced a digital hand scanner for Circuit Cellar Issue 1. The aluminum case came from an external 8″ floppy drive!

The robust aluminum case originally housed an external 8″ floppy drive for one of my earlier DIY “home computers” (they sure don’t make ‘em like they used to!) and I assembled the rest of the hardware in my shop. With hardware and software in hand, I hauled everything to Circuit Cellar Galactic HQ for a demo.

Some of the work Nisley details is much more modern. For instance, the photo below shows the Arduino microcontroller boards he has been using in many of his recent projects. Nisley writes:

The processors, from the Atmel AVR microcontroller family, date to the mid-1990s, with a compiler-friendly architecture producing good performance with high-level languages. Barely more than breakout boards wrapped around the microcontrollers, Arduinos provide a convenient way to mount and wire to the microcontroller chips. The hardware may be too expensive to incorporate in a product, but it’s ideal for prototypes and demonstrations.

The Arduino microcontroller project provides a convenient basis for small-scale projects like this NiMH cell tester. Simple interconnections work well with low-speed signals and lowcurrent hardware, but analog gotchas always lie in wait.

Even better, a single person can still comprehend all of a project’s hardware and software, if only because the projects tend to be human scaled. The Arduino’s open-source licensing model fits well with my column’s readily available hardware and firmware: you can reproduce everything from scratch, then extend it to suit your needs.

Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.

Q&A: Andrew Spitz (Co-Designer of the Arduino-Based Skube)

Andrew Spitz is a Copenhagen, Denmark-based sound designer, interaction designer, programmer, and blogger studying toward a Master’s interaction design at the Copenhagen Institute of Interaction Design (CIID). Among his various innovative projects is the Arduino-based Skube music player, which is an innovative design that enables users to find and share music.

The Arduino-based Skube

Spitz worked on the design with Andrew Nip, Ruben van der Vleuten, and Malthe Borch. Check out the video to see the Skube in action.

On his blog SoundPlusDesign.com, Spitz writes:

It is a fully working prototype through the combination of using ArduinoMax/MSP and an XBee wireless network. We access the Last.fm API to populate the Skube with tracks and scrobble, and using their algorithms to find similar music when in Discover mode.

The following is an abridged  version of an interview that appears in the December 2012 issue of audioXpress magazine, a sister publication of Circuit Cellar magazine..

SHANNON BECKER: Tell us a little about your background and where you live.

Andrew Spitz: I’m half French, half South African. I grew up in France, but my parents are South African so when I was 17, I moved to South Africa. Last year, I decided to go back to school, and I’m now based in Copenhagen, Denmark where I’m earning a master’s degree at the Copenhagen Institute of Interaction Design (CID).

SHANNON: How did you become interested in sound design? Tell us about some of your initial projects.

Andrew: From the age of 16, I was a skydiving cameraman and I was obsessed with filming. So when it was time to do my undergraduate work, I decided to study film. I went to film school thinking that I would be doing cinematography, but I’m color blind and it turned out to be a bigger problem than I had hoped. At the same time, we had a lecturer in sound design named Jahn Beukes who was incredibly inspiring, and I discovered a passion for sound that has stayed with me.

Shannon: What do your interaction design studies at CIID entail? What do you plan to do with the additional education?

Andrew: CIID is focused on a user-centered approach to design, which involves finding intuitive solutions for products, software, and services using mostly technology as our medium. What this means in reality is that we spend a lot of time playing, hacking, prototyping, and basically building interactive things and experiences of some sort.

I’ve really committed to the shift from sound design to interaction design and it’s now my main focus. That said, I feel like I look at design from the lens of a sound designer as this is my background and what has formed me. Many designers around me are very visual, and I feel like my background gives me not only a different approach to the work but also enables me to see opportunities using sound as the catalyst for interactive experiences. Lots of my recent projects have been set in the intersection among technology, sound, and people.

SHANNON: You have worked as a sound effects recordist and editor, location recordist and sound designer for commercials, feature films, and documentaries. Tell us about some of these experiences?

ANDREW: I love all aspects of sound for different reasons. Because I do a lot of things and don’t focus on one, I end up having more of a general set of skills than going deep with one—this fits my personality very well. By doing different jobs within sound, I was able to have lots of different experiences, which I loved! nLocation recording enabled me to see really interesting things—from blowing up armored vehicles with rocket-propelled grenades (RPGs) to interviewing famous artists and presidents. And, documentaries enabled me to travel to amazing places such as Rwanda, Liberia, Mexico, and Nigeria. As a sound effects recordist on Jock of the Bushvelt, a 3-D animation, I recorded animals such as lions, baboons, and leopards in the South African bush. With Bakgat 2, I spent my time recording and editing rugby sounds to create a sound effects library. This time in my life has been a huge highlight, but I couldn’t see myself doing this forever. I love technology and design, which is why I made the move...

SHANNON: Where did the idea for Skube originate?

Andrew: Skube came out of the Tangible User Interface (TUI) class at CIID where we were tasked to rethink audio in the home context. So understanding how and where people share music was the jumping-off point for creating Skube.

We realized that as we move more toward a digital and online music listening experience, current portable music players are not adapted for this environment. Sharing mSkube Videousic in communal spaces is neither convenient nor easy, especially when we all have such different taste in music.

The result of our exploration was Skube. It is a music player that enables you to discover and share music and facilitates the decision process of picking tracks when in a communal setting.

audioXpress is an Elektor International Media publication.