Microcontroller-Based, Cube-Solving Robot

Cube Solver in ActionCanadian Nelson Epp has earned degrees in physics and electrical engineering. But as a child, he was stumped by the Rubik’s Cube puzzle. So, as an adult, he built a Rubik’s Cube-solving robot that uses a Parallax Propeller microcontroller and a 52-move algorithm to solve the 3-D puzzle.

Designing and completing the robot wasn’t easy. Epp says he originally used a “gripper”-type robot that was “a complete disaster.” Then he experimented with different algorithms–“human memorizable ones”—before settling on a solution method developed by mathematician Morwen Thistlethwaite. (The algorithm is based on the mathematical concepts of a group, a subgroup, and generator and coset representatives.)

Nelson also developed a version of his Rubik’s Cube solver that used neural networks to analyze the cube’s colors, but that worked only half the time.

So, considering the time he had to spend on project trial and error (and his obligations to work, family, and pets), it took about six years to complete the robot. He writes about the results in the September issue of Circuit Cellar magazine. 

Here, he describes some of the choices he made in hardware components.

“The cube solver hardware uses two external power supplies: 5 VDC for the servomotors and 12 VDC for the remaining circuits. The 12-VDC power supply feeds a Texas Instruments (TI) UA78M33 and a UA78M05 linear regulator. The UA78M05 regulator powers an Electronics123 C3088 camera board. The UA78M33 regulator powers a Maxim Integrated MAX3232 ECPE RS-232 transceiver, a Microchip Technology 24LC256 CMOS serial EEPROM, remote reset circuitry, the Propeller, a SD/MMC card, the camera board’s digital output circuitry, and an ECS ECS-300C-160 oscillator. The images at right show my cube solver and circuit board.
“The ECS-300C-160 is a self-contained dual-output oscillator that can produce clock signals that are binary fractions of the 16-MHz base signal. My application uses the 8- and 16-MHz clock taps. The Propeller is clocked with the 8-MHz signal and then internally multiplied up to 64 MHz. The 16-MHz signal is fed to the camera.

“I used a MAX3232 transceiver to communicate to the host’s RS-232 port. The Propeller’s serial input pin and serial output pin are only required at startup. After the Propeller starts up, these pins can be used to exchange commands with the host. The Propeller also has pins for serial communication to an EEPROM, which are used during power up when a host is not sending a program.

“The cube-solving algorithm uses the coset representative file stored on an SD card, which is read by the Propeller via a SparkFun Electronics Breakout Board for SD-MMC cards. The Propeller interface to the SD card consists of a chip select, data in, data out, data clock, and power. The chip select is fixed into the active state. The three lines associated with data are wired to the Propeller.

“The Propeller uses a camera to determine the cube’s starting permutation. The C3088 uses an Electronics123 OV6630 color sensor module. I chose the camera because its data format and clocking speed was within the range of the Propeller’s capabilities. The C3088 has jumpers for external or internal clocking.”

To read more about Epp’s design journey—and outcomes—check out Circuit Cellar’s September issue. And click here for a video of his robot at work.


Embedded Wireless Made Simple

Last week at the 2013 Sensors Expo in Chicago, Anaren had interesting wireless embedded control systems on display. The message was straightforward: add an Anaren Integrated Radio (AIR) module to an embedded system and you’re ready to go wireless.

Bob Frankel demos embedded mobile control

Bob Frankel of Emmoco provided a embedded mobile control demonstration. By adding an AIR module to a light control system, he was able to use a tablet as a user interface.

The Anaren 2530 module in a light control system (Source: Anaren)

In a separate demonstration, Anaren electrical engineer Mihir Dani showed me how to achieve effective light control with an Anaren 2530 module and TI technology. The module is embedded within the light and compact remote enables him to manipulate variables such as light color and saturation.

Visit Anaren’s website for more information.

New Products: May 2013


iC-Haus iC-TW8

The iC-TW8 is a high-resolution signal processor designed to evaluate sine/cosine sensors. Its automatic functions help minimize angular errors and jitters. The processor can be used for initial, push-button calibration and to permanently adapt signal-path parameters during operation. The angular position is calculated at a programmable resolution of up to 65,536 increments per input cycle and output as an indexed incremental signal. A 32-bit word, which includes the counted cycles, is available through the SPI.

As an application-specific DSP, the iC-TW8 has two ADCs that simultaneously sample at a 250-ksps rate, fast CORDIC algorithms, special signal filters, and an analog front end with differential programmable gate amplifier (PGA) inputs that accepts typical magnetic sensor signals from 20 mVPP and up. Signal frequencies of up to 125 kHz enable high rotary and linear speeds for position measuring devices and are processed at a 24-µs constant latency period.

The device’s 12-bit measurement accuracy works with one button press. Measuring tools are not required. The iC-TW8 independently acquires information about the signal corrections needed for offset, amplitude, and phase errors and stores them in an external EEPROM.

The iC-TW8 has two configuration modes. Preset functions and interpolation factors can be retrieved through pins and the device can be calibrated with a button push. No programming is required for initial operation.

The device’s functions—including an AB output divider for fractional interpolation, an advanced signal filter to reduce jitter, a table to compensate for signal distortion, and configurable monitors for errors and signal quality—can be accessed when the serial interfaces are used. Typical applications include magnetic linear displacement measuring systems, optical linear scales, programmable magnetic/optical incremental encoders, high-resolution absolute/incremental angle sensors with on-axis, Hall scanning, and the general evaluation of sine/cosine signals (e.g., PC measuring cards for 1 VPP and 11 µAPP).

The iC-TW8 operates on a 3.1-to-5.5-V single-ended supply within a –40°C-to-125°C extended operating temperature range. It comes in a 48-pin QFN package that requires 7 mm × 7 mm of board space. A ready-to-operate demo board is  available for evaluation. An optional PC operating program, in other words, a GUI, can be connected with a USB adapter.

The iC-TW8 costs $7.69 in 1,000-unit quantities.

iC-Haus GmbH



Analog Devices AD9675

The AD9675 and the AD9674 are the latest additions to Analog Devices’s octal ultrasound receiver portfolio. The devices and are pin compatible with the AD9670/AD9671.

The AD9675 is an eight-channel ultrasound analog front end (AFE) with an on-chip radio frequency (RF) decimator and Analog Devices’s JESD204B serial interface. It is designed for mid- to high-end portable and cart-based medical and industrial ultrasound systems. The device integrates eight channels of a low-noise amplifier, a variable-gain amplifier, an anti-aliasing filter, and a 14-bit ADC with a 125-MSPS sample rate and a 75-dB signal-to-noise ratio (SNR) performance for enhanced ultrasound image quality. The on-chip RF decimator enables the ADC to be oversampled, providing increased SNR for improved image quality while maintaining lower data I/O rates. The 5-Gbps JESD204B serial interface reduces ultrasound system I/O data routing.

The AD9674 offers similar functionality, but includes a standard low-voltage differential signaling (LVDS) interface. Both devices are available in a 144-ball, 10-mm × 10-mm ball grid array (BGA) package.

The AD9674 and the AD9675 cost $62 and $68, respectively.

Analog Devices, Inc.



Melexis MLX92212

Melexis MLX92212

MLX92212 digital output Hall-effect sensors are AEC-Q100-qualified devices that deliver robust, automotive-level performance. The MLX92212LSE-AAA low-hysteresis bipolar latch and the MLX92212LSE-ABA high-hysteresis unipolar switch are optimized for 2.5-to-5.5-V operation. They pair well with many low-power microcontrollers in embedded systems. The sensor and specified microcontroller can share the same power rail. The sensors’ open-drain outputs enable simple connectivity with CMOS/TTL. They exhibit minimal magnetic switch point drift over temperature (up to 150°C) or lifetime and can withstand 8 kV electrostatic discharge.

The MLX92212LSE-AAA is designed for use with multipole ring magnets or alternating magnetic fields. It is well suited for brushless DC electric motor commutation, speed sensing, and magnetic encoder applications. Typical automotive uses include anti-trap/anti-pinch window lift controls, automatic door/hatch systems, and automatic power seat positioning. The MLX92212LSE-ABA enables the use of generic/weak magnets or larger air gaps. It can be used in simple magnetic proximity sensing and interlocks in covers/hatches or ferrous-vane interrupt sensors for precise position and timing applications.

Both MLX92212 devices utilize chopper-stabilized amplifiers with switched capacitors. The CMOS technology makes this technique possible and contributes to the sensors’ low current consumption and small chip size.

The MLX92212 sensors cost $0.35 each in 5,000-unit quantities and $0.30 in 10,000-unit quantities.

Melexis Microelectronic Integrated Systems



Byte SPI Storm

Byte SPI Storm

The SPI Storm 50 and the SPI Storm 10 are the latest versions of Byte Paradigm’s SPI Storm serial protocol host adapter. The adapters support serial peripheral interface (SPI), Quad-SPI, and custom serial protocols in the same USB device.

The SPI Storm 50 and the SPI Storm 10 support serial protocols and master up to 50 and 10 MHz, respectively. The SPI Storm 10 features an 8-MB memory, while the higher-end devices are equipped with a 32-MB memory.

The SPI Storm adapters enable system engineers to access, communicate, and program their digital board and digital ICs, such as field-programmable gate array (FPGA), flash memories, application-specific integrated circuit (ASIC), and

system-on-a-chip (SoC). The SPI Storm 10 is well suited for engineering schools and universities because it is a flexible, all-around access device for hands-on digital electronics. The 50- and 100-MHz versions can be used in mid- and high-end testing and debugging for telecommunications, medical electronics, and digital imaging industries.

The SPI Storm 50 and the SPI Storm 10 cost $530 and $400, respectively.

Byte Paradigm



Microchip MCP19111

Microchip MCP19111

The MCP19111 digitally enhanced power analog controller is a new hybrid, digital and analog power-management device. In combination with the expanded MCP87xxx family of low-figure-of-merit (FOM) MOSFETs, it supports configurable, high-efficiency DC/DC power-conversion designs for many consumer and industrial applications.

The MCP19111 controller, which operates at 4.5 to 32 V, integrates an analog-based PWM controller with a fully functional flash-based microcontroller. This integration offers the flexibility of a digital solution with the speed, performance, and resolution of an analog-based controller.

The MCP19111 devices have integrated MOSFET drivers configured for synchronous, step-down applications. The MCP87018, MCP87030, MCP87090, and MCP87130 are 25-V-rated, 1.8-, 3-, 9-, and 13-mΩ logic-level MOSFETs that are specifically optimized for switched-mode-power-supply (SMPS) applications.

The MCP19111 evaluation board includes Microchip’s high-speed MOSFETs. This evaluation board includes standard firmware, which is user-configurable through an MPLAB X IDE graphical user interface (GUI) plug-in. The combined evaluation board, GUI, and firmware enable power-supply designers to configure and evaluate the MCP19111’s performance for their target applications.

The MCP19111 controllers cost $2.81 each and the MCP87018/030/090/130 MOSFETs cost $0.28 each, all in 5,000-unit quantities.

Microchip Technology, Inc.



Ironwood SG-QFE-7011

Ironwood SG-QFE-7011

The SG-QFE-7011 is a high-performance QFP socket for 0.4-mm pitch, 128-pin QFPs. The socket is designed for a

1.6-mm × 14-mm × 14-mm package size with a 16-mm × 16-mm lead tip to tip. It operates at bandwidths up to 10 GHz with less than 1 dB of insertion loss and has a typical 20 mΩ per I/O contact resistance. The socket connects all pins with 10-GHz bandwidth on all connections. The small-footprint socket is mounted with supplied hardware on the target PCB. No soldering is required. The small footprint enables inductors, resistors, and decoupling capacitors to be placed close to the device for impedance tuning.

The SG-QFE-7011’s swivel lid has a compression screw that enables ICs to be quickly changed out. The socket features a floating compression plate to force down the QFP leads on to elastomer. A hard-stop feature is built into the compression mechanism.

The sockets are constructed with high-performance, low-inductance gold-plated embedded wire on elastomer as interconnect material between a device and a PCB. They feature a –35°C-to-100°C temperature range, a 0.15-nH pin self inductance, a 0.025-nH mutual inductance, a 0.01-pF capacitance to ground, and a 2-A per pin current capacity.

The SG-QFE-7011 costs $474.

Ironwood Electronics


Member Profile: John Peterson

John Peterson

John Peterson

Location: Menlo Park, CA

Education: BS and MS, University of Utah

Occupation: Software Developer

Member Status: John has been a subscriber since 2002.

Technical Interests: His interests include user interfaces for embedded systems, field-programmable gate array (FPGA) development, and embedded Internet development.

Most Recent Embedded Tech-Related Purchase: John recently purchased a power supply for one of his designs.

Current Projects: He is currently working on a custom light controller for strings of progammable LED lights.

Thoughts on the Future of Embedded Technology: John feels that smartphones have raised everybody’s expectations for how we interact with everyday things (e.g., cars, appliances, household control, etc.). “Either the phone becomes the interface (via the network) or the gadgets need touchscreen displays,” John said.

Member Profile: Gordon David Dick

Gordon Dick

Location: Stony Plain, AB, Canada (Stony Plain is suburb of Edmonton, home of the Oilers)

Education: MS, the University of Saskatchewan in Saskatoon, SK, Canada

Occupation: Gordon is semi-retired. He used to be an Electronics Technology and Computer Engineering Technology instructor at the Northern Alberta Institute of Technology in Edmonton.

Member Status: Gordon says he used to have Circuit Cellar issues dating back to 1995. “We were getting issues under the ‘college program’ then,” he explained. Later, his department subscribed to the magazine and the issues came directly to Gordon. Then he obtained a personal subscription. “I still have my paper copies containing my own articles. And we bought the CDs to get all the back issues.”

Technical Interests: Gordon has always been interested in electronics, both as a hobby and as a profession. He focused first on audio, then turned to microcontrollers. He has built a few microcontroller-based instruments, some of which have been the topics of his Circuit Cellar articles. “For a time, I was involved in building microcontroller-based dog training equipment. I built a microcontroller-based weather station, which I also wrote an article about. I have several microcontroller-based projects in my home that are specific to my needs. My cold-room temperature controller is microcontroller-based, for example.”

Most Recent Embedded Tech-Related Acquisition: Gordon bought a SparkFun Electronics FG085 frequency generator kit.

Current Projects: He is working with a Freescale Semiconductor MPL3115 pressure/temperature I2C transducer for his weather station. “It has amazing barometric pressure resolution,” Gordon explained.

Client Profile: Parallax, Inc.

Parallax P8X32A Propeller chips

Parallax, Inc.
599 Menlo Drive
Rocklin, CA 95765


Contact: Emily Kurze

Embedded Products/Services: Parallax P8X32A Propeller chip (Part #P8X32A-Q44), Propeller family. The P8X32A Propeller chip is Parallax’s 8-core, 32-bit, 80-MHz microcontroller. P8X32A Quickstart (Part #40000), Quickstart family. The P8X32A Quickstart board, featuring the Propeller chip, is everything you need to begin designing Propeller-based applications.

Product Information: The P8X32A Propeller chip is a modern, easy-to-use and a powerful multicore microcontroller that has the flexibility to propel your design to the next tier of performance and reliability. With eight independent cores at your disposal, developers can easily instantiate any number of custom soft-peripherals from Parallax’s Object Exchange library to enable the chip to fill nearly any role. From generating graphics for a control system’s VGA display to managing fly-by-wire avionics equipment, the 80-MHz Propeller chip makes short work of embedded applications that require real-time execution.

Parallax Propeller QuickStart Board #40000

Q&A: Colin O’Flynn (Engineering and “Pure” Research)

Colin O’Flynn

NAN: Where are you located?

COLIN: I’m currently living in Halifax, Nova Scotia, Canada. I’m originally from Hamilton, Ontario, Canada, and had been living in Edinburgh, Scotland for almost two years before I moved to Halifax.

NAN: How did you become interested in electronics?

COLIN: Like many people in this area, I did start at a very young age. If I had to pin one event as the starting of my life-long interest in electronics, it was getting one of those “20-in-1” kits from RadioShack as a present. My parents always encouraged my interest in electronics, but as they were a commercial airline pilot and a chartered accountant, it wasn’t the case of them initially pushing me in the same direction they started!

My dad found me a few small “learn-to-solder” kits, which I enjoyed. At age 8, I assembled my first real kit, the LED-Tric Christmas tree featured in the December 1994 issue of Popular Electronics. My parents have kept bringing that tree out as a Christmas decoration every year since, and it still works.

Besides my parents, I also had help from local people interested in electronics and became friends with many of the local electronics store owners. I spent many hours building projects from magazines like Electronics Now, Popular Electronics, Circuit Cellar, and the various Forrest M. Mims III books. I find it interesting to see the recent surge in “maker” culture. It’s something that has really been going on for years. Growing up, there wasn’t such a thing as maker spaces, but there were local people with interesting workshops who would share projects. It’s great to see this a little more mainstream now, as it means more opportunities for people to get involved at any stage of their life in this fascinating world.

NAN: What is your current occupation? Are you still consulting for projects related to 802.15.4 wireless communications?

COLIN: I’m currently a graduate student at Dalhousie University pursuing a PhD. I decided to go back to school for the chance to do more “pure” research. It’s also fun to have access to a range of tools I wouldn’t otherwise get—the lab I sit in has an anechoic chamber, for example. And we have most of the latest versions of high-end software like MATLAB (including most of the add-ons), 3-D electromagnetic antenna simulation software, FPGA design software, and so forth.


I’m only loosely involved in 802.15.4 projects for now, and not actively following the latest developments and standards. Having said that, a friend of mine has gotten involved in creating small, wireless modules called RadioBlocks.

They use an IEEE 802.15.4 radio combined with a small ARM Cortex-M0 microcontroller. They use an open-source mesh networking software we created called SimpleMesh, so most of my recent work on 802.15.4 has been around this project. The mesh software is designed to do the basic job of sending a block of data to another node, and otherwise staying out of the way. I previously did a lot of work using IPv6 on such small sensor networks, but haven’t been active in that area lately.

At Dalhousie, I’m working on the area of side-channel analysis of cryptographic systems, specifically power analysis. This area has a simple idea: if you have a microcontroller or other embedded controller, it typically has some internal data bus. When those data lines switch state, it takes power. But the power actually depends on the data. Imagine a databus switching from all 1s to all 0s in a clock cycle, compared to staying at all 1s. Likewise, different operations, such as a MUL compared to a LDI, have different power signatures. If you measure the current consumption on each clock cycle, you can learn something about the data being processed, and then often the secret key. Practically speaking, you can measure this current even with an electromagnetic probe, so you don’t need to physically modify the circuit board.

I gave a presentation at Black Hat Abu Dhabi in December 2012 about some of this work. If you are interested, the slides and white paper are available online at Blackhat.com, or from my personal website NewAE.com. You can see the photo above showing an example of attacking a microcontroller-based smart card. The capture software might look something like where you can see different computations the card is performing directly from the power trace. In this case, each burst is a round of the AES-128 computation.

NAN: Many of your projects include Atmel microcontrollers. Why Atmel?

COLIN: It’s no secret I’ve been a big fan of Atmel’s AVR microcontroller, but it wasn’t my first. I don’t know the exact lineage of my microcontroller work, but one of the first things I learned on was an AMD 2900 Evaluation and Learning Kit. A local electronics store happened to have it in stock. They had gotten it from someone cleaning out old inventory, as even at that time it was old. I added heatsinks, as the several amps it drew when powered with 5 V made a lot of those chips very hot. And, of course, you had to keep the entire board powered up if you didn’t want to lose you program you’d been manually entering. From there, I moved onto a Z80 trainer board, which let you program with a hex-entry keypad, and eventually I moved onto programming it from the computer. I designed a Z80 computer board but never built it—I still have the piece of transparency with the taped out PCB design and photosensitive PCB on which I was to expose it. That’s more than 10 years old now, so I suspect the chemicals in it have degraded a little!

I forget exactly why I picked up the AVRs, but I had one of the first AVRs released, Atmel’s AT90S1200, which I programmed in Assembly. After Assembly, I programmed them in BASIC (using MCS Electronics’s BASCOM-AVR), going as far to write a neural network in

BASCOM-AVR. Even today, I think BASIC gets a bad rap. It was almost the original “Arduino” environment, as you could drop down LCD drivers, ADC, and so forth without ever knowing much about how it worked, and with a really intuitive feel. I moved onto C sometime later, and used C almost exclusively for embedded development since. For some time, I was fairly involved in the tools used in the AVR world, such as WinAVR. Atmel donated a considerable amount of equipment to me, as at the time I was a high school student using these devices for science fair projects. I think that’s a great example of how such corporate donations pay off. I’ve almost exclusively used AVR processors since I am so familiar with them because of that. In addition, as a student with little money but lots of time, I was happy to spend hours each day on AVRFreaks.net or working on open-source tools. While Atmel probably ended up giving me around $3,000 worth of tools, I’m sure the value of work I performed for free in terms of open-source tool contributions or forum posts would be worth many times this.

A funny story around all this work: In undergrad, we used the Atmel AVR microcontrollers. During one of the first labs they distributed a tutorial on how to set up the WinAVR tools and compile your first program. As it turned out, this guide was something I wrote years prior and had posted to the WinAVR website. Sufficient to say, I did OK in that class.

NAN: Tell us about NewAE.com. What kind of information is available on the site?

COLIN: I’ve run NewAE.com since 2001, although it’s not really designed to be the type of website one checks for new content daily. If I’ve spent some time solving a problem that I think other people could use, I’ll put a post up. Sometimes this is a complete project, such as my IEEE 802.15.4 sniffer. Sometimes it’s just a small post, such as how to set up the AVR USB keyboard for 5-V operation, which wasn’t described in the manual. I also use it for keeping copies of any published papers or presentations.

I’ve more recently been posting some ongoing research to the site, including blog posts with ongoing projects, rather than just waiting until it’s completely finished! In that vein, I started a YouTube channel with some technical videos (www.youtube.com/user/colinpoflynn). A big collection of these are from when I taught a digital logic course and recorded all my presentations from that.

My content spans a huge range of topics—everything from showing my students how to get screen captures, to a demonstration of my soldering station, to recordings of my academic paper presentations. I don’t like duplicating work. I’ll only go to the effort of making a video or website post if I really couldn’t find the information elsewhere. Because of this, I don’t have one specific topic you could expect to learn about. I’ve never been aiming to be like EEVBlog!

NAN: You wrote “It’s a SNAP: A Flexible Communications Protocol” (Circuit Cellar 139, 2002) more than 10 years ago. Do you still use SNAP in any of your current projects?

COLIN: I have to admit that I haven’t used SNAP in probably eight years! Of course now, when needing to network devices, I’m more likely to turn to a wireless standard.

NAN: Your article “Open-Source AVR Development” (Circuit Cellar 196, 2006) provides an introduction to the AVR-GCC toolchain for AVR microcontrollers. The article references the Cygwin project and Sourceforge’s WinAVR project. How do these components work in the design?

COLIN: The Cygwin project is still something I use regularly, as it lets you run a variety of Unix-like tools on Windows. The Linux command line is extraordinarily powerful, and it is makes it simple to access things like C compilers, text parsing utilities, and scripting tools. With Cygwin, one can have a Linux-like experience under Windows, which I used in that article to build some of the tools you are developing for AVR. By comparison, WinAVR is just a number of prebuilt tools for the AVR development. While it’s more work to build your own tools, sometimes you require special features that were not available in the premade tools.

NAN: Atmel products have played a starring role in several articles you have published in Circuit Cellar. For example, an AT90S4433 microcontroller was featured in “It’s a SNAP: A Flexible Communications Protocol” (Circuit Cellar 139, 2002), an ATmega88 AVR RISC microcontroller was featured in “Digital Video in an Embedded System” (issue 184, 2005), an AT45DB041 DataFlash and an ATmega88 microcontroller were featured in “Open-Source AVR Development” (issue 187, 2006), and an AT90USBKEY demonstration board was featured in “Advanced USB Design Debugging” (issue 241, 2010). Why Atmel microcontrollers/boards? What do you prefer about these products?

COLIN: As I mentioned before, I have a long history with Atmel products. Because of this, I already have the debug toolchains for their chips and can get projects up very quickly.

When picking boards or products, one of the most important considerations for me is that readers can buy it easily. For me, this means I can get it at DigiKey (and I’ll check Farnell for our UK friends). Part of this comes from being in Canada, where DigiKey was one of the first distributors offering cheap and fast shipping to Canada.

NAN: Are you currently working on or planning any microprocessor-based projects?

Binary Explorer Board

COLIN: My current big project is something I designed over the summer of 2012. It’s called the Binary Explorer Board and is something I used when teaching a course in digital logic at Dalhousie University. I needed a simple, programmable logic board and nothing I could find was exactly right. In particular, I needed something with an integrated programmer, several switches and LEDs, and an integrated breadboard. The students needed to be able to use the breadboard without the CPLD to learn about discretely packaged parts. All the CPLD-based trainers I found didn’t have exactly what I wanted in this regard.

The embedded part is the USB interface using an Atmel AT90USB162 microcontroller, although I plan on later upgrading that to an XMEGA for lower cost and more code room. The firmware is powered by Dean Camera’s excellent open-source USB library called LUFA (www.fourwalledcubicle.com/LUFA.php). This firmware lets students program the CPLD on the board easily over USB. But the cool thing is you can go even further and use the device as a generic programmer for other AVRs or CPLDs/FPGAs. For example, you can mount an AVR on the breadboard, connect it to the USB interface, and program that through the Arduino IDE. The entire board would retail for $35 in single-unit quantity, so it’s cheaper than most textbooks. I’m working on making it a real product with Colorado Micro Devices right now.

The design environment is the standard Xilinx toolchain, although I’ve made a number of predefined projects to make it simple enough for students with zero previous design experience to use. The idea is to get students familiar with the real tools they might see in the industry. Around this project, it’s interesting to note I choose a Xilinx CPLD because of my familiarity with Xilinx devices and design tools. This familiarity comes from years ago when Xilinx donated to me a part for a project I was working on. Now throngs of students will be exposed to Xilinx devices, all because Xilinx was willing to donate some parts to a student.

There is always an assortment of half-finished projects, too. I started designing a battery tester, which could simulate characteristics you’d typically see when driving small wireless nodes from coin-cell batteries. I started planning on using an AVR USB microcontroller and doing all the data logging myself. I then found this LabJack device, which simplified my life a lot, as they had basically a generic USB-based logging/control module.

NAN: What do you consider to be the “next big thing” in the embedded design industry?

COLIN: Wireless and the “Internet of Things” will eventually be a big thing, which means design engineers will need to become more familiar with things like protocols and realistic transmission characteristics. I use the word “realistic,” as part of this world is separating hype from reality. There’s certainly a huge disconnect between the marketing hype around all these various wireless protocols and how well they work in practice. When designing a product that will use a wireless technology, it’s likely some commercial off-the-shelf (COTS) module will be used, so the engineer may think they can remain blissfully unaware of RF or networking things. But the engineer still needs to have a rough idea about how many devices might fit in an area on a single network or the advantage of selecting certain protocols.

Another thing of interest to me is programmable logic, such as FPGAs. It’s been interesting to see the tools that try to turn anybody into an FPGA designer becoming more mainstream, or at least letting you program FPGAs in more common languages (e.g., C/C++). They are still fairly specialized and more likely to be used by a hardware engineer looking to improve productivity, compared to a software engineer who needs to offload an algorithm into a FPGA. But I think they could fairly quickly get to the point that engineers with some FPGA experience could implement considerably more complex designs than they would have otherwise been able to had they been required to design everything from scratch.

In a somewhat similar vein, we are starting to see the availability of multicore devices coming down to embedded levels. Learning to program them in a way to take advantage of these new cores is a useful skill to pick up. I recently started using both the OpenMP API and Cilk++ development software on some of my programs. My work wasn’t targeting an embedded project, but instead regular full-size multicore computers, but it’s still a useful (and fairly simple) skill to pick up.

NAN: Tell us a little about your workbench. What are some of your favorite design tools?

Colin’s Workbench

COLIN: My initial workbench was the kitchen table, although other family members were frequently concerned about eating in the same space as these various items with warning labels about lead. My next workbench was a long, custom-built bench in Hamilton, Ontario. My current bench in Halifax was again custom-built, and I’ll take you few of its features. I’d like to point out by “custom-built” I mean built by myself with a jigsaw and some plywood, not an artesian finely crafted piece of furniture.

Due to a back injury, I work standing up, which you can’t see in the photo. It’s actually quite refreshing, and combined with a good quality antifatigue mat and stool to lean up against means I can work long hours without tiring. A cover comes down to hide everything in my desk, which was a feature partially required by my significant other, who didn’t want guests to see the typical mess of wires it contains. When closed, it also gives it some protection against any rogue water leaks. For my computer, I use a trackball instead of a mouse, and the keyboard and trackball are mounted on a plate tilted underneath the desk in a “negative” tilt angle, adjusted to most natural angle. And, because there is no way to see the keyboard while typing, it tends to keep anyone else from borrowing my computer to look something up!

I’ve wired a ground fault interrupter (GFI) into the desk, so all my power outlets are protected. If I ever did something dumb like dropping a scope ground on a live wire, the GFI socket would at least give me a hope of protecting the scope and myself. There are many outlets above and below the desk, and also a ground jack for the antistatic strap beside the thermal wire strippers. The outlets under the desk let me plug in things in a hidden manner—printers, USB hubs, and other permanent devices get wired in there. I’ve wired a number of USB hubs to the top of my desk, so I typically have around 12 free USB slots. You always seem to run out otherwise!

Most of my tools are off the desk and stored in the drawers to either side. I made the “drawers” just pieces of wood with minimal sides—the idea being most of the time you are placing PCBs or tools down, so the lack of high sides prevents you from piling too much into them! All the cables get stored on hooks to the left of my desk, and I’ve got a whiteboard that sticks up when I’m working on a problem.

SMD Organization

I store all my SMD parts in small envelopes stored in index card holders in the bottom left of my desk. While I’m not a static-phobic, I also didn’t want to use plastic film strips or plastic bags. So the paper envelopes at least I hope don’t generate much static, even if they don’t dissipate it. It’s very easy to label all your parts and also this system holds up to a high dynamic range of stock numbers. For example, capacitors get split into 10.1–99.9 nF, 100 nF, 100.1–999.9 nF, and so forth. Because you seem to end up with loads of 100-nF capacitors, they get their own envelope. It’s trivial to change this division around as you get more parts, or to group part sizes together.

In terms of interesting tools: my soldering station is probably my favorite tool, a Metcal MX500 I got used from eBay. The response time on these is unbelievable. I put a video up to show people just because I’ve been so impressed with it. There are other manufactures that now make stations with the same RF-heating technology I believe, and I always encourage everyone to try one. I’ve been using the DG8SAQ Vector Network Analyzer (VNWA) for a while too. It’s a very affordable way to get familiar with VNA and RF measurements. It’s especially fun to follow along with some of the “Darker Side” columns in Circuit Cellar. Rather than just hearing about the mysterious world of RF, you can do experiments like viewing the response of several different decoupling capacitors mounted in parallel. I’ve got an old TiePie TiePieSCOPE HS801 parallel-port oscilloscope mounted underneath my desk, and still use it today. A lot of my work is digital, so have an Intronix LogicPort digital analyzer, a Beagle USB 480 protocol analyzer, and oodles of microcontroller programming/debug tools from different manufacturers.

Member Profile: Dr. Alexander Pozhitkov

Dr. Alexander Pozhitkov

Dr. Alexander Pozhitkov

Location: Seattle, WA

Education: MS in Chemistry, Moscow State University, PhD in Genetics and Bioinformatics, University of Cologne, Germany

Occupation: Research scientist

Member Status: He has been a subscriber for a year.

Technical Interests: Alex is interested in low-level hardware programming and high-voltage electronics, including vacuum tubes.

Most Recent Embedded Tech-Related Acquisition: He recently received a single-board fanless PC with a solid-state hard drive as a gift.

Current Projects: Alex is further developing the NakedCPU platform he wrote about in his two-part article series, “The NakedCPU,” (Circuit Cellar 259–260, 2012).

Thoughts on the Future of Embedded Technology: Alex says he’s worried that embedded solutions are becoming less transparent. He remembers working with one system that had several DVDs of examples and libraries but it didn’t have a comprehensive guide to the system’s architecture. “As a researcher and someone who wants to get to the bottom of things, such a situation is frustrating. This is certainly my personal researcher’s view. I am not commenting on the application side of increasingly complicated embedded systems.”

Q&A: Stephan Lubbers (Sensory Innovation)

Stephan Lubbers enjoys sensing technology. He is a creative engineer and inventor whose designs often build on his need to monitor data and figure out how things work. Steve and I recently discussed some of his designs, his contest-entry process, his thoughts on the future of embedded technology, and what’s currently happening on his workbench.—Nan Price, Associate Editor

NAN: Where are you located?

Stephan Lubbers

Stephan Lubbers in his workspace

STEVE: I live in Dayton, OH.

NAN: Where did you go to school and what did you study?

STEVE: My formal education is a BS in Computer Science from Wright State University, Fairborn, OH. Outside of schools, I’ve taught myself many things ranging from radio electronics to achieving an extra class amateur radio license, to assorted computer languages, to FPGA programming—all from just sitting down and saying, “Let’s learn this.”

NAN: Tell us about your current occupation.

STEVE: I am employed as a Senior Software Engineer at Beijing West Industries, where I develop embedded systems that go under the hood of high-end automobiles. (BWI is the owner of what was once General Motors’s Suspension and Brakes components company.) If your “Service Vehicle Soon” light comes on, I may have written the code behind it.

NAN: Tell us about your technical interests.

STEVE: My technical interests fall into two categories. I like to build systems around new sensing technologies and I build systems to support ham radio.

I never really thought about specific technical interests until I was asked this question. Looking at the Circuit Cellar contests I’ve entered and exploring my parts closet, I discovered that I have an abundance of sensors and sensor systems. When a new sensing device comes out, I often get one, play with it, and then look around for something to do with it. That usually results in an invention of some kind. I’ve analyzed the motion of rodeo bulls and dogs with microelectromechanical (MEMS) accelerometers, tracked eyeball movements with optical sensors, and computed automobile speeds using both GPS and microwave electronics. I don’t know if it is cause or effect, but I was always amazed by the “tricorder” on Star Trek. Do I like sensors because of Scotty and Mr. Spock? Or did I watch Star Trek because of the gadgets? I don’t know.

My love of electronics led me to amateur radio at a young age. I wasn’t as much interested in talking to other people as I was in exploring the technology that enables people to talk. I had a little success building RF devices but found that I had a real knack for digital systems. I’ve used that ability to create satellite tracking controllers, antenna switchers, and computer-to-radio interfaces.

NAN: How long have you been reading Circuit Cellar?

STEVE: I’ve subscribed to Circuit Cellar since Issue 1. I still believe the tagline that said “Inside the Box Still Counts.”

NAN: You’ve written four articles for Circuit Cellar. Some focus on data logging, monitoring, and analysis. For example, your article “Precision Motion-Sensing System Analyzer” (Circuit Cellar 192, 2006) is about a microcontroller-based, motion-sensing system for bull riders. What inspired you to create this system?

STEVE: Several things came together to spark the creation of the “Precision Motion-Sensing System Analyzer,” a.k.a. the BuckyMeter. I had already begun work on a motion-logging system but had no clear goal in mind. Shortly after the logger started working, Circuit Cellar announced its 2005 design contest. I had a short-term goal of entering the contest with my data logger. But what should I log?

My dad provided the suggestion to strap the logger onto the back of a rodeo bull. My parents had become fascinated by the sport of professional bull riding and thought it would be fun to get behind the scenes by doing this science experiment. One of the questions I had when designing the system was: “What kind of maximum G force can I expect to see?” Nobody had an answer, but the doctors responsible for repairing bull riders thought it was an interesting question. They, too, wanted to know that answer. That question opened a few doors to give us access to some bulls. EE Times printed a humorous article about my experience strapping an electronic device on the back of 1,200 lb of angry cow. It was definitely an experience!

The BuckyMeter hardware went through several iterations. In the end, an off-the-shelf Motorola Z-Star evaluation module could be used to instrument the bull with the added bonus of wireless data logging.

The project died out after a trip to instrument competition-grade bulls from American Bucking Bull, Inc. (ABBI). In hindsight, I learned an important lesson about managing customer expectations. I went to Oklahoma on a mission to collect data and try out an engineering prototype. I think the people I met with were expecting to see a polished product. Their impression, after our meeting, was that an electronic scoring aid was too slow and too complicated.

NAN: Another article, “Electronic Data Logging and Analysis: A How-To Guide for Building a Seizure-Monitoring System” (Circuit Cellar 214, 2008), describes an Atmel ATmega32-based electronic monitoring system that enables pet owners and vets to monitor epileptic seizure patterns in dogs. How does the microcontroller factor into the design?

STEVE: My seizure monitor was an offshoot of the rodeo bull motion-sensing system. The original processor had way more power than was needed and it was difficult to hand solder the part. With a working baseline from the BuckyMeter, it was easy to pick a different chip to work with. I had some experience with Atmel AVRs from a previous Circuit Cellar contest, so I looked at its product line. I had a good estimate for RAM/ROM requirements, and I decided it would be nice to have additional SPI channels to interface with the accelerometers. That led to the selection of the ATmega32. It didn’t hurt that another Atmel contest popped up in 2006 when I was in the middle of the design.

I have always wanted to expand my data beyond a single patient to see if my theory held up, so I supplied systems to some other people with epileptic dogs. This required continuous design updates mostly to keep up with outdated parts. Unfortunately, I never got any data back from the systems I gave away. My pet (and science guinea pig) passed away a few years ago, so I don’t have a subject to continue with this project.

NAN: At the end of your article, “Doppler Radar Design” (Circuit Cellar 243, 2010), you note that upgrades to the project (e.g., an enclosure and a portable power supply) could make the system “an easy-to-use mobile device.” Tell us about the design. Did you end up implementing any of those upgrades?

STEVE: Doppler Radar Design has been my most popular project. I get e-mails all the time asking how to reproduce it. As I stated in the article, the RF section is now hard to come by and expensive. Not being an RF engineer, I haven’t been able to recommend replacement parts.

The project started when my dad loaned me the microwave electronics to play with. He had wired them up for two-way ham radio communications. I couldn’t manage to make any radio contact with anybody but myself, so I started looking for other experiments to perform. In one of the experiments, I learned how to make a motion detector. From that, I decided to try to turn the project into a speed radar.

This project took help from a lot of other people because I really didn’t know what I was doing. Some radar discussions on the Internet outlined the basic design for Doppler speed radar, so I followed the suggestions, essentially a transmitter/receiver pair supplied by my borrowed Gunnplexer and a frequency detector (FFT) to show the Doppler shift of the returned signal. Accounting for the radio frequency in use gives you the speed of the reflected target, which in my case was a car.

When I discovered Ramsey Electronics sells a radar kit for $100, I decided that my Doppler radar was really just a science experiment. It was educational for me, but for everyone who contacted me just wanting to have their own radar, the Ramsey option was cheaper, more accurate, and already packaged for portability.

I did get some helpful hints from Alan Rutz at SHF Microwave Parts Company, who suggested something called a dielectric resonator oscillator (DRO) could be used in place of the Gunnplexer I used. The advantage of his approach is that DROs are available and cost about $20. I have not yet been successful with this upgrade.

NAN: The Renesas Electronics RX62N development board is at the heart of your KartTracker’s monitoring system (“KartTracker: A GPS-Based Vehicle Timing & Monitoring System,” Circuit Cellar 259, 2012). Tell us about the design and how the KartTracker functions.


KartTracker: A GPS-Based Vehicle Timing & Monitoring System

STEVE: The KartTracker came about one day when the neighborhood NASCAR fans went out racing karts. We wondered how fast we went, so the local engineer (me) set about finding out.

I started with a GPS receiver and a data logger and drove around the track to see what happened. As it turns out, GPS receivers automatically give you your speed! That was too easy, so I started looking for more features.

The next couple of races I watched, I tried to pay attention to more than just the action and saw that teams were very concerned with lap times. Well, I could time my laps, but that didn’t seem very interesting or complicated enough. Then I saw a qualifying session where the TV showed a continuous real-time comparison between two cars. That seemed cool! If I could build that, I could race myself to see if I was doing better or worse.

So, the KartTracker concept was born. A GPS receiver feeds continuous position data into a Renesas RX62N board. The software continuously compares my time at some location against the last time I was there. It’s like looking at the lap time, but it updates every couple of seconds so you have continuous feedback.

All the timing data is retained so later we can compare times against each other and brag about who went the fastest. I would like to broadcast the times back to the spectators, but that radio is a project for another day.

NAN: You received an Honorable Mention for your 2010 Texas Instruments DesignStellaris Design Contest entry, “Hands-Free USB Mouse.” Tell us about the project and your contest-entry process.

Hands-Free USB Mouse

2010 Texas Instruments DesignStellaris Design Contest Honorable Mention “Hands-Free USB Mouse”

STEVE: My eyePOD hands-free USB Mouse is a head-mounted motion sensor that controls the mouse cursor on a PC. By moving your head, the mouse moves around the screen. You wink your eyes to click the mouse buttons. The goal was to produce a PC interface for someone who couldn’t use a typical mouse, with a secondary goal of teaching me about USB. There are some problems in certain lighting conditions, but overall it works pretty well.

After about a dozen contest entries, I have a bit of a process for creating an entry. I hope I don’t hurt my future chances by sharing my secrets, but since you asked, three things need to line up for me to start a project (contest or otherwise): I need an idea, I need some technology, and I need motivation.

Author James Rollins says, “Don’t ask where the ideas come from.” But, if you have to know, his story ideas come from a box. My contest ideas come from a little red notebook. In reality, we don’t know where the actual ideas come from, but when we get ideas we put them in the box (or book) and make a withdrawal when we need to use an idea.

Part two is that there needs to be a technology that will support the idea. I couldn’t build a rodeo bull monitor until there were cheap accelerometers available. I couldn’t build the KartTracker without a GPS. So, keep a list of technologies you like in your box of ideas.

Finally, you need motivation to execute the project. At work, your boss provides the motivation in the form of a paycheck. At home, you might have a dog that needs help or a neighbor who supplies beer for the answer of how fast his kart is. When I put the three pieces together, I have the starting point for a project. Apply your abilities and start building.

The only biggie after that is time management. Somewhere there is a deadline you need to meet. Do consistent work on your project and prioritize what needs to be done. I have a knack for drawing a line through the critical parts of a project to make sure I have something working when the end is near. You can always go back and improve a working project, but if you have too many half-built features, you have nothing to fall back on when time runs out. A good example is the radio link for the KartTracker. Without GPS and timing software, the project would be nothing. When I had time remaining, I added file I/O and data storage on an SD card. Nice features, but they weren’t necessary to demonstrate the project. The radio link fell by the wayside when entry time came up.

Finally, don’t forget the book report at the end. The judges need to know what you did, so you need to write about it. Who knows? Circuit Cellar might like what you wrote and decide to turn it into an article.

NAN: Have you recently purchased any embedded technology tools to help you with your data logging, monitoring, and analysis projects?

STEVE: My most recent tech purchase was an iPod Touch funded from a recent Circuit Cellar publication. Before you say, “That’s not embedded,” let me explain. I tend to make the user interfaces to my projects simple and to the point. Circuit Cellar contest deadlines don’t lend themselves to creating a new fancy interface for each project. Instead, I would offload debugging, control, and extra features to an external system. I started out using RS-232 serial to a PC. For portability and speed, I moved to a PalmPilot with an infrared data access  (IrDA) interface. A Bluetooth or Wi-Fi interface seems like a logical progression to me. The iPod Touch has these interfaces and it leaves me with a new gadget to play with.

A more embedded acquisition is the Texas Instruments MetaWatch. If you haven’t seen one of these, it’s a stylish digital watch that talks to your smartphone. For the more adventurous, the source code is available so you can add your own features. There must be something great that I can do with a wrist-mounted computer, I just haven’t had the “ah-ha” moment yet.

NAN: Are you currently working on or planning any embedded-design-related projects?

STEVE: I call my current project the SeeingEye for a dog. The blind have used guide dogs since the 16th century. That’s a huge debt man owes his best friend! To help repay that debt, I’m creating a twist on the seeing eye dog by creating a seeing eye for a friend’s vision-impaired dog. Using the sensors and technology robots use for collision avoidance, the SeeingEye will detect obstacles in a dog’s path. The trick seems to be the user interface to convey the collision avoidance information and training the dog to respond correctly to the stimulus. I figure if microchips in robots can learn to avoid walls, then puppy neurons should be able to do the same thing. I still have more work to do to figure out how to get the sensor to stay in place.

SeeingEye board

SeeingEye for dogs, circuit board


SeeingEye for dogs, in “use”

NAN: Do you have any thoughts on the future of embedded technology?

STEVE: As a builder of embedded systems, I am amazed at all of the things we can do with high-speed processors and multiple megabytes of memory. It seems like if we can imagine it, we can build it.

As a user of embedded technologies, it sometimes seems like the engineers are trying to be too clever by stuffing anything they can into the box whether those features are needed or not.

The complexity of some devices has skyrocketed to the point that stability has been affected and users don’t know what features they have or how to use them. We now take for granted a constant stream of software updates to our devices and press reset when it doesn’t work as desired.

Einstein is credited with saying, “Everything should be made as simple as possible, but no simpler.” I’d like to see the industry adopt Einstein’s advice and the “Keep it simple, stupid!” (KISS) principle to help us manage the growing complexities. We’d spend less time serving our devices by trying to make them work and more time being served by our devices as they flawlessly do the work we want done.

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:


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.


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.


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.


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!

Member Profile: Thomas Struzik

Member Thomas Struzik at his bench.


  • Member Name: Thomas Struzik
  • Location: Houston, TX
  • Education: BSEE, Purdue University
  • Occupation: Software architect
  • Member Status: He has been a subscriber since day one. “I’ve got Issue 1 sitting in a box somewhere,” he said. Thomas adds that he was a BYTE magazine subscriber before Circuit Cellar.
  • Technical Interests: Thomas enjoys automation through embedded technology, robotics, low-level programming, and electronic music generation / enhancement.
  • Most Recent Embedded Tech-Related Purchase: He recently bought a CWAV USBee SX Digital Test Pod and an Atmel AVR Dragon.
  • Current and Recent Projects: Thomas is working on designing an isolated USB power supply for his car.
  • Thoughts on the Future of Embedded Technology: Ever-increasing complexity is becoming a stumbling block for the “average” user. “Few people even realize the technology embedded in everyday items,” he said. “How many people know that brand-new LCD TV they’ve got is actually running Linux under the covers? Fortunately, there seems to be a resurgence of ‘need-to-know how stuff works’ with the whole DIY/maker culture. But even that is still a small island compared to the population in general.”

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.

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.