Seven-Controller EtherCAT Orchestra

When I first saw the Intel Industrial Control in Concert demonstration at Design West 2012 in San Jose, CA, I immediately thought of Kurt Vonnegut ‘s 1952 novel Player Piano. The connection, of course, is that the player piano in the novel and Intel’s Atom-based robotic orchestra both play preprogrammed music without human involvement. But the similarities end there. Vonnegut used the self-playing autopiano as a metaphor for a mechanized society in which wealthy industrialists replaced human workers with automated machines. In contrast, Intel’s innovative system demonstrated engineering excellence and created a buzz in the in the already positive atmosphere at the conference.

In “EtherCAT Orchestra” (Circuit Cellar 264, July 2012), Richard Wotiz carefully details the awe-inspiring music machine that’s built around seven embedded systems, each of which is based on Intel’s Atom D525 dual-core microprocessor. He provides information about the system you can’t find on YouTube or hobby tech blogs. Here is the article in its entirety.

EtherCAT Orchestra

I have long been interested in automatically controlled musical instruments. When I was little, I remember being fascinated whenever I ran across a coin-operated electromechanical calliope or a carnival hurdy-gurdy. I could spend all day watching the many levers, wheels, shafts, and other moving parts as it played its tunes over and over. Unfortunately, the mechanical complexity and expertise needed to maintain these machines makes them increasingly rare. But, in our modern world of pocket-sized MP3 players, there’s still nothing like seeing music created in front of you.

I recently attended the Design West conference (formerly the Embedded Systems Conference) in San Jose, CA, and ran across an amazing contraption that reminded me of old carnival music machines. The system was created for Intel as a demonstration of its Atom processor family, and was quite successful at capturing the attention of anyone walking by Intel’s booth (see Photo 1).

Photo 1—This is Intel’s computer-controlled orchestra. It may not look like any musical instrument you’ve ever seen, but it’s quite a thing to watch. The inspiration came from Animusic’s “Pipe Dream,” which appears on the video screen at the top. (Source: R. Wotiz)

The concept is based on Animusic’s music video “Pipe Dream,” which is a captivating computer graphics representation of a futuristic orchestra. The instruments in the video play when virtual balls strike against them. Each ball is launched at a precise time so it will land on an instrument the moment each note is played.

The demonstration, officially known as Intel’s Industrial Control in Concert, uses high-speed pneumatic valves to fire practice paintballs at plastic targets of various shapes and sizes. The balls are made of 0.68”-diameter soft rubber. They put on quite a show bouncing around while a song played. Photo 2 shows one of the pneumatic firing arrays.

Photo 2—This is one of several sets of pneumatic valves. Air is supplied by the many tees below the valves and is sent to the ball-firing nozzles near the top of the photo. The corrugated hoses at the top supply balls to the nozzles. (Source: R. Wotiz)

The valves are the gray boxes lined up along the center. When each one opens, a burst of air is sent up one of the clear hoses to a nozzle to fire a ball. The corrugated black hoses at the top supply the balls to the nozzles. They’re fed by paintball hoppers that are refilled after each performance. Each nozzle fires at a particular target (see Photo 3).

Photo 3—These are the targets at which the nozzles from Photo 2 are aimed. If you look closely, you can see a ball just after it bounced off the illuminated target at the top right. (Source: R. Wotiz)

Each target has an array of LEDs that shows when it’s activated and a piezoelectric sensor that detects a ball’s impact. Unfortunately, slight variations in the pneumatics and the balls themselves mean that not every ball makes it to its intended target. To avoid sounding choppy and incomplete, the musical notes are triggered by a fixed timing sequence rather than the ball impact sensors. Think of it as a form of mechanical lip syncing. There’s a noticeable pop when a ball is fired, so the system sounds something like a cross between a pinball machine and a popcorn popper. You may expect that to detract from the music, but I felt it added to the novelty of the experience.

The control system consists of seven separate embedded systems, all based on Intel’s Atom D525 dual-core microprocessor, on an Ethernet network (see Figure 1).

Figure 1—Each block across the top is an embedded system providing some aspect of the user interface. The real-time interface is handled by the modules at the bottom. They’re controlled by the EtherCAT master at the center. (Source. R. Wotiz)

One of the systems is responsible for the real-time control of the mechanism. It communicates over an Ethernet control automation technology (EtherCAT) bus to several slave units, which provide the I/O interface to the sensors and actuators.


EtherCAT is a fieldbus providing high-speed, real-time control over a conventional 100 Mb/s Ethernet hardware infrastructure. It’s a relatively recent technology, originally developed by Beckhoff Automation GmbH, and currently managed by the EtherCAT Technology Group (ETG), which was formed in 2003. You need to be an ETG member to access most of their specification documents, but information is publicly available. According to information on the ETG website, membership is currently free to qualified companies. EtherCAT was also made a part of international standard IEC 61158 “Industrial Communication Networks—Fieldbus Specifications” in 2007.

EtherCAT uses standard Ethernet data frames, but instead of each device decoding and processing an individual frame, the devices are arranged in a daisy chain, where a single frame is circulated through all devices in sequence. Any device with an Ethernet port can function as the master, which initiates the frame transmission. The slaves need specialized EtherCAT ports. A two-port slave device receives and starts processing a frame while simultaneously sending it out to the next device (see Figure 2).

Figure 2—Each EtherCAT slave processes incoming data as it sends it out the downstream port. (Source: R. Wotiz))

The last slave in the chain detects that there isn’t a downstream device and sends its frame back to the previous device, where it eventually returns to the originating master. This forms a logical ring by taking advantage of both the outgoing and return paths in the full-duplex network. The last slave can also be directly connected to a second Ethernet port on the master, if one is available, creating a physical ring. This creates redundancy in case there is a break in the network. A slave with three or more ports can be used to form more complex topologies than a simple daisy chain. However, this wouldn’t speed up network operation, since a frame still has to travel through each slave, one at a time, in both directions.

The EtherCAT frame, known as a telegram, can be transmitted in one of two different ways depending on the network configuration. When all devices are on the same subnet, the data is sent as the entire payload of an Ethernet frame, using an EtherType value of 0x88A4 (see Figure 3a).

Figure 3a—An EtherCAT frame uses the standard Ethernet framing format with very little overhead. The payload size shown includes both the EtherCAT telegram and any padding bytes needed to bring the total frame size up to 64 bytes, the minimum size for an Ethernet frame. b—The payload can be encapsulated inside a UDP frame if it needs to pass through a router or switch. (Source: R. Wotiz)

If the telegrams must pass through a router or switch onto a different physical network, they may be encapsulated within a UDP datagram using a destination port number of 0x88A4 (see Figure 3b), though this will affect network performance. Slaves do not have their own Ethernet or IP addresses, so all telegrams will be processed by all slaves on a subnet regardless of which transmission method was used. Each telegram contains one or more EtherCAT datagrams (see Figure 4).

Each datagram includes a block of data and a command indicating what to do with the data. The commands fall into three categories. Write commands copy the data into a slave’s memory, while read commands copy slave data into the datagram as it passes through. Read/write commands do both operations in sequence, first copying data from memory into the outgoing datagram, then moving data that was originally in the datagram into memory. Depending on the addressing mode, the read and write operations of a read/write command can both access the same or different devices. This enables fast propagation of data between slaves.

Each datagram contains addressing information that specifies which slave device should be accessed and the memory address offset within the slave to be read or written. A 16-bit value for each enables up to 65,535 slaves to be addressed, with a 65,536-byte address space for each one. The command code specifies which of four different addressing modes to use. Position addressing specifies a slave by its physical location on the network. A slave is selected only if the address value is zero. It increments the address as it passes the datagram on to the next device. This enables the master to select a device by setting the address value to the negative of the number of devices in the network preceding the desired device. This addressing mode is useful during system startup before the slaves are configured with unique addresses. Node addressing specifies a slave by its configured address, which the master will set during the startup process. This mode enables direct access to a particular device’s memory or control registers. Logical addressing takes advantage of one or more fieldbus memory management units (FMMUs) on a slave device. Once configured, a FMMU will translate a logical address to any desired physical memory address. This may include the ability to specify individual bits in a data byte, which provides an efficient way to control specific I/O ports or register bits without having to send any more data than needed. Finally, broadcast addressing selects all slaves on the network. For broadcast reads, slaves send out the logical OR of their data with the data from the incoming datagram.

Each time a slave successfully reads or writes data contained in a datagram, it increments the working counter value (see Figure 4).

Figure 4—An EtherCAT telegram consists of a header and one or more datagrams. Each datagram can be addressed to one slave, a particular block of data within a slave, or multiple slaves. A slave can modify the datagram’s Address, C, IRQ, Process data, and WKC fields as it passes the data on to the next device. (Source: R. Wotiz)

This enables the master to confirm that all the slaves it was expecting to communicate with actually handled the data sent to them. If a slave is disconnected, or its configuration changes so it is no longer being addressed as expected, then it will no longer increment the counter. This alerts the master to rescan the network to confirm the presence of all devices and reconfigure them, if necessary. If a slave wants to alert the master of a high-priority event, it can set one or more bits in the IRQ field to request the master to take some predetermined action.


Frames are processed in each slave by a specialized EtherCAT slave controller (ESC), which extracts incoming data and inserts outgoing data into the frame as it passes through. The ESC operates at a high speed, resulting in a typical data delay from the incoming to the outgoing network port of less than 1 μs. The operating speed is often dominated by how fast the master can process the data, rather than the speed of the network itself. For a system that runs a process feedback loop, the master has to receive data from the previous cycle and process it before sending out data for the next cycle. The minimum cycle time TCYC is given by: TCYC = TMP + TFR + N × TDLY  + 2 × TCBL + TJ. TMP = master’s processing time, TFR = frame transmission time on the network (80 ns per data byte + 5 μs frame overhead), N = total number of slaves, TDLY  = sum of the forward and return delay times through each slave (typically 600 ns), TCBL = cable propagation delay (5 ns per meter for Category 5 Ethernet cable), and TJ = network jitter (determined by master).[1]

A slave’s internal processing time may overlap some or all of these time windows, depending on how its I/O is synchronized. The network may be slowed if the slave needs more time than the total cycle time computed above. A maximum-length telegram containing 1,486 bytes of process data can be communicated to a network of 1,000 slaves in less than 1 ms, not including processing time.

Synchronization is an important aspect of any fieldbus. EtherCAT uses a distributed clock (DC) with a resolution of 1 ns located in the ESC on each slave. The master can configure the slaves to take a snapshot of their individual DC values when a particular frame is sent. Each slave captures the value when the frame is received by the ESC in both the outbound and returning directions. The master then reads these values and computes the propagation delays between each device. It also computes the clock offsets between the slaves and its reference clock, then uses these values to update each slave’s DC to match the reference. The process can be repeated at regular intervals to compensate for clock drift. This results in an absolute clock error of less than 1 μs between devices.


The orchestra’s EtherCAT network is built around a set of modules from National Instruments. The virtual conductor is an application running under LabVIEW Real-Time on a CompactRIO controller, which functions as the master device. It communicates with four slaves containing a mix of digital and analog I/O and three slaves consisting of servo motor drives. Both the master and the I/O slaves contain a FPGA to implement any custom local processing that’s necessary to keep the data flowing. The system runs at a cycle time of 1 ms, which provides enough timing resolution to keep the balls properly flying.

I hope you’ve enjoyed learning about EtherCAT—as well as the fascinating musical device it’s used in—as much as I have.

Author’s note: I would like to thank Marc Christenson of SISU Devices, creator of this amazing device, for his help in providing information on the design.


[1] National Instruments Corp., “Benchmarks for the NI 9144 EtherCAT Slave Chassis,”


Animusic, LLC,

Beckhoff Automation GmbH, “ET1100 EtherCAT Slave Controller Hardware Data Sheet, Version 1.8”, 2010,

EtherCAT Technology Group, “The Ethernet Fieldbus”, 2009,

Intel, Atom microprocessor, www/us/en/processors/atom/atom-processor.html.


Atom D525 dual-core microprocessor

Intel Corp.

LabVIEW Real-Time modules, CompactRIO controller, and EtherCAT devices

National Instruments Corp.

Circuit Cellar 264 is now on newsstands, and it’s available at the CC-Webshop.

Issue 264: A Case for the DIY Electronics Fix

Most of today’s expensive electronics systems are engineered to be left alone—meaning, the manufacturer doesn’t want you opening, servicing, or tweaking the products on your own. But that doesn’t mean intelligent, inquisitive engineers shouldn’t give modern electronics gadgets a good hack. The rewards tend to outweigh the drawbacks. As Steve Ciarcia argues in Circuit Cellar 264 (July), you stand to learn a lot by looking inside electronics systems, especially broken ones. Even if you can’t fix them, you can pull out the components and use them in future projects.

In “Fix It or Toss It?” he writes:

No prophetic diatribes or deep philosophical insights this month. Just the musings of an old guy who apparently doesn’t know when to throw in the towel. Let me explain.

I have a friend with a couple LCD monitors he purchased about two years ago. Perhaps due to continuous duty operation (only interrupted by automatic “Sleep mode”), both were now exhibiting some flakiness, particularly when powering up from “sleep.” More importantly, if power was completely shut down, as in a power failure, they wouldn’t come back on at all without manual intervention. He asked if they could be repaired or must they be replaced.

Since I remembered something about a few manufacturers who’d had a bunch of motherboard problems a while back due to bad electrolytic capacitors, I suspected a power supply problem. Of course, agreeing to look into the problem and figuring out how to get inside the monitors was a whole different issue. Practically all of today’s electronics are not meant to be opened or serviced internally at all. Fortunately, my sledgehammer disassembly techniques weren’t so bad that I couldn’t reassemble them. In the process, I found several bulging and leaking capacitors on the power supply board. After replacing the capacitors, the monitors came right up with no problems.

Power supplies just seem to have it out for me. Recently, I had a wireless router stop working and, after a little diagnosing, I determined that its power supply (an external wall-wart) had failed. While hardly worth my time, I was curious, so I cracked open the sealed case to see just how complicated it was. Sure enough, replacing one scorched electrolytic capacitor and gluing the case back together put me back in business.

All this got me thinking about the relative value of various electronic devices. What is the replace/repair decision line? These $200 high-tech electronic LCD monitors failed because of $3 worth of old-tech components that I was fortunately able to fix. It took time to do the repair that has some value, but it also takes time to shop for and purchase a replacement. There must be better monitors these days for the same price. Should I have told him to toss them and use the opportunity to upgrade?

It’s interesting to consider the type of person who repairs stuff like this (being an EE with a fully equipped lab doesn’t hurt either). I mean, I do it primarily because I like knowing how things work. Okay, so I’m getting a little carried away after fixing a couple burnt capacitors, but there’s still an incredible sense of satisfaction in being able to put something back together and having it work. Since I was a kid, dissecting circuits and equipment helped me understand the design choices that were made, and my curiosity naturally lead me to engineering.

Now, I recognize that people like me who repair their own electronics for curiosity or adventure are very much in the minority. So, what about the average person with a failed piece of $200 electronics? For them, the only goal is getting the functionality back as soon as possible. Do they go to a repair service where it takes longer and involves a couple trips? Worse yet, some things just can’t be repaired, and the bad news then is having both the repair “inspection” cost and the replacement cost. I’m guessing that in 99% of typical cases, the no-brainer decision is to toss the failed unit and buy a new one—without ever giving me a chance to tear it apart and play with it.

Let’s face it. Taking modern equipment apart to make even simple repairs is next to impossible. The manufacturers use every trick in the design book to minimize the cost of the goods. This means leaving out features that might make end-user repair easier. Cases that snap together (once)—or worse, are heat-welded together—are cheaper than cases with screws or latches. Most board electronics are custom-labeled surface mount devices, everything uses custom connectors, and the short cabling between boards has no slack to swing out subassemblies for access, and so forth. You couldn’t even fit a scope probe inside most of this stuff if you tried. Sure, some manufacturers do still put component reference designators in the silkscreen, but I suspect it’s so they can repair subassemblies on their production line before final assembly, not make it easier for me to poke around.

Anyway, like I said, there’s no prophetic conclusion to be drawn from all of this. I fix stuff because I enjoy the challenge and I usually learn something from it. Even if I can’t repair the item, I usually keep some of the useful components and/or subassemblies for experimenter one-off projects or proof-of-concept prototypes. You never know when something in the junk box might prove useful.

Circuit Cellar 264 (July 2012) is now available on newsstands and at the Circuit Cellar Webshop.

Issue 264: EQ Answers

The answers to the Circuit Cellar 264 (July) Engineering Quotient are now available. The problems and answers are listed below, along with a schematic.

Problem 1a—Is it possible to transmit on-off (DC) signals between two pieces of equipment in both directions simultaneously on the same wire, in much the same way that telephones do for audio?

Source: D. Tweed, CC264

Answer 1a—Why not? Hybrids work just as well at DC as they do for audio; you just need a receiver with balanced inputs, like an RS-422 buffer:

All resistors are the same value (e.g., 4,700 Ω) and the transmit driver needs to be a voltage source (low impedance).

If the transmitter switches between, say, 0 V and 5 V, the opposite receiver will see a voltage differential of 0 V and 2.5 V, respectively, while the local receiver will just see 0V.

For long lines, you’ll probably want to use lower resistances and you’ll want to limit the slew rate of the transmitter so that the receiver doesn’t produce glitches on the transitions of the local transmitter.

If the RS-422 receiver is replaced with an op-amp differential amplifier with a gain of 2, then any analog voltage transmitted by one end will be reproduced at the other end.

Problem 1b—But doesn’t a true hybrid use transformers, or at least some tricky transformer simulation with op amps to ensure the transmitted signal does not appear on the receive port?

Answer 1b—No. A hybrid is just a bridge circuit, with one arm of the bridge replaced by the line and the termination at the far end. The transmit signal is applied to two opposite corners of the bridge and the receive signal is taken from the other two corners.

In order to provide the Tx/Rx isolation, the bridge must be balanced, which in the example above, means that the lower resistor on each side must match the impedance of the line/far end combination. For DC and short lines, a simple resistor suffices. At audio frequencies and with the long unshielded twisted pairs used in telephony, a more complex matching impedance is required.

Transformers are used only because it’s the easiest way (and the only passive way) to get a balanced drive and/or receive signal — the transmit driver and receiver cannot share a ground. In order to mass produce phones that were dirt cheap, yet simple and reliable, the phone company figured out how to use a multi-winding transformer to provide the both the isolation and the balanced/unbalanced conversion in both directions, usually with a single resistor and capacitor to provide the line matching. As noted, modern electronic phones use active electronics to achieve the same things.

As always, the theory is simple, but the practical implementations can get complicated.

Problem 2a—The conventional way to calculate the magnitude (length) of a vector is to take the square root of the sum of the squares of its components. On small processors, this can be somewhat difficult (especially the square root operation), and various approximations are used instead.

One approximation that works surprisingly well for 2-D vectors and complex numbers is to take the absolute values of the two components, compare them, then add 1/3 of the smaller to the larger.

What is the maximum error using this method?

Answer 2a—If we restrict the discussion to unit vectors at various angles A, the x component is cos(A) and the y component is sin(A), and the correct magnitude is 1.

Furthermore, let’s concentrate on angles between 0 and 45° — then we know that both cos(A) and sin(A) are positive and that cos(A) > sin(A). (The absolute value and compare operations provide the symmetry that covers the rest of the unit circle.) The approximation then gives the result

Magnitude = cos(A) + sin(A)/3

Graphing this shows that this is most negative (0.943) at 45° and most positive (1.054) at approximately 18.4° (the actual angle is given by atan(1/3) —can you show why?). The peak error is therefore –5.7%, +5.4%.

Problem 2b—Is there a similar formula that gives even better results?

Answer 2b—Yes. One more multiplication operation gives a result that has less than 4% error:

Magnitude = 0.960433 × max(|x|, |y|) + 0.397826 × min(|x|, |y|)

This function is most negative at 0° and 45°, and most positive at 22.5°. The error is ± 3.96%. This form is well-suited to DSPs that have multiply-accumulate units. The two constants can be expressed as 62943/65536 and 26072/65536, respectively.

Contributor: David Tweed

Q&A: Ayse Kivilcim Coskun (Engineer, BU)

Ayse Kivilcim Coskun’s research on 3-D stacked systems has gained notoriety in academia, and it could change the way electrical engineers and chip manufacturers think about energy efficiency for years to come. In a recent interview, the Boston University engineering professor briefed us on her work and explained how she came to focus on the topics of green computing and 3-D systems.

Boston University professor Ayse Kivilcim Coskun

The following is an excerpt from an interview that appears in Circuit Cellar 264 (July 2012), which is currently on newsstands.

NAN: When did you first become interested in computer engineering?

AYSE: I’ve been interested in electronics since high school and in science and physics since I was little. My undergraduate major was microelectronics engineering. I actually did not start studying computer engineering officially until graduate school at University of California, San Diego. However, during my undergraduate education, I started taking programming, operating systems, logic design, and computer architecture classes, which spiked my interest in the area.

NAN: Tell us about your teaching position at the Electrical and Computer Engineering Department at Boston University (BU).

AYSE: I have been an assistant professor at BU for almost three years. I teach Introduction to Software Engineering to undergraduates and Introduction to Embedded systems to graduate students. I enjoy that both courses develop computational thinking as well as hands-on implementation skills. It’s great to see the students learning to build systems and have fun while learning.

NAN: As an engineering professor, you have some insight into what excites future engineers. What “hot topics” currently interest your students?

AYSE: Programming and software design in general are certainly attracting a lot of interest. Our introductory software engineering class is attracting a growing number of students across the College of Engineering every year. DSP, image processing, and security are also hot topics among the students. Our engineering students are very keen on seeing a working system at the end of their class projects. Some project examples from my embedded systems class include embedded low-power gaming consoles, autonomous toy vehicles, and embedded systems focusing on healthcare or security applications …

NAN: How did you come to focus on energy efficiency and thermal challenges?

AYSE: Energy efficiency has been a hot topic for embedded systems for several decades, mainly due to battery-life restrictions. With the growth of computing sources at all levels—from embedded to large-scale computers, and following the move to data centers and the cloud—now energy efficiency is a major bottleneck for any computing system. The focus on energy efficiency and temperature management among the academic community was increasing when I started my PhD. I got especially interested in thermally induced problems as I also had some background on fault tolerance and reliability topics. I thought it would be interesting to leverage job scheduling to improve thermal behavior and my advisor liked the idea too. Temperature-aware job scheduling in multiprocessor systems was the first energy-efficiency related project I worked on.

NAN: In May 2011, you were awarded the A. Richard Newton Graduate Scholarship at the Design Automation Conference (DAC) for a joint project, “3-D Systems for Low-Power High-Performance Computing.” Tell us about the project and how you became involved.

AYSE: My vision is that 3-D stacked systems—where multiple dies are stacked together into a single chip—can provide significant benefits in energy efficiency. However, there are design, modeling, and management challenges that need to be addressed in order to simultaneously achieve energy efficiency and reliability. For example, stacking enables putting DRAM and processor cores together on a single 3-D chip. This means we can cut down the memory access latency, which is the main performance bottleneck for a lot of applications today. This gain in performance could be leveraged to run processors at a lower speed or use simpler cores, which would enable low-power, high-performance computing. Or we can use the reduction in memory latency to boost performance of single-chip multicore systems. Higher performance, however, means higher power and temperature. Thermal challenges are already pressing concerns for 3-D design, as cooling these systems is difficult. The project focuses on simultaneously analyzing performance, power, and temperature and using this analysis to design system management methods that maximize performance under power or thermal constraints.

I started researching 3-D systems during a summer internship at  the Swiss Federal Institute of Technology (EPFL) in the last year of my PhD. Now, the area is maturing and there are even some 3-D prototype systems being designed. I think it is an exciting time for 3-D research as we’ll start seeing a larger pool of commercial 3-D stacked chips in a few years. The A. Richard Newton scholarship enabled us to do the preliminary research and collect results. Following the scholarship, I also received a National Science Foundation (NSF) CAREER award for designing innovative strategies for modeling and management of 3-D stacked systems.

The entire interview appears in Circuit Cellar 264  (July 2012).

Electronics Engineering Crossword (Issue 264)

The answers to Circuit Cellar’s July Electronics Engineer crossword puzzle are now available.

Issue 264 crossword answers


3.     IONIZATION—Occurs when an atom or molecule gains either and positive or negative charge

4.     ANDROIDPHONE—In “Audio-Enhanced Touch Sensors” (Circuit Cellar, May 2012), Matt Oppenheim said one of the stumbling blocks of using this for data collection is that it will try to recharge itself whenever you connect it to a USB port. [two words]

6.     FOLTZER—Circuit Cellar interviewee who participated in Motorola’s IEEE-802 MAC subcommittee on token-passing access control methods. [two words]

13.   COORDINATEDUNIVERSALTIME—A method of keeping the world in sync [three words]

14.   CICCHINELLI—Circuit Cellar published his book about a commonly used computer programming language in 2010

17.   HACKSPACE—i.e, “a circuit cellar”

18.   CHIP—A basic component of an electronic device

19.   VOLTAGEREFERENCE—National Semiconductor’s LM385 series is an example of an adjustable one. [three words]


1.     DOPPLEREFFECT—A phenomenon that occurs when a vehicle sounding a siren approaches, passes, and recedes from an observer [two words]

2.     WAVEFORMGENERATOR—A device that produces electronic signals [two words]

5.     ANGSTROM—Equals 1/10,000,000,000 m

7.     ISOTHERMALPROCESS— ΔT = 0 [two words]

8.     COMPARATOR—A device that compares two voltages or currents and switches its output to indicate which is larger

9.     NSPE—Organization formed in 1934 by bridge engineer David Steinman

10.   EMI—Acronym; common cause of electronic data corruption and subject of Novacek’s December 2011 Circuit Cellar article [two words]

11.   PIEZOELECTRICITY—Occurs when crystals acquire a charge after being compressed, twisted, or distorted (e.g., quartz)

12.   WIDLAR—American electrical engineer (1937–1991); IC pioneer

15.   LEDDRIVER—Circuitry that regulates or provides powers to a light source [two words]

16.   JOULE—Symbolized by 10th letter of the alphabet

20.   RTOS—Hint: acronym. Unscramble the following: IETEORGSEPSMNYMRLTIAEAT

CC264: Plan, Construct, and Secure

Circuit Cellar July 2012 features innovative ideas for embedded design projects, handy design tips with real-world examples, and essential information on embedded design planning and security. A particularly interesting topic covered in this issue is the microcontroller-based home control systems (HCS). Interest in building and HCSes never wanes. In fact, articles about such projects have appeared in this magazine since 1988.

Circuit Cellar 264 (July 2012) is now available.

Turn to page 18 for the first HCS-related article. John Breitenbach details how he built an Internet-enabled, cloud-based attic monitoring system. Turn to page 36 for another HCS article. Tommy Tyler explains how to build a handy MCU-based digital thermometer. You can construct a similar system for your home, or you can apply what you learn to a variety of other temperature-sensing applications. Are you currently working on a home automation design or industrial control system? Check out Richard Wotiz’s “EtherCAT Orchestra” (p. 52). He describes an innovative industrial control network built around seven embedded controllers.

John Breitenbach's DIY leak-monitoring system

The wiring diagram for Tommy Tyler's MCU-based digital thermometer

The rest of the articles in the issue cover essential electrical engineering concepts and design techniques. Engineers of every skill level will find the information immediately applicable to the projects on their workbenches.

Tom Struzik’s article on USB is a good introduction to the technology, and it details how to effectively customize an I/O and data transfer solution (p. 28). On page 44, Patrick Schaumont introduces the topic of electronic signatures and then details how to use them to sign firmware updates. George Novacek provides a project development road map for professionals and novices alike (p. 58). Flip to page 62 for George Martin’s insight on switch debouncing and interfacing to a simple device. On page 68, Jeff Bachiochi tackles the concepts of wireless data delivery and time stamping.

Jeff Bachiochi's hand-wired modules

I encourage you to read the interview with Boston University professor Ayse Kivilcim Coskun on page 26. Her research on 3-D stacked systems has gained notoriety in academia, and it could change the way electrical engineers and chip manufacturers think about energy efficiency for years to come. If you’re an engineer fascinated by “green computing,” you’ll find Coskun’s work particularly intriguing.

Special note: The Circuit Cellar staff dedicates this issue to Richard Alan Wotiz who passed away on May 30, 2012. We appreciate having had the opportunity to publish articles about his inventive projects and innovative engineering ideas and solutions. We extend our condolences to his family and friends.

Circuit Cellar Issue 264 (July 2012) is now available on newsstands. Go to Circuit Cellar Digital and then select “Free Preview” to take a look at the first several pages.

HackMiami: UAV Design, Cybersecurity, & More

Miami isn’t just a destination for the Heat vs. Thunder NBA Finals, world-renowned clubs, five-star restaurants, and professional beach lazing. It also boasts an evolving technology scene with tons of monthly events (e.g., game hackathons, app-building workshops). A notable contributor to the city’s culture of innovation is HackMiami, a hackerspace where professionals, students, and innovators can “invent/develop new technologies, develop new skills, enhance old skills, collaborate with other like minded individuals to create something that is better than what they can do on their own.”

The group’s multitalented members work on projects as diverse as secure servers and UAV designs (see video below).

Below are images Rod—one of the group’s members—submitted of the hackerpace.

HackMiami meets at the "Planet Linux Caffe" (Source: HackMiami)

HackMiami meets at the “Planet Linux Caffe” (Source: HackMiami)

HackMiami runs events such as workshops and contests such as the Homebrew Antenna Contest at DEFCON XX in Las Vegas, NV.

After reviewing the photo submissions, I asked Rod for a bit of info about the group. He quickly filled me in.
C. J.: What are we looking at in the photos? Is that HackMiami’s actual space or are you holding an event a local establishment?

Rod: We hold our meetings at Planet Linux Caffe in Coral Gables, Florida. Planet Linux Caffe is a Open Source community place.

C. J.: What is the group’s “mission” or purpose?

Rod: We are hackerspace based in Miami, FL. We focus on information security and vulnerability research.

C. J.: What is your group like? Do members come from diverse tech backgrounds? How often do you meet?

A HackMiami meeting on the topic of cyber weapons (Source: HackMiami)

A HackMiami meeting on the topic of cyber weapons (Source: HackMiami)

Rod: We have an open-door policy. Everybody welcome, we have people from ALL ages and ALL backgrounds. We meet every two weeks. Here is where we publish our meetings:

C. J.: Does HackMiami do any work with embedded tech (e.g., embedded security, MCU-based designs, etc)?

Rod: We have done some work with DD-WRT, Plug Servers, Pinapples, Arduino, etc.

C. J.: Tell us about the quadracopter project. When did you build it? How many group members were part of it? Can you tell our readers about some of the parts you used (e.g., MCU, motor controls, etc)?

Rod: This was done in December 2011. There were around five people involved in the project. The idea is in principle to create a network of communicating self resilient UAVs. Here is the list of the parts for the drone. For more information please contact Twitter handle @d1sc0rd1an.

Wrapping up, I mentioned to Rod that we’re always looking for interesting projects to share with the embedded design/programming community. He said HackMiami members likely will be working with Raspberry Pi in the near future. Sounds exciting. We can’t wait to see what the group develops.


Show us your hackerspace! Tell us about your group! Where does your group design, hack, create, program, debug, and innovate? Do you work in a 20′ × 20′ space in an old warehouse? Do you share a small space in a university lab? Do you meet a local coffee shop or bar? What sort of electronics projects do you work on? Submit your hackerspace and we might feature you on our website!

In Memoriam: Richard Alan Wotiz

Richard Alan Wotiz—a multitalented electronics engineer, inventor, and author—provided the international embedded design community with creative projects and useful electronics engineering lessons since the early 1980s when he graduated from Princeton University. Sadly, Richard passed away unexpectedly on May 30, 2012 while hiking with a group of friends (a group called “Take a Hike”) in Santa Cruz County, California.

Richard Alan Wotiz

Richard started writing his “Embedded Unveiled” column for Circuit Cellar magazine in 2011. You can read each of his columns by clicking the links below:

Prior to becoming a columnist, Richard placed highly in several international embedded design challenges. Amazingly, he won First Prize in both the Texas Instruments 2010 DesignStellaris Challenge and the 2010 WIZnet iMCU Challenge. That’s right—he won First Place in both of Circuit Cellar’s 2010 design challenges!

Richard published intriguing feature article about some of his prize-winning projects. Interestingly, he liked combining his passion for engineering with his love of the outdoors. When he did so, the results were memorable designs intended to be used outdoors: a backpack water level monitor, an earth field magnetometer, and an ABS brake system for a mountain bike.

Richard’s ABS system is built around a Texas Instruments EKK-LM3S9B96 evaluation board, which contains the Stellaris LM3S9B96 microcontroller and support circuitry. The mechanism mounts to the front fork in place of the reflector, and the control unit sits on a bracket that’s also attached to the handlebars. A veritable maze of wires runs to the various sensors on the brake levers and wheels.

His other projects were well-built systems—such as his single-phase, variable-speed drive for AC induction motors—intended to solve real-world problems or handy DIY designs—such as his “Net Butler” network control system—that he could use in his daily life.

Richard’s single-phase, variable-speed drive for AC induction motors is an excellent device for powerful, yet quiet, pump operation. Designed for use with a capacitor-start/capacitor-run motor, it includes active power factor correction (PFC) and inrush current limiting. This is the drive unit. A Microchip Technology dsPIC30F2020 and all of the control circuitry is at the upper right, with all of the power components below. The line filter and low-voltage supplies are in a separate box to the left. It’s designed to sit vertically with the three large filter capacitors at the bottom, so they stay as cool as possible.

Richard named his finished network control system the “Net Butler.” This innovative multifunctional design can control, monitor, and automatically maintain a home network. Built around a WIZnet iMCU7100EVB, the design has several functions, such as reporting on connected network devices and downloading Internet-based content.

I last saw Richard in March 2012 at the Design West Conference in San Jose, CA. As usual, he stopped by our booth to chat about his work and Circuit Cellar magazine in general. He had a great passion for both, and it showed whenever I spoke with him. He was a true believer of this magazine and its mission. During our chat, he asked if he could write about the seven-processor Intel Industrial Control Robotic Orchestra system on display at the conference. I agreed, of course! His enthusiasm for doing such an article was apparent. Soon thereafter he was at the Intel booth taking photos and notes for his column.

I’m happy to announce that the column—which he titled “EtherCAT Orchestra”—will appear in Circuit Cellar 264 (July 2012).

Richard’s work was a wonderful contribution to this magazine, and we’re grateful to have published his articles. We’re sure Richard’s inventive design ideas and technical insight will endure to help countless more professionals, academics, and students to excel at electronics engineering for years to come.

Q&A: Aubrey Kagan (Engineer, Author)

Aubrey Kagan is a talented engineer with years of experience designing embedded systems. He’s also a prolific author. Between 2000 and 2010 he published 15 articles with Circuit Cellar on topics ranging from developing an AC current generator to resilience in embedded designs. His 2004 book Excel By Example: A Microsoft Excel Cookbook for Electronics Engineers provides tips on using Excel for engineering computations, data analysis, circuit modeling, and more.

In Circuit Cellar 263 (June 2012), Kagan opens up in a candid interview with editor Nan Price. Below is an abridged version of an interview that currently appears in Circuit Cellar 263.

AUBREY KAGAN: I live on the northern edge of Toronto, Ontario, Canada. However, that belies my accent, which the readers obviously cannot hear. I was born and grew up in “deepest, darkest Africa” just north of Rudyard Kipling’s “great gray-green, greasy Limpopo River” (see “How the Elephant Got Its Trunk” from Kipling’s Just So Stories) in what is now called Zimbabwe (then Rhodesia). I did my undergraduate engineering degree at the Technion, Israel Institute of Technology, and then returned to Africa for my MBA at the University of the Witwatersrand in South Africa. My early years in engineering were spent in South Africa, immigrating to Canada in 1989.

NAN PRICE: What is your current occupation?

AUBREY: I am an engineering manager at Emphatec, although managing occupies only a small portion of my day—the majority of my time is engineering. Most of the projects are for industrial monitoring and control. They tend to be a blend of analog and digital approaches and usually are quite compact with only a single function.

Engineer and author Aubrey Kagan

NAN: How long have you been interested in designing embedded systems?

AUBREY: I was given the opportunity to get into embedded design long before anybody thought to call it that. It was in 1977, and all we had were microprocessors, which I was trying to design into HF radio transceivers. I had been struggling with phase lock loops and control of the frequency divider seemed a likely candidate for computer control. Just at that time, there was an article in Popular Electronics on creating an evaluation board for the RCA CDP1802 COSMAC microprocessor. I used that as the basis for the development and as they say, the rest is history.

NAN: Circuit Cellar Online featured your article, “Developing an AC Current Generator” (119, 2000). Tell our newer readers about that project. Do you still use the generator? Have you made any upgrades to it?

AUBREY: That was my first Circuit Cellar article and my only collaborative effort (with Ernesto Gradin). It is probably my favorite project because it is so unusual and remains pertinent to this day.

This AC current generator is one of Kagan’s favorite projects.

Some of the products that we make involve monitoring an AC current and converting the measurement to a 4-to-20-mA analog signal. Some of the devices will measure currents up to 100 A AC. In order to test and calibrate these units, obviously you need an accurate current. If you use a variable AC voltage into a fixed load or a fixed voltage into a variable load to generate the current, you will be working with dangerous voltages and lots of heat. This leads to errors due to heating and more importantly health risks to the operators. We all know in transformers (VIN × IIN) = (VOUT × IOUT) and VIN = (N × VOUT) and so if you make a transformer with a low number of output turns, there is a low output voltage, and for a given power input you can then derive a high current—no heat and very low voltage. To improve the performance, we added a feedback loop with a micro then implemented PID control. The generator is still in use. I have not made any upgrades to it, but I certainly could improve upon it now. I would like to increase its resolution, and of course some of the components are now obsolete, so they would need revision. I might consider onboard displays as well, not control from a PC.

NAN: Your 2002 article series, “Driving the NKK SmartSwitch” (Circuit Cellar 144 and 145), focused on using a Cypress Microsystems programm-able system-on-chip (PSoC) microcomputer as an interface to drive the SmartSwitch. Tell us how this project came about.

AUBREY: Signal conditioning modules in the process-control market tend to be physically small, typically 2” high by 3” deep by 0.75” wide. Of course, there are many much bigger and smaller examples. All of them mount on a rail installed in a panel. Aside from some LED indications, there is very little information you can glean by just looking at the modules. As a result, there has been a slow trend in the industry to add displays to each individual module. Because of the size, the displays are small and are limited to seven-segment displays of up to four digits and sometimes some indicators, if a custom LCD has been used. Also, the displays are invisible when the panel door is closed. The NKK SmartSwitch would allow three lines of six alphanumeric characters and even some graphics. It would also allow the user to change operational parameters for the module. The NKK projects through the panel door and so the information is available to the outside world.

Simply driving the display was the focus of my discussion in Circuit Cellar. At the time, the article had the distinction of being used as an application note by two different companies simultaneously (NKK and Cypress).

But there is much more to the story. If an NKK SmartSwitch and driver were added to a single module, it would probably double the effective price of the module, and so we came up with a networked approach that allowed a single NKK SmartSwitch to be shared among up to 30 different modules spreading the costs and now becoming economically more viable.

Circuit Cellar 263 (June 2012) is now available. Featured on EEWeb is the featured website today on Check it out, and be sure to take advantage of the special offer!

Circuit Cellar celebrates 25 years!

Visit each day for embedded design and programming projects, news, tutorials, and more!

Also, to celebrate the Circuit Cellar’s 25th anniversary, the company has a special archive thumb drive promotion. Check it out. Get 25 years of articles and projects on a 32-GB thumb drive! Click here for details.

Show Your Circuit Cellar, Hackspace, Design Space!

Where do you design, hack, create, program, debug, and innovate? Do you work in a 20′ × 20′ space in your cellar? Do you share a small workspace in a lab at a university? Do you design in your dorm room? Do you work at your office after hours when the 9-to-5 employees are long gone? Have you built a “design cave” in your garage? Do you construct your projects at your local hackspace facility? We want to see where you design and program! Show us your personal circuit cellar or whatever you call your design space!

Email your pics, as well as a short description of the space, to

We might feature your space on our website!

Check out these spaces:

Inside the Elektor lab in Limbricht, The Netherlands (November 2011)


Circuit Cellar columnist Robert Lacoste’s workspace in Chaville, France.


The Elektor Lab November 2011

Laser TV Project: BASCOM Programmers Wanted

Do you have sound programming skills and an interest in assisting a fellow electronics designer with an creative image projection project? If so, the Laser TV Project posted on the “Elektor Projects” website is for you.

The Laser TV Project (Source:

Website editor Clemens Valens writes:

Some people use electronics to build something they need, others just want to find out if something can be done. These projects are often the most fun to read about because of their unusual character and the creativity needed to accomplish the (sometimes bizarre) goal. The laser TV project posted on Elektor Projects is such a project. It is an attempt to project an image by means of 30 rotating mirrors mounted on a VHS head motor. Why you would want to do such a thing is not important, can it be done is the thing that matters.

According to the author the main challenge is the phase synchronization of the top plate on which the mirrors are mounted, and the author is looking for interested BASCOM programmers to develop the motor PLL (or a similar software solution). The motor rotates at 750 rpm and must be precisely synchronized to a pulse, which is available once per revolution.

Do you want to help with this project? Have you done something similar with Atmel and BASCOM? If so, go to and help “hpt” with the project. You can also review other projects and vote. Your vote counts! and are Elektor International Media publications.

Free Webinar: Bridge Android & Your Electronics Projects

Do you want to add a powerful wireless Android device to your own projects? Now you can, and doing so is easier than you think.

With their high-resolution touchscreens, ample computing power, WLAN support, and telephone functions, Android smartphones and tablets are ideal for use as control centers in your projects. But until now, it has been difficult to connect them to external circuitry. Elektor’s AndroPod interface board, which adds a serial TTL port and an RS-485 port to the picture, changes this situation.

The Elektor AndroPod module

In a free webinar on June 21, 2012, Bernhard Wörndl-Aichriedler (codesigner of the AndroPod Interface) will explain how easy it is to connect your own circuitry to an Android smartphone using the AndroPod interface. Click here to register.

Elektor Academy and element14 have teamed up to bring you a series of exclusive webinars covering blockbuster projects from recent editions of Elektor magazine. Participation in these webinars is completely free!

Webinar: AndroPod – Bridging Android and Your Electronics Projects
Date: Thursday June 21, 2012
Time: 16:00 CET
Presenter: Bernhard Wörndl-Aichriedler (Codesigner of the Andropod Interface)
Language: English is an Elektor International Media publication.

A CTO’s Bright & Clean Workspace

Our enthusiasm for bright and clean workspaces won’t wane. A tidy, well-lit space is a must-have for a designer working with microcontrollers, PCBs, and small components such as transistors and capacitors. Fergus Dixon’s Sydney, Australia-based workspace is an excellent example.

Keeping a space clean and bright is key. (Source: F. Dixon)

Dixon submitted the following information about his workspace:

The tools I use include an oscilloscope, function generator, variable DC power supply and desoldering tool. The Oscilloscope is a new Agilent DSP-X 3014A which replaces the old Tektronix TDS210 which lasted for 12 years. I looked into the Chinese Rigol scopes, but while they are value for money, opted to go for a high-end scope. The function generator is a cheap one with an annoying mains hum, and the DC supply is a GPS-3030D which has been going well for over ten years, and another would be useful. The desoldering tool is a Hakko 701 which needs to be replaced with a hot-air gun soon for small SMD work. The workspace has a workbench for assembly of prototypes and a desk. The major issue is being able to store all the parts in a logical way – the new yellow boxes work well with pullout trays for small SMD parts. There are a few new projects this month including an energy meter which is better than the rest and electric fence energizers for farms. Reverse engineering projects are the hardest and most rewarding since you pick up experience from other engineers and see different methods of building circuits.

A narrow workspace can be useful when moving to and from equipment and tools (Source: F. Dixon)

Nice cabinet space and storage for electronics components (Source: F. Dixon)

Dixon is the Chief Technical Officer at Electronic System Design (ESD), which he started to provide hardware and software engineering services to clients. After completing one of ESD’s recent projects for a client, Dixon published an article titled “Smart Switch Management: Construct and MCU-Based, Net-Enabled Controller” in Circuit Cellar 263 (June 2012).

The following excerpt is the introduction to his article about the switch controller.

“Mate, we have a new project for you you’ll like this one,” said my pal from the contract assembly company. New projects are often referred to contract assembly companies and printed circuit board (PCB) designers, so it pays to be on good terms with them. This project was to design a controller for up to 50 smart switches. Smart switches are energy-saving devices installed in office blocks to automatically turn off the lights at the end of the day to conserve energy. The controller needed an accurate real-time clock (RTC) that would pulse a 24-V AC line once or twice to turn off the smart switches at the end of the working day, and repeat at two- to three-hour intervals in case the lights were turned on. After the first prototype was finished, the Ethernet interface was added.

The first prototype featured a Microchip Technology ENC28J60 Ethernet chip on a Vero board.

The design features Microchip Technology ENC28J60 Ethernet chip

You can read the entire article in the June 2012 issue.

Share your space! Circuit Cellar is interested in finding as many workspaces as possible and sharing them with the world. Email editor at to submit photos and information about your workspace. Write “workspace” in the subject line of the email, and include info such as where you’re located (city, country), the projects you build in your space, your tech interests, your occupation, and more. If you have an interesting space, we might feature it on!

Propeller Games (P2): Game Logic

In the first part of this article series on Parallax Propeller-based gaming projects, I hooked up the hardware for the Hi/Lo game on a breadboard. Now I’ll write the game logic. The finished code is available here.

The power of the Propeller chip is in its multiple CPU cores. But you can do just fine with one processor, especially for a simple game like Hi/Lo. You program each of the processors in assembly or in the Parallax-invented SPIN high-level language. Assembly programs run blazingly fast directly in the CPU core. SPIN compiles to a binary format that is interpreted by the SPIN interpreter (written in assembly). The interpreter runs in the CPU core.

The CPU core is designed for speed, but it only has room for 512 instructions. The SPIN interpreter fetches your program byte by byte from shared RAM. Your code runs more slowly, but you have 32K of space to work with. I’ll use assembly in future projects, but SPIN is perfect for Hi/Lo.

A SPIN file is a collection of functions and data (shared by all functions in the file). The functions use local variables kept on a call stack. You break up your programming task into smaller functions that build on one another and call each other. You pass parameters to the functions and use the return values. It is all very similar to C programming though the syntax is different. The interpreter begins with the first function in your file no matter what you name it.

I started the project with a test “main” and the functions to control the Hi/Lo speaker, LEDs, and switches. 

This function plays a tone on the speaker (Source: C. Cantrell)

The “playTone” function generates a square wave on the speaker pin. The “cnt” register is a built-in 32-bit value that increments with every system clock. I run the prop stick full out with an 80-MHz clock configuration (5M-Hz crystal with a *16 internal multiplier). The “waitcnt” instruction puts the CPU to sleep until the system clock reaches the requested value. There are two waits in the loop that generates one clock cycle. Thus the generated frequency is roughly 40 MHz/freq. I say “roughly” because each instruction takes a little time to execute. The actual generated frequency is slightly less. There are much better ways to generate a precise square wave with the propeller hardware, but this is function is easy to understand, and it works fine for the simple Hi/Lo game.

The LED display is a collection of 14 segments and two dots that are turned on or off by writing a 1 or 0 to the Propeller port pins. The program use a look-up table that defines the various segment patterns to be shown.

The output pin bit patterns for numeric digits (Source: C. Cantrell)

The look-up table is defined in a data (DAT) section in the program. The SPIN language allows you to define binary constants with a “%” prefix. You can use the underscore (“_”) anywhere in any numeric constant to make it easier to read. The comment line just above the table shows how the segments map to bit positions in the propeller’s output register.

The “drawNumber” function displays a two digit value on the display. The function first divides the value by 10. The whole part (value/10) is the digit in the 10s place. The remainder (value//10) is the digit in the 1s place. The function looks up the separate patterns, ORs them together, and writes to the “outa” output register to toggle the lights.

I wrote LED functions to “drawBlank” (blank the display) and “drawHi” (show “Hi”) and “drawLo” (show “Lo”). These one-line functions are easy enough to code inline where they are used. But having the functions in distinct blocks makes the using code easier to understand and modify.

The functions to read the buttons return Boolean values: true if the switch is pressed or false if it is not. When a button is pressed, the corresponding input bit in “ina” goes to “1.” There are five buttons and five functions—one for each. There is also an “isAny” function to detect if any button is pressed.

The function returns "true" if a button is pressed. (Source: C. Cantrell)

The game itself has two distinct modes. The “splash” mode flashes “Hi/Lo” and waits for a player to press a button. This is an “attract” mode that draws players to the game. The “splash” function returns when a button has been pressed. The “playGame” function is the game logic. The function returns when the game is over. Thus the main loop simply calls the two functions in an infinite loop.

???????????. (Source: C. Cantrell)

The “splash” function calls “drawHi” and “drawLo” with a pause between.

The function attracts a player to the game. (Source: C. Cantrell)

The “pauseStopOnAnyButton” function counts up the delay and watches for “isAny”. It aborts the pause and returns true if a button is pressed. The “SPLASH_DELAY” is defined in the constant (“CON”) area of the program. I keep all “magic numbers” like delay counts and tone values in the CON area for easy tweaking.

The “playGame” function uses three helper functions: “getPlayerGuess,” “showWin,” and “showHint.” The “showWin” and “showHint” functions are just a couple of lines each and could be coded inline. Having them separate allows you to enhance the visual effects without changing the game logic code.

The “getPlayerGuess” does the real work of the game. It watches the buttons and changes the displayed number accordingly.

The function takes the player input. (Source: C. Cantrell)

The “getPlayerGuess” function is an infinite loop with five IF checks for each button. When the middle button is pressed the function returns with the global “playerGuess” variable holding the input value. The other buttons increment or decrement the digits on the display. Each IF block checks for overflow and plays a feedback tone.

There you have it: a simple Hi Lo game. The visual and input effects are in separate functions ready to be spruced up. I bet your solution has many more bells and whistles! I look forward to reading your ideas in the comments of this blog.

Next time I’ll wrap up the Hi Lo game with a little multitasking. I’ll write parallel programs to run in two new CPU cogs to manage sound effects and the LED display.

Chris Cantrell earned an MSEE from the University of Alabama. He writes Java and Flex for Emerson Network Power in Huntsville, Alabama. Circuit Cellar published 10 of his articles between 2002 and 2012: Issue 145, Issue 152, Issue 161, Issue 184, Issue 187, Issue 193, Issue 205, Issue 209, Issue 139, and Issue 260.