IAR Workbench Supports Next-Generation AVR MCUs

IAR Systems recently announced that its Embedded Workbench now supports a new generation of Microchip Technology 8-bit AVR microcontrollers. You can use Workbench with AVR microcontrollers to develop a wide range of low-power systems.

IAR Embedded Workbench’s features, benefits, and specs:

  • The compiler and debugger toolchain IAR Embedded Workbench incorporates the IAR C/C++ Compiler, which can create compact code for Microchip’s 8-bit AVR MCUs
  • IDE tools (editor, project manager, and library tools)
  • Build tools (compiler, assembler, and linker)
  • C-SPY debugger (simulator driver, hardware debugging, power debgging, and RTOS plugins
  • IAR Embedded Workbench offers full-scale support for AVR 32-bit MCUs as well as Microchip’s ARM®-based and 8051-based MCUs families.

Source: IAR Systems

Minimum Mass Waveform Capture

I can capture repetitive waveforms at 1 Msps using a microcontroller’s on-chip PWM and comparator. The impetus for developing this technique came from my own need to capture repetitive waveforms using the least expensive and lowest part count means possible. I wanted to be able to view the waveforms on an LCD dedicated to the purpose or upload the waveform to a computer for manipulation on a spread­sheet. This waveform capture method adheres to the “minimum mass” product design concept: it doesn’t use anything that is not absolutely essential to obtaining the needed function.

Implementations can be cheap enough to allow capture and analysis in many applications that otherwise could not justify the cost. Such applications include calculating the RMS values or harmonic content of waveforms for power management and equipment maintenance, self-testing audio frequency circuits, the analysis of pulse response for self-tuning servos, signal signature analysis, and remote diagnostics and data gathering.

The approaches using on-chip A/D converters on AVR and PIC controllers reach sample rates of up to nearly 60 kHz. Exotic and pricey high-speed controllers top out around 100 kHz. Such a sampling rate is not really high enough for the sort of applications I had in mind: encoded data, radio control signals, A/D converter waveforms, checking the dynamic range of amplifiers and capturing audio frequency waveforms for filtering, and power calculations. I realized that the comparators in AVR and PIC devices have fast response times (several hundred nanoseconds) and that the pulse width modulation (PWM) circuit could be made fairly responsive. I just needed some way to quickly combine them to sample analog values.

Eventually it became apparent that repetitive sampling was the only way to get high enough voltage and temporal sampling resolution using only these on-chip components. Rather than trying to sample and digitize the waveform in real time as it comes in, this method finds out a little bit about the waveform using the relatively high-speed comparator every time the waveform is repeated; it builds a more detailed picture with each repetition by changing the relatively low-speed PWM voltage each time.

Subscribe to Circuit Cellar magazine! Get 12 months of electrical engineering project articles, embedded design tutorials, embedded programming tips, and much more. We cover micrcontrollers, robotics, embedded Linux, IoT projects, and more!

THE METHOD

To capture a waveform, the PWM D/A converter (PWM DAC) is set to its maximum output voltage. Then, using timing loops to generate regularly spaced sampling times (1 µs in Figure 1), the microcontroller looks at the output of the voltage comparator to determine if the incoming voltage is higher than the PWM voltage. At each sampling time, if the PWM voltage is at a higher voltage than that of the incoming waveform, the PWM value is stored in a RAM array location corresponding to that sampling time.

Figure 1—It’s all in the timing. Firmware timing loops set the interval between samples in a burst of waveform samplings that starts with a trigger signal. The green dots represent voltage levels of the sampled signal at the time of sampling.

Figure 1—It’s all in the timing. Firmware timing loops set the interval between samples in a burst of waveform samplings that starts with a trigger signal. The green dots represent voltage levels of the sampled signal at the time of sampling.

After all of the sample times have been tested against the PWM voltage, the PWM voltage is decremented. The process is then repeated until the PWM voltage has been reduced to its mini­mum value (0 V). Each scan of the sample time starts by a trigger signal that’s derived from, or in some way related to, the incoming waveform. The finer the voltage resolution, the longer it takes to capture the wave­form because the waveform has to be sampled more times. Note that the settling time for the PWM DAC needs to be longer for finer voltage resolution.

The total capture time (TCAP) equals: the number of voltage levels × (trigger latency + sample time + step settling time). Trigger latency is the average amount of time the controller waits for a trigger signal. The initial PWM settling time and the step settling time are the times for the PWM filter to charge to its initial value and settle after a 1-LSB step change, respectively. Capturing 100 samples at 1 Msps in a circuit optimized for 6-bit resolution (64 levels) takes approximately 69 ms; however, it takes about 1.3 s to measure the same waveform on a circuit optimized for 8-bit resolution.

When capturing waveforms with long periods, the total time needed to capture the waveform is dominated by the time it takes the waveform to make the requisite number of repetitions. For shorter periods, the total time is dominated by the settling times for the PWM. Thus, the higher the sampling rate, the more you can speed up the capture cycle by using a faster DAC. A resistor network connected to some port pins could suffice for low-resolution (6-bit) waveform capture. An integrated circuit DAC would be better for higher resolution applications.

The quality of the trigger signal is essential to the fidelity of the captured waveform. The trigger signal must consistently appear at the same time with respect to the captured signal, otherwise severe distortion will result. This means that a noisy trigger signal, such as one derived directly from a noisy input signal, would give poor results. You’ll get the best results with a digital trigger signal taken directly from the source of the signal if such a trigger source is available.

Unsynchronized signals (e.g., noise) are not represented accurately; instead, such signals are underrepresented in the captured waveform. This quality, which results from synchronous sampling, is sometimes a good thing because it can effectively pull a signal out of the noise, which is an important property in applications such as ultra wideband and spread-spectrum signal decoding. But, if you intend to measure noise or jitter, this quality makes the system inappropriate.

Another aspect of sampled data sys­tems is their susceptibility to aliasing. Aliasing is a phenomenon in which a signal appears to occur at a frequency other than that at which it actually occurs. For instance, when a 250-kHz square wave is viewed with a 1-µs sampling interval, it shows up properly as four samples per cycle; however, when it is captured at a 100-µs sampling interval, it appears as 16 samples per cycle, or a 625-Hz signal, which is one four-hundredth the actual frequency.

To prevent aliasing, insert an analog filter in the signal path before the comparator’s input. In the example I’ve been focusing on, the Atmel AT90S2313 samples the signal at 1 Msps. The on-chip comparator has a propagation delay of 500 to 700 ns, providing inherent filtering for components of signals above approximately 800 kHz, and thus restricting the range of frequencies above the sam­pling rate that can be aliased down to frequencies below the sampling rate. To reduce the aliasing of signal components that have a lower frequency than the sampling rate, you’d need an additional external analog filter.

Figure 2— You can work with a bare minimum of parts, because it doesn’t take much to capture repetitive waveforms at 1 Msps and upload them to a terminal program on a PC for display and analysis. The passive components connected to pins 13 and 15 of the microcontroller are in the same basic configuration used for successive approximation A/D conversion; only the firmware is different.

Figure 2—You can work with a bare minimum of parts, because it doesn’t take much to capture repetitive waveforms at 1 Msps and upload them to a terminal program on a PC for display and analysis. The passive components connected to pins 13 and 15 of the microcontroller are in the same basic configuration used for successive approximation A/D conversion; only the firmware is different.

AN IMPLEMENTATION

The simple implementation shown in Figure 2 needs only a microcontroller with a DAC and voltage comparator, and some way to get control signals into the chip and the data back out. The demonstration system, for which firmware is posted on the Circuit Cellar ftp site, assumes an Atmel AT90S2313­10 is connected to level-shifting invert­ers for the EIA-232 interface such as a Maxim MAX232 with its 1-µf capaci­tors, a 10-MHz crystal with load capacitors, a decoupling capacitor, and the PWM low-pass filter connected to pins 13 and 15 of the microcontroller (see Photo 1).

Photo 1—The only components added to the operating Atmel AT90S2313 circuit needed to allow for waveform sampling with less than 1-μs resolution at 1-V full scale are the capacitor and two resistors. Imagine how small the circuit will be using surface-mount components.

Photo 1—The only components added to the operating Atmel AT90S2313 circuit needed to allow for waveform sampling with less than 1-μs resolution at 1-V full scale are the capacitor and two resistors. Imagine how small the circuit will be using surface-mount components.

It can be controlled by and dump data to an ASCII terminal program such as HyperTerminal at capture rates from 1 µs per sample to 10 ms per sample at 6-, 7-, and 8-bit resolution with selectable trigger polarity. An example of a waveform captured with this system and plot­ted in a spreadsheet program is shown in Figure 3.

Figure 3—This is the capture of a 31.25-kHz sawtooth waveform. The sample rate is set to 1 μs per sample and the voltage resolution is 8 bits.

Figure 3—This is the capture of a 31.25-kHz sawtooth waveform. The sample rate is set to 1 μs per sample and the voltage resolution is 8 bits.

PWM LOW-PASS FILTER

The DAC uses pulse-width modula­tion, so it is necessary to have an averaging (low-pass) filter to recover the DC component while filtering out most of the PWM signal’s AC component. The AC component remaining on the filter’s output is referred to as ripple.

The filter is made up of 330- and 82-kΩ resistors and a 0.047-µF capaci­tor, which forms a single-pole RC fil­ter. The two resistors form a voltage divider to reduce the full-scale voltage from the DAC to 1-V full scale. If you are worried about accuracy, you can replace the 82-kΩ resistor with a fixed resistor and a variable resistor in series to allow for full-scale calibration.

If 5-V full scale is appropriate for your application, you can omit the lower resistor and save a part. The low-pass filter for the PWM output needs to be made with a large enough time constant to keep the ripple to an acceptable level. After the filter time constant is pinned down, the controller must wait long enough after each step change in output voltage for the filter to settle adequately before starting measurements.

The PWM filter can be analyzed as a single resistor driving the capacitor (see Figure 4). Judging from the AT90S2313 datasheet, when operating at 5 V, the output resistance of the PWM output is approximately 28 Ω; it is safe to say that it is negligible com­pared to the 330-kΩ resistor that’s in series with it. Thus, the filter model is plenty close by taking the value of the resistance to be the parallel combina­tion of the two resistors (see Figure 4).

Figure 4—The PWM filter is easily analyzed as a single resistor charging the capacitor by replacing the resistors with a single resistor equal to the parallel combination of the two, because that is what it looks like to the capacitor.

Figure 4—The PWM filter is easily analyzed as a single resistor charging the capacitor by replacing the resistors with a single resistor equal to the parallel combination of the two, because that is what it looks like to the capacitor.

The first step is to select the time constant that gives an acceptably low ripple. For my application, I considered speed to be more important than absolute accuracy, so I decided to keep the ripple at 1 LSB. The time constant should be figured for the worst possible PWM signal. The worst case for ripple is when the lowest frequency appears at the filter’s input. In the case of the AT90S2313, this occurs when the PWM output runs 50% duty cycle. Under this condition, the pulse frequency is about 19.6 kHz and the voltage across the capacitor is 0.5 V. When the pulse is high (this analysis is the same for the time the pulse is low, only the signs change), the difference between the PWM peak voltage (1 V) and the voltage across the capacitor is across the equivalent resistance, and the current through the resistance charges the capacitor.

Note that 1 LSB of an 8-bit value based on 1-V full scale is 4 mV (1/255). Using the formula in Figure 5, the time constant must be approximately 3.2 ms. I chose the resistors by first selecting the largest capacitor and a pair of large resistors that had the necessary 4:1 resistance ratio while simultaneously giving nearly the correct time constant. The resulting combination gives a divide ratio of 1:5.02 and a time con­stant of 3.15 ms (67 kΩ × 0.047 µF).

Figure 5—A simplified model can be used to predict the relationship between the filter’s time constant and the amount of ripple. The charging current for the capacitor comes from the voltage drop between the 1 V from the output of the resistive divider and the voltage across the capacitor. Note that EO is the voltage change across the capacitor (1 LSB = 4 mV), and EI is the average voltage across the resistance (0.5 V). T is the time that voltage is applied across the circuit (25.5 μs), and t is the time constant of the circuit.

Figure 5—A simplified model can be used to predict the relationship between the filter’s time constant and the amount of ripple. The charging current for the capacitor comes from the voltage drop between the 1 V from the output of the resistive divider and the voltage across the capacitor. Note that EO is the voltage change across the capacitor (1 LSB = 4 mV), and EI is the average voltage across the resistance (0.5 V). T is the time that voltage is applied across the circuit (25.5 μs), and t is the time constant of the circuit.

After the filter time constant is known, the settling times can be determined. I decided to have the con­troller wait for the initial settling of the filter to within 1 LSB of full scale before starting the waveform capture cycle using the formula in Figure 6. For the settling time between succes­sive steps, I wanted to wait until after the voltage changed more than 0.5 LSB. Because the step size is 1 LSB, I chose one time constant, or 3 ms.

Figure 6—The initial settling time must be long enough to assure that the PWM output settles to within 1 LSB of the final voltage. It must be calculated for the worst case scenario, which is when it starts from 0 V. Note that ΔV is the error in the settled voltage (1 LSB = 4 mV). EI is the voltage applied to the circuit, which is 1 V. In is the natural logarithm (base 2.71828…). T is the time that voltage is applied across the circuit, and t is the time constant of the circuit (3.17 ms).

Figure 6—The initial settling time must be long enough to assure that the PWM output settles to within 1 LSB of the final voltage. It must be calculated for the worst case scenario, which is when it starts from 0 V. Note that ΔV is the error in the settled voltage (1 LSB = 4 mV). EI is the voltage applied to the circuit, which is 1 V. In is the natural logarithm (base 2.71828…). T is the time that voltage is applied across the circuit, and t is the time constant of the circuit (3.17 ms).

FIRMWARE

When capturing a waveform, the PWM circuit first generates the maxi­mum output voltage and samples all time intervals starting from a trigger signal, taking care to keep the time between samples constant. Whenever the voltage at a sampled time exceeds the PWM voltage, the PWM value is stored in the RAM array location corresponding to that sample. In this way, at the end of the capture cycle, the peak value at each sampling time is stored in the RAM array.

The sampling loop in Listing 1 is the time-critical part of the code. It requires 10 clock cycles per sample. With a 10­-MHz clock, the sampling rate is 1 MHz. Two clock cycles are taken up by the indirect jump instruction (ijmp), which jumps either to the next instruction in sequence (at the label oneus:) or to a delay routine that returns to the next instruction in sequence. Eliminating the indirect jump instruction would decrease the sampling interval to eight cycles. Straight line coding would be inflexible and take a lot of program memory, but it could reduce the sam­pling interval to as few as three cycles when storing the waveform in RAM.

Listing 1—The sampling of the waveform takes place at the sbic ACSR,5 instruction, where the output of the comparator is tested. If the comparator’s output is low, execution proceeds to st Y+,pwmval, the instruction that stores the data into the RAM array via the Y pointer. If the comparator’s input is high, the program branches back to nextydelay, which imcrements the Y pointer without storing data.

Listing 1—The sampling of the waveform takes place at the sbic ACSR,5 instruction, where the output of the comparator is tested. If the comparator’s output is low, execution proceeds to st Y+,pwmval, the instruction that stores the data into the RAM array via the Y pointer. If the comparator’s input is high, the program branches back to nextydelay, which imcrements the Y pointer without storing data.

At the beginning of a waveform collection cycle, the program sits in a wait loop and waits for a transition on the trigger input. After the triggering edge is detected, the sampling routine is called and it runs through and collects a full set of samples. Then, the PWM value is decremented, a wait loop is executed to allow the RC filter in the PWM DAC to settle, and the program returns to wait for the next triggering event. This process continues until the lowest pos­sible PWM value has been tested.

Timing uncertainty is introduced by the short loop in which the controller waits for the triggering edge. The uncertainty translates into jitter in the signal sampling. As long as the uncer­tainty is small compared to the signal-sampling interval, it should not contribute much in the way of noise to the captured waveform. In applications that use only a few machine cycles between samples, it pays to keep the wait loops as short as possible.

BELOW GROUND SIGNALS

Judging from the offset-versus-input voltage curve on the AT90S2313’s datasheet, the comparator’s differen­tial gain is good enough for 6-bit waveform capture just above ground. For linearity errors of less than 1 LSB with 8-bit operation, the comparator inputs need to run closer to the mid­dle of the power supply where the curve is nearly flat.

There is a bonus to adding offset to the input signal in that it can measure input signals at and below ground without clipping. When the input signal is level-shifted, the PWM DAC’s output must be similarly offset. The PWM offset circuit provides an oppor­tunity for an adjustable vertical-cen­tering control (to use the oscilloscope term). Circuits that shift the input level and allow offset adjustment are shown in Figure 7.

Figure 7—The FET provides an offset allowing the input to swing above and below ground as well as moving the input to the AT90S2313’s on-chip comparator away from ground and enabling an offset adjustment. You can also achieve these functions with op-amps, but there are several trade-offs to consider.

Figure 7—The FET provides an offset allowing the input to swing above and below ground as well as moving the input to the AT90S2313’s on-chip comparator away from ground and enabling an offset adjustment. You can also achieve these functions with op-amps, but there are several trade-offs to consider.

Level shifting is achieved easily enough with an op-amp if you have a negative power supply, but my objec­tive was to make the entire system operate from a single 5-V regulator. Besides, my cheap single-supply op-amps, which also had adequate dynam­ic range, had too poor a slew rate to give satisfactory performance at 1 Msps.
A junction field effect transistor (JFET) source follower is an ideal way to offset the input signal to a more positive voltage without much attenu­ation or loss of bandwidth. I used an MPF102 in my own circuit because I had some on hand. Numerous other small signal JFETs would work well.

Pinch-off voltage is the FET parameter that most affects the offset because, for most FETs, this parameter varies widely. To obtain the approximate 2.5-V offset (the DC voltage on the FET source when the gate is grounded), you can hand select an FET, adjust the source resistor (15 kΩ in the circuit above), or try a combination of the two. The higher the value of the resistor, the higher the off­set voltage (i.e., up to nearly the pinch-off voltage of the FET, which is usually specified at a low current). Be aware that the source resistor affects the trade-off between the bandwidth and signal loss. As the resistor gets larger, the bandwidth will decrease; as the resistor gets smaller, the gain of the source follower drops. For my particular circuit layout and its parasitic capacitance, 15 kΩ was about the upper limit for 1 Msps.

One way to add an adjustable DC offset to the output of the PWM circuit without affecting the RC filter’s response time is to use an adjustable constant current source. The current source shown in Figure 7 relies on the fact that the 2N2907’s collector current is nearly equal to the emitter current. (The collector cur­rent equals the emitter current times Alpha, which is nearly unity and pretty stable.) Emitter current is determined by the voltage across the 8.2-kΩ emitter resistor, which follows the base voltage and is temperature-compensated by the diode in series with the potentiometer.

SIMPLE, ECONOMICAL, FLEXIBLE

Among the variations that may be useful are programmable offset and gain controls, and a calibration func­tion using only a few resistors and additional I/O pins. In multiple-chip systems, the time-dependent sampling task can be offloaded to a low-cost slave processor with little or no RAM that sends intermediate results to a host. The slave could be one of the cheapest eight-pin microcontrollers offered that has a suitable on-chip voltage comparator. The minimum mass waveform capture approach is a building block that produces a much faster sampling rate and costs less than conventional approaches using on-chip A/D converters.

I suspect that by now you have come up with some ideas of your own. It’s easy enough to put the sam­ple system together, so why not give it a try?

ABOUT THE AUTHOR

Dick Cappels enjoys tinkering with and writing about analog circuits and microcontrollers. He has published several papers relating to electronic displays in computer systems, and is currently active in the Society for Information Display. Dick holds 17 U.S. patents.

This article first appeared in Circuit Cellar 159.

Rad-Tolerant megaAVR MCU for Space Applications

Atmel Corp. is now shipping the ATmegaS128 microcontroller targeting next-generation space applications. Atmel’s first Rad-Tolerant device, ATmegaS128 delivers full wafer lot traceability, a 64-lead  CQFP, space screening, space qualification according to QML and ESCC flow, and total ionizing dose up to 30 Krad (Si) for space applications.

The ATmegaS128 is available in a ceramic hermetic packaging and is pin-to-pin and drop-in compatible with existing ATmega128 MCUs. This provides flexibility between commercial and qualified devices and thus enables faster time-to-market and lower development costs.

Features and specs:

  • High-performance, low-power Atmel AVR 8-bit MCU
  • High endurance, non-volatile memory
  • Robust peripherals including 8- and 16-bit timers/counters, 6 PWM channels, 8-channel, 10-bit ADC, TWI/USARTs/SPI serial interface, programmable watchdog timer, on-chip analog compactor
  • Power-on reset and programmable brown-out detection
  • Internal calibrated RC oscillator
  • External and internal interrupt sources
  • Six sleep modes
  • Power-down, standby and extended standby

A complete STK600 starter kit and development system for the ATmegaS128 AVR MCU is available. You can design with an industrial version of the ATmega128—with the exact pin-out of the ATmegaS128—to save costs. The new AVRs are supported by the proven Atmel Studio IDP for developing and debugging Atmel SMART ARM processor-based MCUs and Atmel AVR MCU applications, along with the Atmel Software Framework.

Source: Atmel

Dialog to Buy at Atmel for $4.6 Billion

Dialog Semiconductor and Atmel Corp. recently announced Dialog will acquire Atmel in a cash and stock transaction for approximately $4.6 billion. According to reports, the deal will likely close in the first quarter of 2016.

The transaction—which has been unanimously approved by the boards of directors of both companies and is subject to regulatory approvals in various jurisdictions, as well as the approval of Dialog and Atmel shareholders—will likely close in Q1 2016. Jalal Bagherli will continue as Chief Executive Officer and Executive Board Director of Dialog.

Two-Pin, Self-Powered Serial EEPROM for the IoT

Atmel recently announced a two-pin, single-wire EEPROM intended for the Internet of Things (IoT), wearables, and more. The self-powered devices don’t require a power source or VCC pin, with a parasitic power scheme over the data pin. They provide ultra-low power standby of 700 nA, 200 µA for write current, and 80 µA for read current at 25°C.

The AT21CS01/11 devices eliminate the need for external capacitors and rectifiers with its parasitic power scheme over a single data pin. Plus, their ultra-high write endurance capability to allow more than 1 million cycles for each memory location to meet the requirements for today’s high-write endurance applications.

The AT21CS01/11 products include a simple product identification with a plug-and-play, 64-bit unique serial number in every device. Furthermore, they deliver industry-leading electrostatic discharge (ESD) rating (IEC 61000-4-2 Level 4 ESD Compliant), so a variety of applications (e.g., cables and consumables) can tolerate exposure to the outside environment or direct human contact while still delivering high performance.

The new devices follow the I2C protocol, which enables easy migration from existing EEPROM with less overhead and the capability to connect up to eight devices on the same bus. The AT21CS01 devices offer a security register with a 64-bit factory programmed serial number and an extra 16 bytes of user-programmable and permanently lockable storag.

The AT21CS01 is intended for low-voltage applications operating at 1.7 to 3.6 V. For applications that require higher voltage ranges (e.g., Li-Ion/polymer batteries), the AT21CS11 supports a 2.7 to 4.5 V operating range.

The AT21CS01 devices are available in production quantities in three-lead SOT23, eight-lead SOIC, and four-ball WLCSP. Pricing starts at $0.32 in 5,000-piece quantities. The AT21CS11 will be available in Q4 2015.

Source: Atmel

Ultra-Low Power Wi-Fi Platform for IoT Applications

Atmel and MXCHIP recently announced that they’re jointly developing an ultra-low power Internet of Things (IoT) platform with secure Wi-Fi access to the cloud, enabling designers to quickly bring IoT devices to market. The platform combines Atmel’s ultra-low power SMART SAM G ARM Cortex-M4-based MCUs and its SmartConnect WILC1000 Wi-Fi solution with MXCHIP’s MiCO IoT operating system (OS), servicing a full range of smart device developers for IoT applications. The integrated platform is intended to give IoT designers the confidence that their battery-operated devices will have longer battery life and their data will be securely transferred to the cloud.

Atmel’s WILC1000 is an IEEE 802.11b/g/n IoT link controller leveraging its ultra-low power Wi-Fi transceiver with a fully integrated power amplifier. This solution delivers the industry’s best communication range of up to +20.5-dBm output, ideal for connected home devices. Integrated in packages as small as a 3.2 mm × 3.2 mm WLCSP, the Atmel WILC1000 link controller leverages in this platform Atmel’s SAM G MCU, an ideal solution for low-power IoT applications and optimized for lower power consumption, incorporating large SRAM, high performance and operating efficiency with floating-point unit in an industry-leading 2.84 mm × 2.84 mm package. When combined with secure Wi-Fi technology, the joint IoT platform connects directly to each other or to a local area network (LAN), enabling remote system monitoring or control. For increased security, the platform comes with an optional Atmel ATECC508A, which is the industry’s first crypto device to integrate ECDH key agreement, making it easy to add confidentiality to digital systems including IoT nodes used in home automation, industrial networking, accessory and consumable authentication, medical, mobile and other applications.

 

To accelerate the IoT design process, the platform includes the MiCOKit-G55 development kit, technical documentation, application notes and a software development kit.

Source: Atmel

Quad Bench Power Supply

The need for a bevy of equipment for building and testing presents a problem: how to deliver an adequate power supply while keeping workbench clutter to a minimum. Brian decided to tackle this classic engineering conundrum with a small, low-capacity quad bench power supply.

To the right of the output Johnson posts are the switches that set the polarity of the floating supplies—as well as the switch that disconnects all power supply outputs—while leaving the unit still powered up.

To the right of the output Johnson posts are the switches that set the polarity of the floating supplies—as well as the switch that disconnects all power supply outputs—while leaving the unit still powered up.

In “Quad Bench Power Supply,” Millier writes:

I hate to admit it, but my electronics bench is not a pretty sight, at least in the midst of a project anyway. Of course, I’m always in the middle of some project that, more often than not, contains two or three different projects in various stages of completion. To make matters worse, most of my projects involve microchips, which have to be programmed. Because I use ISP flash memory MCUs exclusively, it makes sense to locate a computer on my construction bench to facilitate programming and testing. To save space, I initially used my laptop’s parallel port for MCU programming. It was only a matter of time before I popped the laptop’s printer port by connecting it to a prototype circuit with errors on it.

Fixing my laptop’s printer port would have involved replacing its main board, which is an expensive proposition. Therefore, I switched over to a desktop computer (with a $20 ISA printer port board) for programming and testing purposes. The desktop, however, took up much more room on my bench.

You can’t do without lots of testing equipment, all of which takes up more bench space. Amongst my test equipment, I have several bench power supplies, which are unfortunately large because I built them with surplus power supply assemblies taken from older, unused equipment. This seemed like a good candidate for miniaturization.

At about the same time, I read a fine article by Robert Lacoste describing a high-power tracking lab power supply (“A Tracking Lab Power Supply,” Circuit Cellar 139). Although I liked many of Robert’s clever design ideas, most of my recent projects seemed to need only modest amounts of power. Therefore, I decided to design my own low-capacity bench supply that would be compact enough to fit in a small case. In this article, I’ll describe that power supply.

MY WISH LIST

Even though I mentioned that my recent project’s power demands were fairly modest, I frequently needed three or more discrete voltage levels. This meant lugging out a couple of different bench supplies and wiring all of them to the circuit I was building. If the circuit required all of the power supplies to cycle on and off simultaneously, the above arrangement was extremely inconvenient. In any event, it took up too much space on my bench.

I decided that I wanted to have four discrete voltage sources available. One power supply would be ground referenced. Two additional power supplies would be floating power supplies. Each of these would have the provision to switch either the positive or negative terminal to the negative (ground) terminal of the ground-referenced supply, allowing for positive or negative output voltage. Alternately, these supplies could be left floating with respect to ground by leaving the aforementioned switch in the center position.

This arrangement allows for one positive and two positive, negative or floating voltage outputs. To round off the complement, I added Condor’s commercial 5-V, 3-A linear power supply module, which I had on hand in my junk box. Table 1 shows the capabilities of the four power supplies.

I wanted to provide the metering of voltage and current for the three variable power supplies. The simultaneous voltage and current measurement of three completely independent power supplies seemed to indicate the need for six digital panel meters. Indeed, this is the path that Robert Lacoste used in his tracking lab supply.

As you can see, there are four power supplies. I’ve included all of the information you need to understand their capabilities.

As you can see, there are four power supplies. I’ve included all of the information you need to understand their capabilities.

I had used many of these DPM modules before, so I was aware of the fact that the modules require their negative measurement terminal to float with respect to the DPM’s own power supply. I solved this problem in the past by providing the DPM module with its own independent power source. Robert solved it by designing a differential drive circuit for the DPM. Either solution, when multiplied by six, is not trivial. Add to this the fact that high-quality DPMs cost about $40 in Canada, and you’ll see why I started to consider a different solution.

I decided to incorporate an MCU into the design to replace the six DPMs as well as six 10-turn potentiometers, which are also becoming expensive. In place of $240 worth of DPMs, I used three inexpensive dual 12-bit ADCs, an MCU, and an inexpensive LCD panel. The $100 worth of 10-turn potentiometers was replaced with three dual digital potentiometers and two inexpensive rotary encoders.

Using a microcontroller-based circuit basically allows you to control the bench supply with a computer for free. I have to admit that I decided to add the commercial 5-V supply module at the last minute; therefore, I didn’t allow for the voltage or current monitoring of this particular supply.

THE ANALOG CORE

Although there certainly is a digital component to this project, the basic power supply core is a standard analog series-pass regulator design. I borrowed a bit of this design from Robert’s lab supply circuit.

Basically, all three power supplies share the same design. The ground-referenced power supply provides less voltage and more current than the floating supplies. Thus, it uses a different transformer than the two floating supplies. The ground-referenced supply’s digital circuitry (for control of the digital potentiometer and ADC) can be connected directly to the MCU port lines. The two floating supplies, in addition to the different power transformer, also need isolation circuitry to connect to the MCU.

Figure 1 is the schematic for the ground-referenced supply. As you can see, a 24VCT PCB-mounted transformer provides all four necessary voltage sources. A full wave rectifier comprised of D4, D5, and C5 provides the 16 V that’s regulated down to the actual power supply output. Diodes D6, R10, C8, and Zener diode D7 provide the negative power supply needed by the op-amps. …

The ground-referenced power supply includes an independent 5-V supply to run the microcontroller module.

The ground-referenced power supply includes an independent 5-V supply to run the microcontroller module.

MCU AND USER INTERFACE

As with every other project I’ve worked on in the last two years, I chose the Atmel AVR family for the MCU. In this case, I went with the AT90S8535 for a couple of reasons. I needed 23 I/O lines to handle the three SPI channels, LCD, rotary encoders, and RS-232. This ruled out the use of smaller AVR devices. I could’ve used the slightly less expensive AT90LS8515, but I wanted to allow for the possibility of adding a temperature-sensing meter/alarm option to the circuit. The ’8535 has a 10-bit ADC function that’s suitable for this purpose; the ’8515 does not.

The ’8535 MCU has 8 KB of ISP flash memory, which is just about right for the necessary firmware. It also contains 512 bytes of EEPROM. I used a small amount of the EEPROM to store default values for the three programmable power supplies. That is to say, the power supply will power up with the same settings that existed at the time its Save Configuration push button was last pressed.

To simplify construction, I decided to use a SIMM100 SimmStick module made by Lawicel. The SIMM100 is a 3.5″ × 2.0″ PCB containing the ’8535, power supply regulator, reset function, RS-232 interface, ADC, ISP programming headers, and a 30-pin SimmStick-style bus. I’ve used this module for prototypes several times in the past, but this is the first time I’ve actually incorporated one into a finished project. …

eded to operate the three SPI channels and interface the two rotary encoders come out through the 30-pin bus. As you now know, I designed the ground-referenced power supply PCB to include space to mount the SIMM100 module, as well as the IsoLoop isolators. The SIMM100 mounts at right angles to this PCB; it’s hard-wired in place using 90° header pins. The floating power supplies share a virtually identical PCB layout apart from being smaller because of the lack of traces and circuitry associated with the SIMM100 bus and IsoLoop isolators.

The SIMM100 module has headers for the ISP programming cable and RS-232 port. I used its ADC header to run the LCD by reassigning six of the ADC port pins to general I/O pins.

When I buy in bulk, it’s inevitable that by the time I use the last item in my stock, something better has taken its place. After contacting Lawicel to request a .jpg image of the SIMM100 for this article, I was introduced to the new line of AVR modules that the company is developing.

Rather than a SimmStick-based module, the new modules are 24- and 40-pin DIP modules that are meant to replace Basic Stamps. Instead of using PIC chips/serial EEPROM and a Basic Interpreter, they implement the most powerful members of Atmel’s AVR family—the Mega chips.

Mega chips execute compiled code from fast internal flash memory and contain much more RAM and EEPROM than Stamps. Even though flash programming AVR-family chips is easy through SPI, using inexpensive printer port programming cables, these modules go one step further by incorporating RS-232 flash memory programming. This makes field updates a snap. …

The user interface I settled on consisted of a common 4 × 20 LCD panel along with two rotary encoders. One encoder is used to scroll through the various power supply parameters, and the other adjusts the selected parameter. The cost of LCDs and rotary encoders is reasonable these days. Being able to eliminate the substantial cost of six DPMs and six 10-turn potentiometers was the main reason for choosing an MCU-based design in the first place.

Brian Millier’s article first appeared in Circuit Cellar 149.

ARM MCUs wtith Capacitive Touch Hardware Support for HMI and LIN Applications

Atmel recently announced its next-generation family of automotive-qualified ARM Cortext-M0+-based micrcontrollers with an integrated peripheral touch controller (PTC) for capacitive touch applications. The new SAM DA1 is the first series in this Atmel |SMART MCU automotive-qualified product family, operating at a maximum frequency of 48 MHz and reaching a 2.14 Coremark/MHz.Atmel Corporation SAM DA1

Atmel’s SAM DA1 series is ideal for capacitive touch button, slider, wheel or proximity sensing applications and offers high analog performance for greater front-end flexibility. The new devices are available down to a very compact QFN 5 × 5 mm package with wettable flanks for automated optical inspection.

Eliminating external components and offering more robust features, devices in the SAM DA1 series come with 32 to 64 pins, up to 64 KB of flash memory, 8 KB of SRAM, and 2-KB read-while-write flash memory and are qualified according to the AEC Q-100 Grade 2 (–40° to 105°C).

Key Features of Atmel’s SAM DA1 Series

  • Atmel |SMART ARM Cortex-M0+-based processor
  • 45 DMIPS
  • Vcc 2.7 to 3.63 V
  • 16- to 64-KB Flash; 32 to 64 pins
  • Up to six SERCOM (Serial Communication Interface), USB, I2S
  • Peripheral Touch Controller
  • Complex PWM
  • AEC Q100 Grade 2 Qualified

To accelerate the design development, the ATSAMDA1-XPRO development kit is available to support the new devices. The new SAM DA1 series is also supported by Atmel Studio, Atmel Software Framework and debuggers.

Contact Atmel to sample the SAM DA1 series.

Source: Atmel

Utilize Simple Radios with Simple Computers

I ordered some little UHF transmitters and receivers from suppliers on AliExpress, the Chinese equivalent of Amazon.com, in order to extend my door chimes into areas of my home where I could not hear them. These ridiculously inexpensive units are currently about $1 per transmitter-receiver pair in quantities of five, including shipping, and are available at 315 and 433.92 MHz. Photo 1 shows a transmitter and receiver pair.  Connections are power and ground and data in or out.

Photo 1: 315 MHz Transmitter-Receiver Pair (Receiver on Left)

Photo 1: The 315-MHz transmitter-receiver pair (receiver on left)

The original attempt at a door chime extender modulated the transmit RF with an audio tone and searched for the presence of that tone at the receiver with a narrow audio filter, envelope detector, and threshold detector. This sort of worked, but I started incorporating the same transmitters into another project that interfered, despite the audio filter.

The other project used Arduino Uno R3 computers and Virtual Wire to convey data reliably between transmitters and receivers. Do not expect a simple connection to a serial port to work well. As the other project evolved, I learned enough about the Atmel ATtiny85 processor, a smaller alternative to the Atmel ATmega328 processor in the Arduino Uno R3, to make new and better and very much simpler circuits. That project evolved to come full circle and now serves as a better doorbell extender. The transmitters self identify, so a second transmit unit now also notifies me when the postman opens the mailbox.

Note the requirement for Virtual Wire.  Do not expect a simple connection to a serial port to work very well.

Transmitter

Figure 1 shows the basic transmitter circuit, and Photo 2 shows the prototype transmitter. There is only the ATtiny85 CPU and a transmitter board. The ATtiny85 only has eight pins with two dedicated to power and one to the Reset input.

Figure 1: Simple Transmitter Schematic

Figure 1: Simple transmitter schematic

One digital output powers the transmitter and a second digital output provides data to the transmitter.  The remaining three pins are available to serve as inputs.  One serves to configure and control the unit as a mailbox alarm, and the other two set the identification message the transmitter sends to enable the receiver to discriminate among a group of such transmitters.

Photo 2: 315 MHz Transmitter and ATtiny85 CPU

Photo 2: The 315-MHz transmitter and ATtiny85 CPU

When input pin 3 is high at power-up, the unit enters mailbox alarm mode. In mailbox alarm mode, the input pins 2 and 7 serve as binary identification bits to define the value of the single numeric character that the transmitter sends, and the input pin 3 serves as the interrupt input. Whenever input pin 3 transitions from high-to-low or low-to-high, the ATtiny85 CPU wakes from SLEEP_MODE_PWR_DOWN, makes a single transmission, and goes back to sleep. The current mailbox sensor is a tilt switch mounted to the door of the mailbox. The next one will likely be a reed relay, so only a magnet will need to move.

When in SLEEP_MODE_PWR_DOWN, the whole circuit draws under 0.5 µA. I expect long life from the three AAA batteries if they can withstand heat, cold, and moisture. I can program the ATtiny to pull the identification inputs high, but each binary identification pin then draws about 100 µA when pulled low. In contrast, the 20- or 22-MΩ pull-up resistors I use as pull-ups each draw only a small fraction of a microampere when pulled low.

When input pin 3 is low at power-up, the unit enters doorbell extender alarm mode. In doorbell extender alarm mode, the input pins 2 and 7 again serve as binary identification bits to define the value of the single numeric character that the transmitter sends; but in doorbell extender mode, the unit repetitively transmits the identification character whenever power from the door chimes remains applied.

Receiver

Figure 2 shows the basic receiver circuit, and Photo 3 shows the prototype receiver. There is only the ATtiny85 CPU with a 78L05 voltage regulator and a receiver board.

Figure 2: Simple Receiver Schematic

Figure 2: Simple receiver schematic

The receiver output feeds the input at pin 5. The Virtual Wire software decodes and presents the received character. Software in the CPU sends tone pulses to a loudspeaker that convey the value of the identification code received, so I can tell the difference between the door chime and the mailbox signals. Current software changes both the number of beep tones and their audible frequency to indicate the identity of the transmit source.

Photo 3: The 315-MHz receiver with ATtiny85 CPU and 78L05 voltage regulator

Photo 3: The 315-MHz receiver with ATtiny85 CPU and 78L05 voltage regulator

Note that these receivers are annoyingly sensitive to power supply ripple, so receiver power must either come from a filtered and regulated supply or from batteries.

Photo 4 shows the complete receiver with the loudspeaker.

Photo 4: Receiver with antenna connections and loudspeaker

Photo 4: Receiver with antenna connections and a loudspeaker

Link Margin

A few inches of wire for an antenna will reach anywhere in my small basement. To improve transmission distance from the mailbox at the street to the receiver in my basement, I added a simple half-wave dipole antenna to both transmitter and receiver. Construction is with insulated magnet wire so I can twist the balanced transmission line portion as in Photo 5. I bring the transmission line out through an existing hole in my metal mailbox and staple the vertical dipole to the wooden mail post. My next mailbox will not be metal.

Photo 5: Simple half-wave dipole for both Tx and Rx increases link distance

Photo 5: Simple half-wave dipole for both Tx and Rx increases link distance

I don’t have long term bad weather data to show this will continue to work through heavy ice and snow, but my mailman sees me respond promptly so far.

Operating Mode Differences

The mailbox unit must operate at minimum battery drain, and it does this very well. The doorbell extender operates continuously when the AC door chime applies power. In order to complete a full message no matter how short a time someone presses the doorbell push button, I rectify the AC and store charge in a relatively large electrolytic capacitor to enable sufficient transmission time.

Photo 6: New PCBs for receive and transmit

Photo 6: New PCBs for receive and transmit

Availability

This unit is fairly simple to fabricate and program your self, but if there is demand, my friend Lee Johnson will make and sell boards with pre-programmed ATtiny85 CPUs. (Lee Johnson, NØVI, will have information on his website if we develop this project into a product: www.citrus-electronics.com.) We will socket the CPU so you can replace it to change the program. The new transmitter and receiver printed circuit boards appear in Photo 6.


Dr. Sam Green (WØPCE) is a retired aerospace engineer living in Saint Louis, MO. He holds degrees in Electronic Engineering from Northwestern University and the University of Illinois at Urbana. Sam specialized in free space and fiber optical data communications and photonics. He became KN9KEQ and K9KEQ in 1957, while a high school freshman in Skokie, IL, where he was a Skokie Six Meter Indian. Sam held a Technician class license for 36 years before finally upgrading to Amateur Extra Class in 1993. He is a member of ARRL, a member of the Boeing Employees Amateur Radio Society (BEARS), a member of the Saint Louis QRP Society (SLQS), and breakfasts with the Saint Louis Area Microwave Society (SLAMS). Sam is a Registered Professional Engineer in Missouri and a life senior member of IEEE. Sam is listed as inventor on 18 patents.

Microcontroller-Based Wireless Pedometer & Pace Tacker Project

Anyone can easily order a pedometer or GPS sports watch on the Internet. But engineers like challenges, right? With the right parts and a little knowhow, you can engineer your own microcontroller-based wireless Bluetooth pedometer and pace tracker.

In the article, “Run With It” (Circuit Cellar 203, December 2014), Ellen Chuang and Julie Wang explain how they built an Atmel ATmega1284P microcontroller-based wireless pedometer and pace tracker. They wrote:

There’s a simple question most runners, walkers, and joggers ask themselves: How fast am I going? There are various tools for measuring pace, including step counters, GPS units, and smartphone applications. Pedometers are common tools for tracking physical activity. However, pedometers are typically either self-contained units that are out of sight and out of mind or expensive products like the FitBit and Nike+. So, for our culminating design project for Cornell University’s ECE 4760 Microcontrollers course, we decided to create a low-budget wireless pedometer and pace tracker.

The wireless pedometer hardware implementation includes a (a) foot module and a (b) wrist module on the right.

The wireless pedometer includes a foot module (a) and a wrist module (b).

Chuang and Wang’s design is notable because they enabled it with Bluetooth so they could connect it with other Bluetooth devices. In addition, they separated the user interface from the measurement unit.

Our system contains two separate modules: a foot-mounted module that captures acceleration data and a wrist-mounted module with a user interface. The foot module captures your acceleration data, lightly processes it to find values of interest, and sends the data over Bluetooth to the wrist module. The wrist module then further processes the information to determine if a step has occurred. The wrist module also handles user input and displaying information on an LCD.

To use the device, the foot unit is strapped on your lower leg and the wrist unit is either strapped to your wrist or held in your hand. At power-up, the units automatically pair over a Bluetooth link. The wrist unit powers up in Configuration mode, which enables you to use the two push buttons to adjust your stride length and also your desired pace in minutes per mile. You are first prompted for your stride length—the average length of one step—and then the targeted speed in minutes per mile. The Enter button enables you to confirm the parameters, exit Configuration mode, and enter into Pace Display mode. In Pace Display mode, the LCD displays the cumulative number of steps, your calculated pace, and your desired pace. At any point, you can reenter Configuration mode by toggling a switch on the wrist module.

Both modules contain an Atmel ATmega1284P microcontroller and an HC-05 Bluetooth master/slave module.

The foot unit contains a 1.5-g, single-axis Freescale Semiconductor MMA2260D accelerometer orientated with its positive measurement axis pointed away from the center of the Earth. We’ll refer to this direction as the z-axis. The analog data coming from the accelerometer is very noisy. To filter out the excessive noise, the accelerometer data passes through a low-pass filter with a cutoff frequency around 33 Hz using a 10-kΩ resistor and 470-nF capacitor. Human stride frequency typically falls between 185 and 200 strides per minute, or around 3.33 Hz. In order to capture this frequency, as well as higher frequency signals that correspond to other foot movements, we set the low-pass filter’s cutoff frequency to 33 Hertz. Additionally, to fully utilize the internal ADC’s 10-bit range, we dropped the voltage across a 20-kΩ resistor…

This is the foot unit. We used MAX233/RS-232 for debugging purposes and not for the final foot module.

This is the foot unit. We used MAX233/RS-232 for debugging purposes and not for the final foot module.

The wrist unit includes a 16 × 2 LCD a number of user input buttons/switches, status-linked LEDs, and a Bluetooth transceiver (see Figure 2). The three buttons and switch are used in Configuration mode. Additionally, we included the following LEDs: a red LED on the board that toggles every time a step is detected; a yellow LED that toggles every time a packet is received via Bluetooth; and a green “keep alive” LED. The software on the microcontroller manages all of these tasks, which we cover in the next section.

The complete article appears in Circuit Cellar 293 (December 2014).

Read Your Technical Documentation (EE Tip #145)

Last 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.—Bob Japenga, CC25, 2013

Got Problematic Little Bits? (EE Tip #142)

While testing a project, something strange happened (see the nearby image). The terminal showed nonsense, but the logic analyzer properly displayed “Elektor” in ASCII. The latter also indicated that the UART was operating at 4800 baud instead of the 19200 baud that I had programmed (at least that’s what I thought), a difference with a factor of four. The change I had made in my code was a fourfold increase in the clock speed of the dsPIC. The conclusion I had to arrive at is that the clock speed was not being changed. But why not?

Source: Raymond Vermeulen (Elektor, October 2011)

Source: Raymond Vermeulen (Elektor, October 2011)

The inspiration came, and where else, in the shower. In a hobby project, I had used an ATmega32u4 with a bootloader whose only limitation was being unable to program the fuse bits. “That’s not going to be…” I was thinking. But yes, the bootloader I used in my dsPIC cannot program the configuration bits either. Experienced programmers would have realized that long ago, but we all have our off-days. (The solution is to use a “real” programmer, such as the ICD3).—By Raymond Vermeulen (Elektor Labs, Elektor, October 2011)

 

A Coding Interface for an Evaluation Tool

John Peck, a test engineer at Knowles Electronics in Itasca, IL, has used ASCII interfaces to test equipment since he was a graduate student.

“I love test equipment with open, well-documented, ASCII command sets,” he says. “The plain text commands give a complicated instrument a familiar interface and an easy way to automate measurements.”

So when Peck needed to automate the process of reading his ultrasonic range finder’s voltage output, he wanted an ASCII interface to a voltmeter. He also wanted the meter to convert volts into distance, so he added an Atmel AVR Butterfly microcontroller into the mix (see Photo 1). “I thought it would be easy to give it a plain text interface to a PC,” he says.

Atmel AVR Butterfly

Atmel AVR Butterfly

The project became a bit more complex than he expected. But ultimately, Peck says, he came up came up with “a simple command interface that’s easy to customize and extend. It’s not at the level of a commercial instrument, but it works well for sending a few commands and getting some data back.”

If you would like to learn more about how to send commands from a PC to the AVR Butterfly and the basics of using the credit card-sized, single-board microcontroller to recognize, parse, and execute remote commands, read Peck’s article about his project in Circuit Cellar’s May issue.

In the italicized excerpts below, he describes his hardware connections to the board and the process of receiving remote characters (the first step in receiving remote commands). Other topics you’ll find in the full article include setting up a logging system to understand how commands are being processed, configuring the logger (which is the gatekeeper for messages from other subsystems), recognizing and adding commands to extend the system, and sending calibration values.

Peck programmed his system so that it has room to grow and can accommodate his future plans:

“I built the code with AVR-GCC, using the -Os optimization level. The output of avr-gcc –version is avr-gcc (Gentoo 4.6.3 p1.3, pie-0.5.1) 4.6.3.

“The resulting memory map file shows a 306-byte .data size, a 49-byte .bss size, and a 7.8-KB .text size. I used roughly half of the AVR Butterfly’s flash memory and about a third of its RAM. So there’s at least some space left to do more than just recognizing commands and calibrating voltages.”

“I’d like to work on extending the system to handle more types of arguments (e.g., signed integers and floats). And I’d like to port the system to a different part, one with more than one USART. Then I could have a dedicated logging port and log messages wouldn’t get in the way of other communication. Making well-documented interfaces to my designs would help me with my long-term goal of making them more modular.”

These are the connections needed for Atmel’s AVR Butterfly. Atmel’s AVRISP mkII user’s guide stresses that the programmer must be connected to the PC before the target (AVR Butterfly board).

Figure 1: These are the connections needed for Atmel’s AVR Butterfly. Atmel’s AVRISP mkII user’s guide stresses that the programmer must be connected to the PC before the target (AVR Butterfly board).

WORKING WITH THE AVR BUTTERFLY
The AVR Butterfly board includes an Atmel ATmega169 microcontroller and some peripherals. Figure 1 shows the connections I made to it. I only used three wires from the DB9 connector for serial communication with the PC. There isn’t any hardware handshaking. While I could also use this serial channel for programming, I find that using a dedicated programmer makes iterating my code much faster.

A six-pin header soldered to the J403 position enabled me to use Atmel’s AVRISP mkII programmer. Finally, powering the board with an external supply at J401 meant I wouldn’t have to think about the AVR Butterfly’s button cell battery. However, I did need to worry about the minimum power-on reset slope rate. The microcontroller won’t reset at power-on unless the power supply can ramp from about 1 to 3 V at more than 0.1 V/ms. I had to reduce a filter capacitor in my power supply circuit to increase its power-on ramp rate. With that settled, the microcontroller started executing code when I turned on the power supply.

After the hardware was connected, I used the AVR downloader uploader (AVRDUDE) and GNU Make to automate building the code and programming the AVR Butterfly’s flash memory. I modified a makefile template from the WinAVR project to specify my part, programmer, and source files. The template file’s comments helped me understand how to customize the template and comprehend the general build process. Finally, I used Gentoo, Linux’s cross-development package, to install the AVR GNU Compiler Collection (AVR-GCC) and other cross-compilation tools. I could have added these last pieces “by hand,” but Gentoo conveniently updates the toolchain as new versions are released.

Figure2

Figure 2: This is the program flow for processing characters received over the Atmel AVR Butterfly’s USART. Sending a command terminator (carriage return) will always result in an empty Receive buffer. This is a good way to ensure there’s no garbage in the buffer before writing to it.

HANDLING INCOMING CHARACTERS
To receive remote commands, you begin by receiving characters, which are sent to the AVR Butterfly via the USART connector shown in Figure 1. Reception of these characters triggers an interrupt service routine (ISR), which handles them according to the flow shown in Figure 2. The first step in this flow is loading the characters into the Receive buffer.

Figure 3: The received character buffer and pointers used to fill it are shown. There is no limit to the size of commands and their arguments, as long as the entire combined string and terminator fit inside the RECEIVE_BUFFER_SIZE.

Figure 3: The received character buffer and pointers used to fill it are shown. There is no limit to the size of commands and their arguments, as long as the entire combined string and terminator fit inside the RECEIVE_BUFFER_SIZE.

Figure 3 illustrates the Receive buffer loaded with a combined string. The buffer is accessed with a pointer to its beginning and another pointer to the next index to be written. These pointers are members of the recv_cmd_state_t-type variable recv_cmd_state.

This is just style. I like to try to organize a flow’s variables by making them members of their own structure. Naming conventions aside, it’s important to notice that no limitations are imposed on the command or argument size in this first step, provided the total character count stays below the RECEIVE_BUFFER_SIZE limit.

When a combined string in the Receive buffer is finished with a carriage return, the string is copied over to a second buffer. I call this the “Parse buffer,” since this is where the string will be searched for recognized commands and arguments. This buffer is locked until its contents can be processed to keep it from being overwhelmed by new combined strings.

Sending commands faster than they can be processed will generate an error and combined strings sent to a locked parse buffer will be dropped. The maximum command processing frequency will depend on the system clock and other system tasks. Not having larger parse or receive buffers is a limitation that places this project at the hobby level. Extending these buffers to hold more than just one command would make the system more robust.

Editor’s Note: If you are interested in other projects utilizing the AVR Butterfly, check out the Talk Zombie, which won “Distinctive Excellence” in the AVR Design Contest 2006 sponsored by ATMEL and administered by Circuit Cellar. The ATmega169-based multilingual talking device relates ambient temperature and current time in the form of speech (English, Dutch, or French). 

Q&A: Andrew Godbehere, Imaginative Engineering

Engineers are inherently imaginative. I recently spoke with Andrew Godbehere, an Electrical Engineering PhD candidate at the University of California, Berkeley, about how his ideas become realities, his design process, and his dream project. —Nan Price, Associate Editor

Andrew Godbehere

Andrew Godbehere

NAN: You are currently working toward your Electrical Engineering PhD at the University of California, Berkeley. Can you describe any of the electronics projects you’ve worked on?

ANDREW: In my final project at Cornell University, I worked with a friend of mine, Nathan Ward, to make wearable wireless accelerometers and find some way to translate a dancer’s movement into music, in a project we called CUMotive. The computational core was an Atmel ATmega644V connected to an Atmel AT86RF230 802.15.4 wireless transceiver. We designed the PCBs, including the transmission line to feed the ceramic chip antenna. Everything was hand-soldered, though I recommend using an oven instead. We used Kionix KXP74 tri-axis accelerometers, which we encased in a lot of hot glue to create easy-to-handle boards and to shield them from static.

This is the central control belt-pack to be worn by a dancer for CUMotive, the wearable accelerometer project. An Atmel ATmega644V and an AT86RF230 were used inside to interface to synthesizer. The plastic enclosure has holes for the belt to attach to a dancer. Wires connect to accelerometers, which are worn on the dancer’s limbs.

This is the central control belt-pack to be worn by a dancer for CUMotive, the wearable accelerometer project. An Atmel ATmega644V and an AT86RF230 were used inside to interface to synthesizer. The plastic enclosure has holes for the belt to attach to a dancer. Wires connect to accelerometers, which are worn on the dancer’s limbs.

The dancer had four accelerometers connected to a belt pack with an Atmel chip and transceiver. On the receiver side, a musical instrument digital interface (MIDI) communicated with a synthesizer. (Design details are available at http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2007/njw23_abg34/index.htm.)

I was excited about designing PCBs for 802.15.4 radios and making them work. I was also enthusiastic about trying to figure out how to make some sort of music with the product. We programmed several possibilities, one of which was a sort of theremin; another was a sort of drum kit. I found that this was the even more difficult part—not just the making, but the making sense.

When I got to Berkeley, my work switched to the theoretical. I tried to learn everything I could about robotic systems and how to make sense of them and their movements.

NAN: Describe the real-time machine vision-tracking algorithm and integrated vision system you developed for the “Are We There Yet?” installation.

ANDREW: I’ve always been interested in using electronics and robotics for art. Having a designated emphasis in New Media on my degree, I was fortunate enough to be invited to help a professor on a fascinating project.

This view of the Yud Gallery is from the installed camera with three visitors present. Note the specular reflections on the floor. They moved throughout the day with the sun. This movement needed to be discerned from a visitor’s typical movement .

This view of the Yud Gallery is from the installed camera with three visitors present. Note the specular reflections on the floor. They moved throughout the day with the sun. This movement needed to be discerned from a visitor’s typical movement .

For the “Are We There Yet?” installation, we used a PointGrey FireFlyMV camera with a wide-angle lens. The camera was situated a couple hundred feet away from the control computer, so we used a USB-to-Ethernet range extender to communicate with the camera.

We installed a color camera in a gallery in the Contemporary Jewish Museum in San Francisco, CA. We used Meyer Sound speakers with a high-end controller system, which enabled us to “position” sound in the space and to sweep audio tracks around at (the computer’s programmed) will. The Meyer Sound D-Mitri platform was controlled by the computer with Open Sound Control (OSC).

This view of the Yud Gallery is from the perspective of the computer running the analysis. This is a probabilistic view, where the brightness of each pixel represents the “belief” that the pixel is part of an interesting foreground object, such as a pedestrian. Note the hot spots corresponding nicely with the locations of the visitors in the image above.

This view of the Yud Gallery is from the perspective of the computer running the analysis. This is a probabilistic view, where the brightness of each pixel represents the “belief” that the pixel is part of an interesting foreground object, such as a pedestrian. Note the hot spots corresponding nicely with the locations of the visitors in the image above.

The hard work was to then program the computer to discern humans from floors, furniture, shadows, sunbeams, and cloud reflections. The gallery had many skylights, which made the lighting very dynamic. Then, I programmed the computer to keep track of people as they moved and found that this dynamic information was itself useful to determine whether detected color-perturbance was human or not.

Once complete, the experience of the installation was beautiful, enchanting, and maybe a little spooky. The audio tracks were all questions (e.g., “Are we there yet?”) and they were always spoken near you, as if addressed to you. They responded to your movement in a way that felt to me like dancing with a ghost. You can watch videos about the installation at www.are-we-there-yet.org.

The “Are We There Yet?” project opens itself up to possible use as an embedded system. I’ve been told that the software I wrote works on iOS devices by the start-up company Romo (www.kickstarter.com/projects/peterseid/romo-the-smartphone-robot-for-everyone), which was evaluating my vision-tracking code for use in its cute iPhone rover. Further, I’d say that if someone were interested, they could create a similar pedestrian, auto, pet, or cloud-tracking system using a Raspberry Pi and a reasonable webcam.

I may create an automatic cloud-tracking system to watch clouds. I think computers could be capable of this capacity for abstraction, even though we think of the leisurely pastime as the mark of a dreamer.

NAN: Some of the projects you’ve contributed to focus on switched linear systems, hybrid systems, wearable interfaces, and computation and control. Tell us about the projects and your research process.

ANDREW: I think my research is all driven by imagination. I try to imagine a world that could be, a world that I think would be nice, or better, or important. Once I have an idea that captivates my imagination in this way, I have no choice but to try to realize the idea and to seek out the knowledge necessary to do so.

For the wearable wireless accelerometers, it began with the thought: Wouldn’t it be cool if dance and music were inherently connected the way we try to make it seem when we’re dancing? From that thought, the designs started. I thought: The project has to be wireless and low power, it needs accelerometers to measure movement, it needs a reasonable processor to handle the data, it needs MIDI output, and so forth.

My switched linear systems research came about in a different way. As I was in class learning about theories regarding stabilization of hybrid systems, I thought: Why would we do it this complicated way, when I have this reasonably simple intuition that seems to solve the problem? I happened to see the problem a different way as my intuition was trying to grapple with a new concept. That naive accident ended up as a publication, “Stabilization of Planar Switched Linear Systems Using Polar Coordinates,” which I presented in 2010 at Hybrid Systems: Computation and Control (HSCC) in Stockholm, Sweden.

NAN: How did you become interested in electronics?

ANDREW: I always thought things that moved seemingly of their own volition were cool and inherently attention-grabbing. I would think: Did it really just do that? How is that possible?

Andrew worked on this project when computers still had parallel ports. a—This photo shows manually etched PCB traces for a digital EKG (the attempted EEG) with 8-bit LED optoisolation. The rainbow cable connects to a computer’s parallel port. The interface code was written in C++ and ran on DOS. b—The EKG circuitry and digitizer are shown on the left. The 8-bit parallel computer interface is on the right. Connecting the two boards is an array of coupled LEDs and phototransistors, encased in heat shrink tubing to shield against outside light.

Andrew worked on this project when computers still had parallel ports. a—This photo shows manually etched PCB traces for a digital EKG (the attempted EEG) with 8-bit LED optoisolation. The rainbow cable connects to a computer’s parallel port. The interface code was written in C++ and ran on DOS. b—The EKG circuitry and digitizer are shown on the left. The 8-bit parallel computer interface is on the right. Connecting the two boards is an array of coupled LEDs and phototransistors, encased in heat shrink tubing to shield against outside light.

Electric rally-car tracks and radio-controlled cars were a favorite of mine. I hadn’t really thought about working with electronics or computers until middle school. Before that, I was all about paleontology. Then, I saw an episode of Scientific American Frontiers, which featured Alan Alda excitedly interviewing RoboCup contestants. Watching RoboCup [a soccer game involving robotic players], I was absolutely enchanted.

While my childhood electronic toys moved and somehow acted as their own entities, they were puppets to my intentions. Watching RoboCup, I knew these robots were somehow making their own decisions on-the-fly, magically making beautiful passes and goals not as puppets, but as something more majestic. I didn’t know about the technical blood, sweat, and tears that went into it all, so I could have these romantic fantasies of what it was, but I was hooked from that moment.

That spurred me to apply to a specialized science and engineering high school program. It was there that I was fortunate enough to attend a fabulous electronics class (taught by David Peins), where I learned the basics of electronics, the joy of tinkering, and even PCB design and assembly (drilling included). I loved everything involved. Even before I became academically invested in the field, I fell in love with the manual craft of making a circuit.

NAN: Tell us about your first design.

ANDREW: Once I’d learned something about designing and making circuits, I jumped in whole-hog, to a comical degree. My very first project without any course direction was an electroencephalograph!

I wanted to make stuff move on my computer with my brain, the obvious first step. I started with a rough design and worked on tweaking parameters and finding components.

In retrospect, I think that first attempt was actually an electromyograph that read the movements of my eye muscles. And it definitely was an electrocardiograph. Success!

Someone suggested that it might not be a good idea to have a power supply hooked up in any reasonably direct path with your brain. So, in my second attempt, I tried to make something new, so I digitized the signal on the brain side and hooked it up to eight white LEDs. On the other side, I had eight phototransistors coupled with the LEDs and covered with heat-shrink tubing to keep out outside light. That part worked, and I was excited about it, even though I was having some trouble properly tuning the op-amps in that version.

NAN: Describe your “dream project.”

ANDREW: Augmented reality goggles. I’m dead serious about that, too. If given enough time and money, I would start making them.

I would use some emerging organic light-emitting diode (OLED) technology. I’m eyeing the start-up MicroOLED (www.microoled.net) for its low-power “near-to-eye” display technologies. They aren’t available yet, but I’m hopeful they will be soon. I’d probably hook that up to a Raspberry Pi SBC, which is small enough to be worn reasonably comfortably.

Small, high-resolution cameras have proliferated with modern cell phones, which could easily be mounted into the sides of goggles, driving each OLED display independently. Then, it’s just a matter of creativity for how to use your newfound vision! The OpenCV computer vision library offers a great starting point for applications such as face detection, image segmentation, and tracking.

Google Glass is starting to get some notice as a sort of “heads-up” display, but in my opinion, it doesn’t go nearly far enough. Here’s the craziest part—please bear with me—I’m willing to give up directly viewing the world with my natural eyes, I would be willing to have full field-of-vision goggles with high-resolution OLED displays with stereoscopic views from two high-resolution smartphone-style cameras. (At least until the technology gets better, as described in Rainbows End by Vernor Vinge.) I think, for this version, all the components are just now becoming available.

Augmented reality goggles would do a number of things for vision and human-computer interaction (HCI). First, 3-D overlays in the real world would be possible.

Crude example: I’m really terrible with faces and names, but computers are now great with that, so why not get a little help and overlay nametags on people when I want? Another fascinating thing for me is that this concept of vision abstracts the body from the eyes. So, you could theoretically connect to the feed from any stereoscopic cameras around (e.g., on an airplane, in the Grand Canyon, or on the back of some wild animal), or you could even switch points of view with your friend!

Perhaps reality goggles are not commercially viable now, but I would unabashedly use them for myself. I dream about them, so why not make them?