Microcontroller-Based Markov Music Box

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

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

Land writes:

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

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

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

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

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

Japenga writes:

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

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

General Essentials

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

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

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

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

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

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

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

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

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

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

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

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

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

Autonomous Mobile Robot (Part 2): Software & Operation

I designed a microcontroller-based mobile robot that can cruise on its own, avoid obstacles, escape from inadvertent collisions, and track a light source. In the first part of this series, I introduced my TOMBOT robot’s hardware. Now I’ll describe its software and how to achieve autonomous robot behavior.

Autonomous Behavior Model Overview
The TOMBOT is a minimalist system with just enough components to demonstrate some simple autonomous behaviors: Cruise, Escape, Avoid, and Home behaviors (see Figure 1). All the behaviors require left and right servos for maneuverability. In general, “Cruise” just keeps the robot in motion in lieu of any stimulus. “Escape” uses the bumper to sense a collision and then 180 spin with reverse. “Avoid” makes use of continuous forward looking IR sensors to veer left or right upon approaching a close obstacle. Finally “Home” utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source.

Figure 1: High-level autonomous behavior flow

Figure 2 shows more details. The diagram captures the interaction of TOMBOT hardware and software. On the left side of the diagram are the sensors, power sources, and command override (the XBee radio command input). All analog sensor inputs and bumper switches are sampled (every 100 ms automatically) during the Microchip Technology PIC32 Timer 1 interrupt. The bumper left and right switches undergo debounce using 100 ms as a timer increment. The analog sensors inputs are digitized using the PIC32’s 10-bit ADC. Each sensor is assigned its own ADC channel input. The collected data is averaged in some cases and then made available for use by the different behaviors. Processing other than averaging is done within the behavior itself.

Figure 2: Detailed TOMBOT autonomous model

All behaviors are implemented as state machines. If a behavior requests motor control, it will be internally arbitrated against all other behaviors before motor action is taken. Escape has the highest priority (the power behavior is not yet implemented) and will dominate with its state machine over all the other behaviors. If escape is not active, then avoid will dominate as a result of its IR detectors are sensing an object in front of the TOMBOT less than 8″ away. If escape and avoid are not active, then home will overtake robot steering to sense track a light source that is immediately in front of TOMBOT. Finally cruise assumes command, and takes the TOMBOT in a forward direction temporarily.

A received command from the XBee RF module can stop and start autonomous operation remotely. This is very handy for system debugging. Complete values of all sensors and battery power can be viewed on graphics display using remote command, with LEDs and buzzer, announcing remote command acceptance and execution.

Currently, the green LED is used to signal that the TOMBOT is ready to accept a command. Red is used to indicate that the TOMBOT is executing a command. The buzzer indicates that the remote command has been completed coincident with the red led turning on.

With behavior programming, there are a lot of considerations. For successful autonomous operation, calibration of the photocells and IR sensors and servos is required. The good news is that each of these behaviors can be isolated (selectively comment out prior to compile time what is not needed), so that phenomena can be isolated and the proper calibrations made. We will discuss this as we get a little bit deeper into the library API, but in general, behavior modeling itself does not require accurate modeling and is fairly robust under less than ideal conditions.

TOMBOT Software Library
The TOMBOT robot library is modular. Some experience with C programming is required to use it (see Figure 3).

Figure 3: TOMBOT Library

The entire library is written using Microchip’s PIC32 C compiler. Both the compiler and Microchip’s 8.xx IDE are available as free downloads at www.microchip.com. The overall library structure is shown. At a highest level library has three main sections: Motor, I/O and Behavior. We cover these areas in some detail.

TOMBOT Motor Library
All functions controlling the servos’ (left and right wheel) operation is contained in this part of the library (see Listing1 Motor.h). In addition the Microchip PIC32 peripheral library is also used. Motor initialization is required before any other library functions. Motor initialization starts up both left and right servo in idle position using PIC32 PWM peripherals OC3 and OC4 and the dual Timer34 (32 bits) for period setting. C Define statements are used to set pulse period and duty cycle for both left and right wheels. These defines provide PWM varies from 1 to 2 ms for different speed CCW rotation over a 20-ms period and from 1.5 ms to 1 ms for CC rotation.

Listing 1: All functions controlling the servos are in this part of the library.

V_LEFT and V_RIGHT (velocity left and right) use the PIC32 peripheral library function to set duty cycle. The other motor functions, in turn, use V_LEFT and V_RIGHT with the define statements. See FORWARD and BACKWARD functions as an example (see Listing 2).

Listing 2: Motor function code examples

In idle setting both PWM set to 1-ms center positions should cause the servos not to turn. A servo calibration process is required to ensure center position does not result in any rotation. For the servos we have a set screw that can be used to adjust motor idle to no spin activity with a small Philips screwdriver.

TOMBOT I/O Library

This is a collection of different low level library functions. Let’s deal with these by examining their files and describing the function set starting with timer (see Listing 3). It uses Timer45 combination (full 32 bits) for precision timer for behaviors. The C defines statements set the different time values. The routine is noninterrupt at this time and simply waits on timer timeout to return.

Listing 3: Low-level library functions

The next I/O library function is ADC. There are a total of five analog inputs all defined below. Each sensor definition corresponds to an integer (32-bit number) designating the specific input channel to which a sensor is connected. The five are: Right IR, Left IR, Battery, Left Photo Cell, Right Photo Cell.

The initialization function initializes the ADC peripheral for the specific channel. The read function performs a 10-bit ADC conversion and returns the result. To faciliate operation across the five sensors we use SCAN_SENSORS function. This does an initialization and conversion of each sensor in turn. The results are placed in global memory where the behavior functions can access . SCAN_SENOR also performs a running average of the last eight samples of photo cell left and right (see Listing 4).

Listing 4: SCAN_SENOR also performs a running average of the last eight samples

The next I/O library function is Graphics (see Listing 5). TOMBOT uses a 102 × 64 monchrome graphics display module that has both red and green LED backlights. There are also red and green LEDs on the module that are independently controlled. The module is driven by the PIC32 SPI2 interface and has several control lines CS –chip select, A0 –command /data.

Listing 5: The Graphics I/O library function

The Graphics display relies on the use of an 8 × 8 font stored in as a project file for character generation. Within the library there are also cursor position macros, functions to write characters or text strings, and functions to draw 32 × 32 bit maps. The library graphic primitives are shown for intialization, module control, and writing to the module. The library writes to a RAM Vmap memory area. And then from this RAM area the screen is updated using dumpVmap function. The LED and backlight controls included within these graphics library.

The next part of I/O library function is delay (see Listing 6). It is just a series of different software delays that can be used by other library function. They were only included because of legacy use with the graphics library.

Listing 6: Series of different software delays

The next I/O library function is UART-XBEE (see Listing 7). This is the serial driver to configure and transfer data through the XBee radio on the robot side. The library is fairly straightforward. It has an initialize function to set up the UART1B for 9600 8N1, transmit and receive.

Listing 7: XBee library functions

Transmission is done one character at a time. Reception is done via interrupt service routine, where the received character is retrieved and a semaphore flag is set. For this communication, I use a Sparkfun XBee Dongle configured through USB as a COM port and then run HyperTerminal or an equivalent application on PC. The default setting for XBee is all that is required (see Photo 1).

Photo 1: XBee PC to TOMBOT communications

The next I/O library function is buzzer (see Listing 8). It uses a simple digital output (Port F bit 1) to control a buzzer. The functions are initializing buzzer control and then the on/off buzzer.

Listing 8: The functions initialize buzzer control

TOMBOT Behavior Library
The Behavior library is the heart of the autonomous TOMBOT and where integrated behavior happens. All of these behaviors require the use of left and right servos for autonomous maneuverability. Each behavior is a finite state machine that interacts with the environment (every 0.1 s). All behaviors have a designated priority relative to the wheel operation. These priorities are resolved by the arbiter for final wheel activation. Listing 9 shows the API for the entire Behavior Library.

Listing 9: The API for the entire behavior library

Let’s briefly cover the specifics.

  • “Cruise” just keeps the robot in motion in lieu of any stimulus.
  • “Escape” uses the bumper to sense a collision and then 180° spin with reverse.
  • “Avoid” makes use of continuous forward looking IR sensors to veer left or right upon approaching a close obstacle.
  • “Home” utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source.
  • “Remote operation” allows for the TOMBOT to respond to the PC via XBee communications to enter/exit autonomous mode, report status, or execute a predetermined motion scenario (i.e., Spin X times, run back and forth X times, etc.).
  • “Dump” is an internal function that is used within Remote.
  • “Arbiter” is an internal function that is an intrinsic part of the behavior library that resolves different behavior priorities for wheel activation.

Here’s an example of the Main function-invoking different Behavior using API (see Listing 10). Note that this is part of a main loop. Behaviors can be called within a main loop or “Stacked Up”. You can remove or stack up behaviors as you choose ( simply comment out what you don’t need and recompile). Keep in mind that remote is a way for a remote operator to control operation or view status.

Listing 10: TOMBOT API Example

Let’s now examine the detailed state machine associated with each behavior to gain a better understanding of behavior operation (see Listing 11).

Listing 11:The TOMBOT’s arbiter

The arbiter is simple for TOMBOT. It is a fixed arbiter. If either during escape or avoid, it abdicates to those behaviors and lets them resolve motor control internally. Home or cruise motor control requests are handled directly by the arbiter (see Listing 12).

Listing 12: Home behavior

Home is still being debugged and is not yet a final product. The goal is for the TOMBOT during Home is to steer the robot toward a strong light source when not engaged in higher priority behaviors.

The Cruise behavior sets motor to forward operation for one second if no other higher priority behaviors are active (see Listing 13).

Listing 13: Cruise behavior

The Escape behavior tests the bumper switch state to determine if a bump is detected (see Listing 14). Once detected it runs through a series of states. The first is an immediate backup, and then it turns around and moves away from obstacle.

Listing 14: Escape behavior

This function is a response to the remote C or capture command that formats and dumps (see Listing 15) to the graphics display The IR left and right, Photo left and Right, and battery in floating point format.

Listing 15: The dump function

This behavior uses the IR sensors and determines if an object is within 8″ of the front of TOMBOT (see Listing 16).

Listing 16: Avoid behavior

If both sensors detect a target within 8″ then it just turns around and moves away (pretty much like escape). If only the right sensor detects an object in range spins away from right side else if on left spins away on left side (see Listing 17).

Listing 17: Remote part 1

Remote behavior is fairly comprehensive (see Listing 18). There are 14 different cases. Each case is driven by a different XBee received radio character. Once a character is received the red LED is turned on. Once the behavior is complete, the red LED is turned off and a buzzer is sounded.

Listing 18: Remote part 2

The first case toggles Autonomous mode on and off. The other 13 are prescribed actions. Seven of these 13 were written to demonstrate TOMBOT mobile agility with multiple spins, back and forwards. The final six of the 13 are standard single step debug like stop, backward, and capture. Capture dumps all sensor output to the display screen (see Table 1).

Table 1: TOMBOT remote commands

Early Findings & Implementation
Implementation always presents a choice. In my particular case, I was interested in rapid development. At that time, I selected to using non interrupt code and just have linear flow of code for easy debug. This amounts to “blocking code.” Block code is used throughout the behavior implementation and causes the robot to be nonresponsive when blocking occurs. All blocking is identified when timeout functions occur. Here the robot is “blind” to outside environmental conditions. Using a real-time operating system (e.g., Free RTOS) to eliminate this problem is recommended.

The TOMBOT also uses photocells for homing. These sensitive devices have different responses and need to be calibrated to ensure correct response. A photocell calibration is needed within the baseline and used prior to operation.

TOMBOT Demo

The TOMBOT was successfully demoed to a large first-grade class in southern California as part of a Science, Technology, Engineering and Mathematics (STEM) program. The main behaviors were limited to Remote, Avoid, and Escape. With autonomous operation off, the robot demonstrated mobility and maneuverability. With autonomous operation on, the robot could interact with a student to demo avoid and escape behavior.

Tom Kibalo holds a BSEE from City College of New York and an MSEE from the University of Maryland. He as 39 years of engineering experience with a number of companies in the Washington, DC area. Tom is an adjunct EE facility member for local community college, and he is president of Kibacorp, a Microchip Design Partner.

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

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

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

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

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

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

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

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

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

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

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

DIY Green Energy Design Projects

Ready to start a low-power or energy-monitoring microcontroller-based design project? You’re in luck. We’re featuring eight award-winning, green energy-related designs that will help get your creative juices flowing.

The projects listed below placed at the top of Renesas’s RL78 Green Energy Challenge.

Electrostatic Cleaning Robot: Solar tracking mirrors, called heliostats, are an integral part of Concentrating Solar Power (CSP) plants. They must be kept clean to help maximize the production of steam, which generates power. Using an RL78, the innovative Electrostatic Cleaning Robot provides a reliable cleaning solution that’s powered entirely by photovoltaic cells. The robot traverses the surface of the mirror and uses a high voltage AC electric field to sweep away dust and debris.

Parts and circuitry inside the robot cleaner

Cloud Electrofusion Machine: Using approximately 400 times less energy than commercial electrofusion machines, the Cloud Electrofusion Machine is designed for welding 0.5″ to 2″ polyethylene fittings. The RL78-controlled machine is designed to read a barcode on the fitting which determines fusion parameters and traceability. Along with the barcode data, the system logs GPS location to an SD card, if present, and transmits the data for each fusion to a cloud database for tracking purposes and quality control.

Inside the electrofusion machine (Source: M. Hamilton)

The Sun Chaser: A GPS Reference Station: The Sun Chaser is a well-designed, solar-based energy harvesting system that automatically recalculates the direction of a solar panel to ensure it is always facing the sun. Mounted on a rotating disc, the solar panel’s orientation is calculated using the registered GPS position. With an external compass, the internal accelerometer, a DC motor and stepper motor, you can determine the solar panel’s exact position. The system uses the Renesas RDKRL78G13 evaluation board running the Micrium µC/OS-III real-time kernel.

[Video: ]

Water Heater by Solar Concentration: This solar water heater is powered by the RL78 evaluation board and designed to deflect concentrated amounts of sunlight onto a water pipe for continual heating. The deflector, armed with a counterweight for easy tilting, automatically adjusts the angle of reflection for maximum solar energy using the lowest power consumption possible.

RL78-based solar water heater (Source: P. Berquin)

Air Quality Mapper: Want to make sure the air along your daily walking path is clean? The Air Quality Mapper is a portable device designed to track levels of CO2 and CO gasses for constructing “Smog Maps” to determine the healthiest routes. Constructed with an RDKRL78G13, the Mapper receives location data from its GPS module, takes readings of the CO2 and CO concentrations along a specific route and stores the data in an SD card. Using a PC, you can parse the SD card data, plot it, and upload it automatically to an online MySQL database that presents the data in a Google map.

Air quality mapper design (Source: R. Alvarez Torrico)

Wireless Remote Solar-Powered “Meteo Sensor”: You can easily measure meteorological parameters with the “Meteo Sensor.” The RL78 MCU-based design takes cyclical measurements of temperature, humidity, atmospheric pressure, and supply voltage, and shares them using digital radio transceivers. Receivers are configured for listening of incoming data on the same radio channel. It simplifies the way weather data is gathered and eases construction of local measurement networks while being optimized for low energy usage and long battery life.

The design takes cyclical measurements of temperature, humidity, atmospheric pressure, and supply voltage, and shares them using digital radio transceivers. (Source: G. Kaczmarek)

Portable Power Quality Meter: Monitoring electrical usage is becoming increasingly popular in modern homes. The Portable Power Quality Meter uses an RL78 MCU to read power factor, total harmonic distortion, line frequency, voltage, and electrical consumption information and stores the data for analysis.

The portable power quality meter uses an RL78 MCU to read power factor, total harmonic distortion, line frequency, voltage, and electrical consumption information and stores the data for analysis. (Source: A. Barbosa)

High-Altitude Low-Cost Experimental Glider (HALO): The “HALO” experimental glider project consists of three main parts. A weather balloon is the carrier section. A glider (the payload of the balloon) is the return section. A ground base section is used for communication and display telemetry data (not part of the contest project). Using the REFLEX flight simulator for testing, the glider has its own micro-GPS receiver, sensors and low-power MCU unit. It can take off, climb to pre-programmed altitude and return to a given coordinate.

High-altitude low-cost experimental glider (Source: J. Altenburg)

CC268: The History of Embedded Tech

At the end of September 2012, an enthusiastic crew of electrical engineers and journalists (and significant others) traveled to Portsmouth, NH, from locations as far apart as San Luis Obispo, CA,  and Paris, France, to celebrate Circuit Cellar’s 25th anniversary. Attendees included Don Akkermans (Director, Elektor International Media), Steve Ciarcia (Founder, Circuit Cellar), the current magazine staff, and several well-known engineers, editors, and columnists. The event marked the beginning of the next chapter in the history of this long-revered publication. As you’d expect, contributors and staffers both reminisced about the past and shared ideas about its future. And in many instances, the conversations turned to the content in this issue, which was at that time entering the final phase of production. Why? We purposely designed this issue (and next month’s) to feature a diversity of content that would represent the breadth of coverage we’ve come to deliver during the past quarter century. A quick look at this issue’s topics gives you an idea of how far embedded technology has come. The topics also point to the fact that some of the most popular ’80s-era engineering concerns are as relevant as ever. Let’s review.

In the earliest issues of Circuit Cellar, home control was one of the hottest topics. Today, inventive DIY home control projects are highly coveted by professional engineers and newbies alike. On page 16, Scott Weber presents an interesting GPS-based time server for lighting control applications. An MCU extracts time from GPS data and transmits it to networked devices.

The time-broadcasting device includes a circuit board that’s attached to a GPS module. (Source: S. Weber, CC268)

Thiadmer Riemersma’s DIY automated component dispenser is a contemporary solution to a problem that has frustrated engineers for decades (p. 26). The MCU-based design simplifies component management and will be a welcome addition to any workbench.

The DIY automated component dispenser. (Source: T. Riemersma, CC268)

USB technology started becoming relevant in the mid-to-late 1990s, and since then has become the go-to connection option for designers and end users alike. Turn to page 30 for Jan Axelson’s  tips about debugging USB firmware. Axelson covers controller architectures and details devices such as the FTDI FT232R USB UART controller and Microchip Technology’s PIC18F4550 microcontroller.

Debugging USB firmware (Source: J. Axelson, CC268)

Electrical engineers have been trying to “control time” in various ways since the earliest innovators began studying and experimenting with electric charge. Contemporary timing control systems are implemented in a amazing ways. For instance, Richard Lord built a digital camera controller that enables him to photograph the movement of high-speed objects (p. 36).

Security and product reliability are topics that have been on the minds of engineers for decades. Whether you’re working on aerospace electronics or a compact embedded system for your workbench (p. 52), you’ll want to ensure your data is protected and that you’ve gone through the necessary steps to predict your project’s likely reliability (p. 60).

The issue’s last two articles detail how to use contemporary electronics to improve older mechanical systems. On page 64 George Martin presents a tachometer design you can implement immediately in a machine shop. And lastly, on page 70, Jeff Bachiochi wraps up his series “Mechanical Gyroscope Replacement.” The goal is to transmit reliable data to motor controllers. The photo below shows the Pololu MinIMU-9.

The Pololu MinIMU-9’s sensor axes are aligned with the mechanical gyro so the x and y output pitch and roll, respectively. (Source: J. Bachiochi, CC268)

Autonomous Mobile Robot (Part 1): Overview & Hardware

Welcome to “Robot Boot Camp.” In this two-part article series, I’ll explain what you can do with a basic mobile machine, a few sensors, and behavioral programming techniques. Behavioral programming provides distinct advantages over other programming techniques. It is independent of any environmental model, and it is more robust in the face of sensor error, and the behaviors can be stacked and run concurrently.

My objectives for my recent robot design were fairly modest. I wanted to build a robot that could cruise on its own, avoid obstacles, escape from inadvertent collisions, and track a light source. I knew that if I could meet such objective other more complex behaviors would be possible (e.g., self-docking on low power). There certainly many commercial robots on the market that could have met my requirements. But I decided that my best bet would be to roll my own. I wanted to keep things simple, and I wanted to fully understand the sensors and controls for behavioral autonomous operation. The TOMBOT is the fruit of that labor (see Photo 1a). A colleague came up with the name TOMBOT in honor of its inventor, and the name kind of stuck.

Photo 1a—The complete TOMBOT design. b—The graphics display is nice feature.

In this series of articles, I’ll present lessons learned and describe the hardware/software design process. The series will detail TOMBOT-style robot hardware and assembly, as well as behavior programming techniques using C code. By the end of the series, I’ll have covered a complete behavior programming library and API, which will be available for experimentation.

DESIGN BASICS

The TOMBOT robot is certainly minimal, no frills: two continuous-rotation, variable-speed control servos; two IR (850 nm) analog distance measurement sensors (4- to 30-cm range); two CdS photoconductive cells with good lux response in visible spectrum; and, finally, a front bumper (switch-activated) for collision detection. The platform is simple: servos and sensors on the left and right side of two level platforms. The bottom platform houses bumper, batteries, and servos. The top platform houses sensors and microcontroller electronics. The back part of the bottom platform uses a central skid for balance between the two servos (see Photo 1).

Given my background as a Microchip Developer and Academic Partner, I used a Microchip Technology PIC32 microcontroller, a PICkit 3 programmer/debugger, and a free Microchip IDE and 32-bit complier for TOMBOT. (Refer to the TOMBOT components list at the end of this article.)

It was a real thrill to design and build a minimal capability robot that can—with stacking programming behaviors—emulate some “intelligence.” TOMBOT is still a work in progress, but I recently had the privilege of demoing it to a first grade class in El Segundo, CA, as part of a Science Technology Engineering and Mathematics (STEM) initiative. The results were very rewarding, but more on that later.

BEHAVIORAL PROGRAMMING

A control system for a completely autonomous mobile robot must perform many complex information-processing tasks in real time, even for simple applications. The traditional method to building control systems for such robots is to separate the problem into a series of sequential functional components. An alternative approach is to use behavioral programming. The technique was introduced by Rodney Brooks out of the MIT Robotics Lab, and it has been very successful in the implementation of a lot of commercial robots, such as the popular Roomba vacuuming. It was even adopted for space applications like NASA’s Mars Rover and military seekers.

Programming a robot according to behavior-based principles makes the program inherently parallel, enabling the robot to attend simultaneously to all hazards it may encounter as well as any serendipitous opportunities that may arise. Each behavior functions independently through sensor registration, perception, and action. In the end, all behavior requests are prioritized and arbitrated before action is taken. By stacking the appropriate behaviors, using arbitrated software techniques, the robot appears to show (broadly speaking) “increasing intelligence.” The TOMBOT modestly achieves this objective using selective compile configurations to emulate a series of robot behaviors (i.e., Cruise, Home, Escape, Avoid, and Low Power). Figure 1 is a simple model illustration of a behavior program.

Figure 1: Behavior program

Joseph Jones’s Robot Programming: A Practical Guide to Behavior-Based Robotics (TAB Electronics, 2003) is a great reference book that helped guide me in this effort. It turns out that Jones was part of the design team for the Roomba product.

Debugging a mobile platform that is executing a series of concurrent behaviors can be daunting task. So, to make things easier, I implemented a complete remote control using a wireless link between the robot and a PC. With this link, I can enable or disable autonomous behavior, retrieve the robot sensor status and mode of operations, and curtail and avoid potential robot hazard. In addition to this, I implemented some additional operator feedback using a small graphics display, LEDs, and a simple sound buzzer. Note the TOMBOT’s power-up display in Photo 1b. We take Robot Boot Camp very seriously.

Minimalist System

As you can see in the robot’s block diagram (see Figure 2), the TOMBOT is very much a minimalist system with just enough components to demonstrate autonomous behaviors: Cruise, Escape, Avoid, and Home. All these behaviors require the use of left and right servos for autonomous maneuverability.

Figure 2: The TOMBOT system

The Cruise behavior just keeps the robot in motion in lieu of any stimulus. The Escape behavior uses the bumper to sense a collision and then 180° spin with reverse. The Avoid behavior makes use of continuous forward-looking IR sensors to veer left or right upon approaching a close obstacle. The Home behavior utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source. It all should add up to some very distinct “intelligent” operation. Figure 3 depicts the basic sensor and electronic layout.

Figure 3: Basic sensor and electronic layout

TOMBOT Assembly

The TOMBOT uses the low-cost robot platform (ArBot Chassis) and wheel set (X-Wheel assembly) from Budget Robotics (see Figure 4).

Figure 4: The platform and wheel set

A picture is worth a thousand words. Photo 2 shows two views of the TOMBOT prototype.

Photo 2a: The TOMBOT’s Sharp IR sensors, photo assembly, and more. b: The battery pack, right servo, and more.

Photo 2a shows dual Sharp IR sensors. Just below them is the photocell assembly. It is a custom board with dual CdS GL5528 photoconductive cells and 2.2-kΩ current-limiting resistors. Below this is a bumper assembly consisting of two SPDT Snap-action switches with lever (All Electronics Corp. CAT# SMS-196, left and right) fixed to a custom pre-fab plastic front bumper. Also shown is the solderless breakout board and left servo. Photo 2b shows the rechargeable battery pack that resides on the lower base platform and associated power switch. The electronics stack is visible. Here the XBee/Buzzer and graphics card modules residing on the 32-bit Experimenter. The Experimenter is plugged into a custom carrier board that allows for an interconnection to the solderless breakout to the rest of the system. Finally, note that the right servo is highlighted. The total TOMBOT package is not ideal; but remember, I’m talking about a prototype, and this particular configuration has held up nicely in several field demos.

I used Parallax (Futaba) continuous-rotation servos. They use a three-wire connector (+5 V, GND, and Control).

Figure 5 depicts a second-generation bumper assembly.  The same snap-action switches with extended levers are bent and fashioned to interconnect a bumper assembly as shown.

Figure 5: Second-generation bumper assembly

TOMBOT Electronics

A 32-bit Micro Experimenter is used as the CPU. This board is based the high-end Microchip Technology PIC32MX695F512H 64-pin TQFP with 128-KB RAM, 512-KB flash memory, and an 80-MHz clock. I did not want to skimp on this component during the prototype phase. In addition the 32-bit Experimenter supports a 102 × 64 monographic card with green/red backlight controls and LEDs. Since a full graphics library was already bundled with this Experimenter graphics card, it also represented good risk reduction during prototyping phase. Details for both cards are available on the Kiba website.

The Experimenter supports six basic board-level connections to outside world using JP1, JP2, JP3, JP4, BOT, and TOP headers.  A custom carrier board interfaces to the Experimenter via these connections and provides power and signal connection to the sensors and servos. The custom carrier accepts battery voltage and regulates it to +5 VDC. This +5 V is then further regulated by the Experimenter to its native +3.3-VDC operation. The solderless breadboard supports a resistor network to sense a +9-V battery voltage for a +3.3-V PIC processor. The breadboard also contains an LM324 quad op-amp to provide a buffer between +3.3-V logic of the processor and the required +5-V operation of the servo. Figure 6 is a detailed schematic diagram of the electronics.

Figure 6: The design’s circuitry

A custom card for the XBee radio carrier and buzzer was built that plugs into the Experimenter’s TOP and BOT connections. Photo 3 shows the modules and the carrier board. The robot uses a rechargeable 1,600-mAH battery system (typical of mid-range wireless toys) that provides hours of uninterrupted operation.

Photo 3: The modules and the carrier board

PIC32 On-Chip Peripherals

The major PIC32 peripheral connection for the Experimenter to rest of the system is shown. The TOMBOT uses PWM for servo, UART for XBee, SPI and digital for LCD, analog input channels for all the sensors, and digital for the buzzer and bumper detect. The key peripheral connection for the Experimenter to rest of the system is shown in Figure 7.

Figure 7: Peripheral usage

The PIC32 pinouts and their associated Experimenter connections are detailed in Figure 8.

Figure 8: PIC32 peripheral pinouts and EXP32 connectors

The TOMBOT Motion Basics and the PIC32 Output Compare Peripheral

Let’s review the basics for TOMBOT motor control. The servos use the Parallax (Futaba) Continuous Rotation Servos. With two-wheel control, the robot motion is controlled as per Table 1.

Table 1: Robot motion

The servos are controlled by using a 20-ms (500-Hz) pulse PWM pattern where the PWM pulse can from 1.0 ms to 2.0 ms. The effects on the servos for the different PWM are shown in Figure 9.

Figure 9: Servo PWM control

The PIC32 microcontroller (used in the Experimenter) has five Output Compare modules (OCX, where X =1 , 2, 3, 4, 5). We use two of these peripherals, specifically OC3, OC4 to generate the PWM to control the servo speed and direction. The OCX module can use either 16 Timer2 (TMR2) or 16 Timer3 (TMR3) or combined as 32-bit Timer23 as a time base and for period (PR) setting for the output pulse waveform. In our case, we are using Timer23 as a PR set to 20 ms (500 Hz). The OCXRS and OCXR registers are loaded with a 16-bit value to control width of the pulse generated during the output period. This value is compared against the Timer during each period cycle. The OCX output starts high and then when a match occurs OCX logic will generate a low on output. This will be repeated on a cycle-by-cycle basis (see Figure 10).

Figure 10: PWM generation

Next Comes Software

We set the research goals and objectives for our autonomous robot. We covered the hardware associated with this robot and in the next installment we will describe the software and operation.

Tom Kibalo holds a BSEE from City College of New York and an MSEE from the University of Maryland. He as 39 years of engineering experience with a number of companies in the Washington, DC area. Tom is an adjunct EE facility member for local community college, and he is president of Kibacorp, a Microchip Design Partner.

MCU-Based Prosthetic Arm with Kinect

James Kim—a biomedical student at Ryerson University in Toronto, Canada—recently submitted an update on the status of an interesting prosthetic arm design project. The design features a Freescale 9S12 microcontroller and a Microsoft Kinect, which tracks arm movements that are then reproduced on the prosthetic arm.

He also submitted a block diagram.

Overview of the prosthetic arm system (Source: J. Kim)

Kim explains:

The 9S12 microcontroller board we use is Arduino form-factor compatible and was coded in C using Codewarrior.  The Kinect was coded in C# using Visual Studio using the latest version of Microsoft Kinect SDK 1.5.  In the article, I plan to discuss how the microcontroller was set up to do deterministic control of the motors (including the timer setup and the PID code used), how the control was implemented to compensate for gravitational effects on the arm, and how we interfaced the microcontroller to the PC.  This last part will involve a discussion of data logging as well as interfacing with the Kinect.

The Kinect tracks a user’s movement and the prosthetic arm replicates it. (Source: J. Kim, YouTube)

The system includes:

Circuit Cellar intends to publish an article about the project in an upcoming issue.

CC266: Microcontroller-Based Data Management

Regardless of your area of embedded design or programming expertise, you have one thing in common with every electronics designer, programmer, and engineering student across the globe: almost everything you do relates to data. Each workday, you busy yourself with acquiring data, transmitting it, repackaging it, compressing it, securing it, sharing it, storing it, analyzing it, converting it, deleting it, decoding it, quantifying it, graphing it, and more. I could go on, but I won’t. The idea is clear: manipulating and controlling data in its many forms is essential to everything you do.

The ubiquitous importance of data is what makes Circuit Cellar’s Data Acquisition issue one of the most popular each year. And since you’re always seeking innovative ways to obtain, secure, and transmit data, we consider it our duty to deliver you a wide variety of content on these topics. The September 2012 issue (Circuit Cellar 266) features both data acquisition system designs and tips relating to control and data management.

On page 18, Brian Beard explains how he planned and built a microcontroller-based environmental data logger. The system can sense and record relative light intensity, barometric pressure, relative humidity, and more.

a: This is the environmental data logger’s (EDL) circuit board. b: This is the back of the EDL.

Data acquisition has been an important theme for engineering instructor Miguel Sánchez, who since 2005 has published six articles in Circuit Cellar about projects such as a digital video recorder (Circuit Cellar 174), “teleporting” serial communications via the ’Net (Circuit Cellar 193), and a creative DIY image-processing system (Circuit Cellar 263). An informative interview with Miguel begins on page 28.

Turn to page 38 for an informative article about how to build a compact acceleration data acquisition system. Mark Csele covers everything you need to know from basic physics to system design to acceleration testing.

This is the complete portable accelerometer design. with the serial download adapter. The adapter is installed only when downloading data to a PC and mates with an eight pin connector on the PCB. The rear of the unit features three powerful
rare-earth magnets that enable it to be attached to a vehicle.

In “Hardware-Accelerated Encryption,” Patrick Schaumont describes a hardware accelerator for data encryption (p. 48). He details the advanced encryption standard (AES) and encourages you to consider working with an FPGA.

This is the embedded processor design flow with FPGA. a: A C program is compiled for a softcore CPU, which is configured in an FPGA. b: To accelerate this C program, it is partitioned into a part for the software CPU, and a part that will be implemented as a hardware accelerator. The softcore CPU is configured together with the hardware accelerator in the FPGA.

Are you now ready to start a new data acquisition project? If so, read George Novacek’s article “Project Configuration Control” (p. 58), George Martin’s article “Software & Design File Organization” (p. 62), and Jeff Bachiochi’s article “Flowcharting Made Simple” (p. 66) before hitting your workbench. You’ll find their tips on project organization, planning, and implementation useful and immediately applicable.

Lastly, on behalf of the entire Circuit Cellar/Elektor team, I congratulate the winners of the DesignSpark chipKIT Challenge. Turn to page 32 to learn about Dean Boman’s First Prize-winning energy-monitoring system, as well as the other exceptional projects that placed at the top. The complete projects (abstracts, photos, schematic, and code) for all the winning entries are posted on the DesignSpark chipKIT Challenge website.

Microcontroller-Based Digital Thermometer Display

With the proper microcontroller, a digital temperature sensor, an SD memory card, and a little know-how, you can build a custom outdoor digital thermometer display. Tommy Tyler’s article in the July issue of Circuit Cellar explains how he built such a system. He carefully details the hardware, firmware, and construction process.

The following is an abridged version of Tyler’s project article. (The complete article appears in Circuit Cellar 264.)

Build an MCU-Based Digital Thermometer

by Tommy Tyler

Wondering what to do with your unused digital photo frame? With a little effort, a tiny circuit board assembly can be installed in the frame to transform the colorful thin film transistor (TFT) screen into the “ultimate” outdoor thermometer display (see Photo 1). Imagine a thermometer with real numeric digits (not seven-segment stick figures) large enough to be read from 40¢ to 50¢ away under any lighting conditions. Combine that with a glare-free, high-contrast screen, wide viewing angles, and an accuracy of ±0.5°F without calibration, and you have a wonderful thermometer that is more a work of art than an instrument, and can be customized and proudly displayed.

Almost any size and brand digital photo frame can be used, although one with 4.5″ or 7″ (diagonal) screen size is ideal for 2″-high digits. If you don’t have a discarded frame to use, some bargains are available for less than $30, if you look for them. Search online for overstocked, refurbished, or open-box units. The modifications are easy. Just drill a few holes and solder a few wires. The postage-stamp size PCB is designed with surface-mount components, so it’s small enough to tuck inside the frame. None of the modifications prevent you from using the frame as it was originally intended, to display photographs.

Photo 1: A TFT screen is easily transformed into an outdoor thermometer with the addition of a small circuit board.

PHOTO FRAME DISPLAY

Although digital photo frames vary in details and features, their basic functions are similar. Nearly all of them can store pictures in external memory, usually a small SD card like those used in digital cameras. Most have a half dozen or so push-button switches that control how the frame operates and select what is being displayed. There’s usually a Menu button, an Enter or Select button, and several cursor buttons for navigating through on-screen menus.

Photo frames feature a slideshow viewing mode that automatically steps through pictures in sequence. You can set the time each picture is displayed to your preference. You can also turn off the timer and have a manual, single-step slideshow mode where a selected picture is continuously displayed until another is selected with a button press. That’s the mode of operation used for the thermometer, and it is key to its accuracy.

The photo frame is loaded with images showing every possible temperature, in precise ascending order. Following power-up, the frame enters Slideshow mode displaying the first image in memory, which provides a known starting point. Based on repeated temperature measurements, the frame keeps incrementing or decrementing the image, 1° at a time, until the display matches the true temperature. After this initial synchronization, the display is simply incremented or decremented whenever the temperature rises or falls by 1° or more.

The frame responds so reliably, the display never gets out of sync with the true temperature. Following a power interruption, the thermometer automatically resynchronizes itself. In fact, for an interesting and reassuring demonstration at any time, just momentarily turn off power. Synchronization might take a minute or so due to the system’s response time, but that’s not considered a problem because presumably power interruptions will be infrequent.

CIRCUIT DESCRIPTION

Figure1 shows a schematic of the thermometer. A Microchip Technology PIC18F14K22 microprocessor U1 periodically polls U3, a factory-calibrated “smart” temperature sensor that transmits the digital value of the current temperature via I/O pin RC5. PIC output pins RC4 and RC3 drive sections of U2, a Texas Instruments TS3A4751 quad SPST analog switch with extremely low on-state resistance. Two of these solid-state switches are wired in parallel with the mechanical switches in the frame that increment and decrement the displayed temperature. RC6 provides an auxiliary output in case you are working with a rare photo frame that requires a third switch be actuated to enter Slideshow mode…

Figure 1: This schematic of the thermometer shows a portion of the Coby DP700 photo frame with a voltage comparator input that responds to different voltage levels from its >and< switches.

Figure 1 includes a portion of the Coby DP700 schematic showing such an arrangement. Switches SW3 (>) and SW4 (<) share input Pin 110 of the frame processor chip (U100). SW3 pulls the voltage down to about 1.5 V to increment the display, and SW4 pulls it all the way down to 0 V to decrement it. If you can gain access to the solder terminals of these switches, you can build this project. Using a solid-state analog switch for U2 enables the PIC control board to work with virtually any model photo frame, without having to worry about voltage, polarity, or switch circuit configuration.

PIC output RB7 continually transmits a running narrative of everything the thermometer is doing. Transistor Q1 provides a standard RS-232 serial output at 38400 bps, no parity, and two Stop bits using the DTR pin for pull-up voltage. This is mainly for testing, troubleshooting, or possibly experimenting with firmware changes. The board also includes a standard in-circuit serial programming (ICSP) interface for programming the PIC with a Microchip PICkit2 development programmer/debugger or similar programming tool.

Photo2 shows the thermometer circuit board assembly…

Photo 2: The thermometer circuit board assembly. The five-pin header is a direct plug-in for a Microchip PICkit2 programmer. The three-pin header is the diagnostic serial output.

WHAT’S UNDER THE HOOD?

I used a Coby DP700 photo frame as an example for the project because it is widely available, easy to modify, and has excellent quality for a low price. Figure 2 shows the basic components of this frame…

Figure 2: The Colby DP700 photo frame’s basic components

The ribbon cable is long enough to enable the display to swing open about 90°, but not much more. That makes it awkward to hold it open while making wiring connections, unless you have more hands than I do. One solution is to use a holding fixture made from a scrap of lumber to protect the ribbon cable from stress or damage during modification and testing.

Cut a piece of ordinary 1″ × 4″ pine board exactly 7.5″ long. Chamfer opposite ends of the board at the bottom on one side, and cut a notch in the center of that edge (see Photo 3a). Loosen the bezel and slide it up just far enough so that you can insert the board into the rear enclosure near the bottom, below the lower edge of the bezel (see Photo 3b).

Photo 3a: The lower edge of a pine board is notched and chamfered. b: The board is attached to the rear enclosure near the bottom, below the lower edge of the bezel.

The board’s chamfered corners should clear the inside radius of the rear enclosure. Temporarily tape the bezel and rear enclosure together while you fasten the board in place with two of the four bezel screws. Leave the board installed until you have completed the entire project, including all testing.

When you need to access the main circuit board to solder wires and install the PIC board, swing the bezel and display perpendicular to the rear enclosure like an open book and secure it firmly to the fixture board with masking tape (see Photo 4a). Later, during set up and testing when you need to see the screen, swing the bezel and display back down and secure them to the rear enclosure with masking tape (see Photo 4b).

Photo 4a: The bezel and display are firmly secured to the fixture board with masking tape. b: During setup and testing the bezel and display can be swung down and secured to the rear enclosure with masking tape.

MECHANICAL MODIFICATIONS

The only mechanical modification is adding a 3.5-mm stereo jack to connect the remote temperature sensor. You may be able to drill a 0.25″ hole in the frame and attach the jack with its knurled ring nut. But sometimes the stereo plug sticks out in a way that spoils the appearance of the frame or interferes with mounting it on a wall. Here’s a way to install the jack that keeps it and the sensor cable flat against the rear of the frame and out of sight.

Cut a piece of perforated project board 0.6″ × 0.7″ and enlarge the three to five holes that line up with the terminals on the side of the jack with a 3/32″ drill (see Figure3). The perforated board acts as a spacer for the stereo plug when cemented to the enclosure.

Figure 3: The perforated board spaces the jack away from the rear enclosure to clear the stereo plug.

Before attaching anything to the perforated board, use it as a guide to drill matching terminal holes through the rear enclosure. Select a position low and to the right in the recessed area so it clears the power connector but does not extend below the lower edge of the rear enclosure (see Photo 5)…

Photo 5: Use the perforated board as a drilling guide

FINAL WIRING

Referring to the wiring diagram in Photo 6, first prep the main PCB by attaching six insulated wires about 8″ to 10″ long, one wire to 3.3 V, one wire to ground, two wires to SW4, and two wires to SW3.

Photo 6: Wiring diagram

Solder all nine wires to the PIC board—six from the main PCB and three from the stereo jack. Trim the excess wire length so the PIC board will lie easily in the empty space beside the main PCB. Route the wires so they won’t get pinched when the bezel and display are replaced. Use masking tape to hold everything in place and keep the PIC board from shorting out.

THE WEATHER-PROOF SENSOR

The Microchip DS18S20 digital temperature sensor is a three-lead package the same size as a TO-92 transistor (see Figure 4)…

Insulating short spliced leads with sleeving is always a problem because the sleeving gets in the way of soldering. One way to keep the probe small and strong is to drip a little fast-set epoxy on the soldered leads, after ensuring they aren’t touching, and rotate the unit slowly for a couple of minutes until the epoxy stops running and begins to harden. Weatherproof the entire assembly with an inch or so of 0.25″ heat-shrink tubing.

LOADING IMAGES INTO MEMORY

Some photo frames don’t have internal memory, so I used a plug-in SD memory card for the temperature images. That also makes it easy to change the appearance of the display whenever you want. Any capacity card you can find is more than adequate, since the images average only about 25 KB each and 141 of them is less than 5 MB. A good source for generic 32-MB SD cards is OEMPCWorld. Their SD cards cost less than $4 each, including free shipping via U.S. Postal Service first-class mail. Just search their site for “32-MB SD card.”

A download package is available with images in 16 × 9 format showing temperature over the range from –20 to 120°F in numerals about 2″ high. The 16 × 9 images will naturally fit the Coby screen and most other brands. There’s also a set of 4 × 3 images for frames with that format. Actually, either size will work in any frame. If you use 4 × 3 images in the 16 × 9 Coby with Show Type set up as Fit Screen, there will be bars on the sides. But if it is set up as Full Screen, the images will expand to eliminate the bars, and the numerals will be about 2-5/8” high.

The download filenames have a sequential numeric prefix from 100 to 240, so Windows will list them in order before you copy them to the SD card. Notice that the sequence of images is as follows: 70°, 71°, 72°…119°, 120°, –20°, –19°, –18°…–2°, –1°, 0°, 1°, 2°…67°, 68°, 69°. The first image is not the lowest temperature. That’s so synchronization can start from 70° instead of all the way from –20°. You can split the temperature range like this as long as there are no extraneous pictures on the SD card, because the frame treats the SD card, in effect, as an endless circular memory, wrapping around from the highest to lowest image when incrementing, and from lowest to highest when decrementing…

SETUP & FINAL TEST

It’s always best to make sure frame power is disconnected before plugging or unplugging the temperature sensor. Position the frame so that the screen is visible. Plug in the sensor and SD card, then connect power to the frame. After a few seconds, what you see on the screen will depend on how the frame was last used and set up. It may start showing pictures from internal memory, or it may start showing temperature images from the SD card. In either case, the pictures will probably start changing rapidly for a while because the frame thinks it is synchronizing its initial display to the temperature of the sensor. You can’t use on-screen menus to check the setup of the frame while it is flipping through all those pictures, so you must wait. After a couple minutes, when things settle down and the display stops rapidly changing, press Menu to bring up the main menu. Use the left or right arrow buttons to select the Set Up sub menu, then use the Enter, Left, Right, Up, and Down buttons to set up the following parameters: Interval Time = Off, Transition Effect = No Effect, Show Type = Fit Screen, Magic Slideshow = Off…

After completing all the setup adjustments, momentarily disconnect power from the frame and confirm that it properly powers up. The Coby logo should appear for a few seconds, followed by the first image in memory, the starting temperature of 70°F. About 12 s later, the display should start changing in 1° steps until it gets to the current temperature of the sensor. Warm the sensor with your hand to ensure the sensor is responding.

This is a good time to demonstrate an error indicator designed into the thermometer to alert you if the PIC can’t communicate with the temperature sensor. Disconnect power and unplug the sensor, then restore power with the sensor disconnected. The display will start at 70°F as before, but this time it will keep incrementing until it reaches 99°F, where it will stop. So if you ever notice the display stuck on 99° when you know it’s not that hot outside, check to see if the sensor is unplugged or damaged.

If everything seems to be working properly, you can skip the following section on troubleshooting. Close the frame and start thinking about how and where you will install it…

ABOUT THE FIRMWARE

Credit for design of the PIC firmware goes to Kevin R. Timmerman—a talented freelance software design engineer, and owner of the Compendium Arcana website—who collaborated with me on this project. Kevin’s backyard in Michigan, as well as mine in Colorado, were the beta-test sites for the design.

A firmware download includes the temperature.hex file needed for programming the PIC, as well as the following source files in case you want to make changes:

inverted_main.c

one_wire.c

fuses_14k22.c

one_wire.h

stdint.h

The file named one_wire.c deals exclusively with sending and receiving messages to/from the temperature sensor. If you use a photo frame other than the Coby DP700 that has some special requirements, the only file you might need to modify is inverted_main.c. The firmware is available on the Circuit Cellar FTP site.

UNLIMITED OPTIONS

When you finish the project, you will have the satisfaction of knowing you probably have the most accurate thermometer in the neighborhood—providing you take reasonable precautions in locating the sensor. Don’t place it in sunlight or near heat sources (i.e., vents or ducts). Even placing it too close to a poorly insulated wall, roof, or window can affect its accuracy. There are articles online about the best places to install outdoor thermometers.

Even after you have completed your modifications to the frame and closed it back up, there are endless ways to customize the project to your taste…

For those living overseas or accustomed to expressing temperature in Centigrade, the download includes an alternate set of images covering the range from –28.9°C to 48.9°C. Images such as 70°F, 71°F, 72°F, and so forth are replaced with their Centigrade equivalents 21.1°C, 21.7°C, 22.2°C, and so forth. The thermometer control can’t tell the difference. It goes on incrementing and decrementing images as if it were displaying the temperature in Fahrenheit. By showing temperature in tenths of Centigrade degrees, the thermometer accuracy is unchanged. The temperature sensor is inherently a Centigrade device, and one could modify the PIC firmware to use the reported temperature in degrees C without ever converting it to degrees Fahrenheit. But this method is a lot easier, and enables you to change between Centigrade and Fahrenheit by just swapping the SD card…

Tommy Tyler graduated with honors from Vanderbilt University with a degree in Mechanical Engineering. He retired after a career spanning more than 40 years managing the product design of industrial instrumentation, medical electronics, consumer electronics, and embedded robotic material transport systems. Tommy earned 17 patents from 1960 to 1995. His current hobbies are electronics, technical writing and illustration, and music. Tommy is a contributing expert to the JP1 Forum on infrared remote control technology.

SOURCES

DP700 Digital photo frame

Coby Electronics Corp. | www.cobyusa.com

PIC18F14K22 Microprocessor, DS18S20 digital temperature sensor, and PICkit2 development programmer/debugger

Microchip Technology, Inc. | www.microchip.com

TS3A4751 quad SPST Analog switch

Texas Instruments, Inc. | www.ti.com

The project files (firmware and images) are available on Circuit Cellar’s FTP site. The complete article appears in Circuit Cellar 264.

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.

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: Elektor-Projects.com)

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 Elektor-projects.com and help “hpt” with the project. You can also review other projects and vote. Your vote counts!

CircuitCellar.com and Elektor-projects.com are Elektor International Media publications.

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.

Propeller Games (P1): Hi Lo

Welcome to the Propeller Games! In a few installments, I’ll present several gaming projects that use the Parallax Propeller chip. The Propeller is perfect for gaming with its multiple CPU cores to handle simultaneous gaming activities and its on-board video generation circuitry.

My first game project is the classic “higher/lower” game, where the computer thinks of a number between 0 and 99 and you guess it. You have probably seen this played as the “Clock Game” on The Price is Right TV show, though some contestants struggle with a basic binary search algorithm. (You can watch videos of the game at YouTube.com.)

This entire project is built on a solderless breadboard. If you are new to the Propeller, this is the perfect project to get acquainted with the hardware and programming. If you are a Propeller guru, you will enjoy the nostalgia of gaming on LEDs and push buttons. Grab your breadboard and follow along.

Parts

What you’ll need:

  • Breadboard and wire
  • 9-VDC wall transformer
  • Parallax PropStick USB
  • Two-digit 7-segment LED display
  • Five SPST pushbuttons
  • Audio speaker
  • Sixteen 200-Ω resistors
  • Five 10-kΩ resistors

The board and basic parts

The Parallax Propeller chip requires a few external components. You need a 3.3-VDC power regulator, a crystal, and a USB-to-serial converter. You also need a serial EEPROM if you want the Propeller to run your program at power up. You can buy all these separately and wire them up on the breadboard. Or you can save time and space with the Parallax PropStick USB. It combines all these external parts on the same footprint as the 40-pin Propeller chip.

I bought the LED display for this project from Mouser Electronics (part number 630-HDSP-521E). The large red segments are common anode (common ground). You supply positive voltage from a propeller port pin through a 220-Ω resistor to light the segments.

I bought the push buttons from Pololu Robotics & Electronics (part number 1400). They are specially designed for mounting on a breadboard. One side of each switch is connected to 3.3 V and the other is connected to a propeller port pin and pulled to ground with a 10-kΩ resistor.

I bought the speaker from Digi-Key (part number 668-1140-ND). The negative terminal of the speaker hooks to the breadboard’s ground. The positive terminal hooks directly to a Propeller port pin.

A speaker, one LED segment, and one switch wired to the Propeller

I placed four of the switches on the corners of the display. These switches are used as up/down inputs for each digit allowing the player to select a number from 00 to 99. The fifth button to the right of the display is the “Enter” button.

The photo above shows the speaker, one LED segment, and one switch wired to the Propeller. I tested the hardware and software incrementally as I hooked it up instead of trying to debug the final system as a whole.

The Parallax Propeller Tool is the free graphical Integrated Development Environment (IDE) you use to develop code for the Propeller. The code editor colors and highlights your work making it easy to see functions and keywords. It also manages indentation. The SPIN programming language uses indentation to identify code blocks much as Python does.

Basic hardware test

The code above is my basic hardware test. The CON (constants) section at the top configures the clock speed of the chip: 5 MHz × 16 = 80 MHz. The OBJ (object) section pulls in the serial terminal driver library. This library object allows you to use the USB cable for both programming and an input/output terminal. The one second pause on line 12 gives you time to switch from the IDE program to the terminal program on your PC once the code is downloaded. The Propeller tool download includes the parallax serial terminal for your PC.

Line 10 sets general I/O pin 0 (P0) as an output (they are inputs by default). Line 17 reads the switch connected to P11 and turns the LED segment on or off accordingly. Line 18 prints the state of the input pins to the PC terminal in an infinite loop.

Parallax serial terminal

It took me a while to warm up to the SPIN programming language. It is syntactically very different from C and its derivatives. But conceptually it is familiar: you break your software up into functions and local/global variables. In the end the simplicity of the syntax and the friendliness of the IDE won me over!

I really like the “Propeller font” used in the Propeller Tool IDE. It includes special symbols you can use to draw circuits and timing diagrams in your code comments. For instance:

Check out the font

Now to wire up the rest of the LEDs and switches. I thought about wiring the left digit to the first port byte and the right digit to the second port byte so that the segments are laid out the same way in each byte. This would make the software easier to write. But the pins for the segments on the display are kind of scattered around at random. The wiring is easier and neater if you wire the segments from the bottom of the display to the bottom of the propeller and from the top of the display to the top of the propeller. You can make up for the scattered pattern with software.

Two tips: Wire the segments from the bottom of the display to the bottom of the Propeller. Wire from the top of the display to the top of the Propeller.

Hi/Lo breadboard layout

That’s it for this installment. Now I’ll clean up all the little wire stripping sprinkles I left around my workbench. In Part 2 of this series, I’ll switch modes from hardware to software and write the Hi/Lo game. Hopefully you are following along. Until next time, may the COGs be ever in your favor.

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.

Design West Update: Compilers Unveiled

IAR Systems announced Tuesday at Design West in San Jose, CA, that GainSpan selected IAR Embedded Workbench as its primary development tool chain for MCU drivers and next-generation chip. “By standardizing on IAR Systems’ embedded software development tool chain, GainSpan will more easily support a wide range of MCUs to communicate with their modules,” IAR publicized a in a release.

It’s an important aspect of a larger plan, IAR’s ARM Strategic Accounts Manager Mike Skrtic said. IAR has overall tool chain standardization goals aimed at giving designers’ more flexibility when choosing MCUs for product development.

Remember: IAR Systems is teamed with Renesas for the RL78 Green Energy Challenge, which is administered by Circuit Cellar and Elektor. Designers are challenged to transform how the world experiences energy efficiency by developing a unique, low-power application using the RL78 MCU and IAR toolchain.

In other compiler-related news, Microchip Technology announced Monday at Design West its new MPLAB XC C compiler line, which supports its approximately 900 microcontrollers. Microchip’s Joe Drzewiecki said the compilers reduce code size by about 35% and improve code execution speed by about 30%. But you can judge for yourself because Microchip offers 8-, 16-, and 32-bit free editions of MPLAB XC compilers. According to Microchip reps, they are” fully functional and have no license restrictions for commercial use.”

So, if you give MPLAB XC a try, let us know what you think!