Category Archives: Tutorials/Educational

Experimenting with Buck Converters

If you’re like me, the first thing you do when wiring up a new circuit is to connect the power and ground rails (with the power source initially turned off… maybe).  And you’ve probably got at least one power supply that’ll do the job.  But what if you didn’t have the supply you needed?  Perhaps all you’ve got is a 12V battery, and you’re in need of a 3.3V source.  Well, if you’ve finished your chores, I hear Tosche Station will sell you some power converters.  Failing that, you could always build your own.  A simple buck converter will likely do the trick:

The Standard Buck Converter (via Microchip)

The buck converter takes a DC input voltage and reduces it by a controllable amount, much like a resistive voltage divider.  But unlike your average voltage divider, the buck converter can efficiently supply a substantial output current.  In fact, this circuit’s output current should be greater than its input current (on average).  And no, that doesn’t violate any laws of physics; the converter’s output power will still be less than its average input power because its output voltage is lower than the voltage at its input.  In mathematical terms, (PIN = VINIIN) > (POUT = VOUTIOUT), where IOUT = ILOAD above.  Make sense?

Now clearly this isn’t your typical linear regulator.  Not with that inductor sitting there anyways.  So just how does it work then?  Well, the key is in the switching action of the p-channel MOSFET – a fact that leads us to call such circuits switching regulators.

Think of the FET as a simple switch.  When this switch is on (conducting), the current through the inductor (L1) will  ramp up (since VIN > VOUT), as will the voltage at the output capacitor.  But we don’t want the output voltage to go as high as the input voltage.  So, after a very brief on-time, we turn the switch off again.  But once the FET stops conducting, the inductor’s current has to go somewhere.  Well fortunately we have diode D1 available – it provides a path for current to continue to circulate (out to the load, back to ground, up through the diode and back to the inductor).

Here’s the trick though: this on-off switching cycle happens over and over again, many thousands of times per second.  In fact, the more frequently we switch, the smoother our output voltage will become.  This is because we have an output capacitor picking up the slack (so to speak).  During the switch-off periods, as the inductor’s current drops, COUT supplies the bulk of the output current (ILOAD).  Once the FET is switched on again, the inductor’s current ramps back up and recharges the output capacitor.  Thus, we maintain a constant ILOAD while the capacitor absorbs the ripple current (IRIPPLE).

Now as you may have already guessed, the ratio of the input to the output voltage is determined based on the relative lengths of the switch’s on and off periods.  This is a method known as pulse-width modulation (and it’s used in tons of other circuits):

Typical PWM Waveforms

If the switch were turned on 100% of the time, the output voltage would eventually equal the input voltage.  On the other hand, if the switch were on 0% of the time, the output voltage would be zero.  So it makes sense then that the output voltage is equal to our duty cycle (the percent on-time) times our input voltage.  In other words, if the switch is on for 50% of a cycle, in theory VOUT = (50%)(VIN).  Now in practice, non-ideal components will cause the required duty cycle to be higher than expected, but we’ll get to that later.

By the way, if you’re wondering how to go about picking component values for your own buck converter, there are equations for that.  But instead of going into all of the details here, I’m going to refer you to this excellent guide (and video) from Microchip.  It’ll walk you through an example design for a 12V to 5V, 2A buck converter.

The Experiments

So this past Sunday I was in my “lab” (aka the table in my basement) and decided to see how efficiently I could build myself a buck converter with the parts I had on hand:

yay for protoboards!

I’ve laid out my circuit almost exactly as shown in the schematic above (ignoring the four ceramic filtering capacitors connected across the four parallel supply rails).  On the left is my p-channel MOSFET, followed by diode D1.  The large green and black thing is, you guessed it, the inductor (which I scavenged from a broken battery charger).  To the right of the inductor are three capacitors in parallel (I’ve done this to get better output filtering characteristics at high frequencies).  The white and black wires you see leaving the right side of the board are connected to my resistive load.  The circuit is configured like so:

  • VIN = 10V
  • PFET = IRF9540
  • D1 = 1N4004
  • L1 = 100uH
  • COUT = 270uF (effective)
  • FSWITCHING = 52kHz
  • D = 62%
  • VOUT = 5V

I should also note that these component values were chosen based on an expected load current of 1A and a ripple current of 0.3A.  I only had the one good inductor to play with, so I computed my switching frequency based on its value.

Experiment #1 (Bad Diode)

For this first test, utilizing the 1N4004 general purpose diode, I measured the following:

  • PIN = 8.7W
  • POUT = 5.1W
  • Efficiency = 59%
  • TPFET = 120°F
  • TDIODE = 149°F
  • TINDUCTOR = 82°F

Alright, so while an efficiency of 59% isn’t terrible (particularly by comparison to the 50% you’d achieve using a linear regulator), it’s not great either.  Simple buck converters are typically 80-90% efficient.  So unless my measurements are way off, clearly something’s not right here.  Based on the temperatures I measured using my Kintrex IR thermometer, I suspect the diode may be our efficiency bottleneck (since it’s the warmest component).  To find out, let’s measure a few voltage waveforms while the circuit operates:

Buck Converter Test #1 Scope Trace

The top waveform, in pink, is our measured 5V output, shown at 5V/div.  Below that, in green, is the voltage measured at the connection between D1, L1, and the FET, shown at 10V/div.  At the very bottom, in yellow, is our gate drive signal.  When this signal hits 10V, the p-channel FET will be off; when it’s at 0V, the FET will be conducting.  Note that because of this inverse relationship, the duty cycle calculated by the scope (~38%) is incorrect; we need to subtract this value from 100% to get our true duty cycle (~62%).

So as I suspected, the diode is clearly having some issues.  See that big (~25V) negative voltage spike across the diode each time the FET turns off?  Yea, that’s not so good.  It means our diode isn’t turning on as quickly as it should.  This puts additional stress on the FET.  But when the diode finally does turn on, it’s showing a voltage drop of just over 0.9V.  During the switch-off period of a cycle, the diode has to conduct, on average, the full load current of 1A.  Since our duty cycle is 62%, the diode will be conducting 38% of the time, meaning it conducts an average current of 0.38A.  Using P = IV, we can determine that the diode is dissipating at least (0.38)(0.9) = 0.34W.  The diode’s turn-on delay probably accounts for more loss, but I’m not entirely sure how to calculate that.

Experiment #2 (Schottky Diode)

Well let’s just see what happens when we substitute a much better Schottky diode (15TQ060) in place of that lousy 1N4004 rectifier.  Here’s the data from test #2:

  • PIN = 5.5W
  • POUT = 5.1W
  • Efficiency = 93%
  • TPFET = 81°F
  • TDIODE = 81°F
  • TINDUCTOR = 80°F

Wow, that’s quite a difference in efficiency (from 59% to 93%)!  And it’s all thanks to the minimal (<0.3V) forward voltage of that Schottky diode, as well as its fast turn-on time.  Our waveforms are starting to look a lot cleaner as well:

Buck Converter Test #2 Scope Trace

Experiment #3 (More Current!)

So what happens if we now decide to turn up the heat a little?  What if we suddenly decide to supply a 2A load instead of 1A?  Well, I tried just that.  Here’s what happened:

  • PIN = 12.8W
  • POUT = 10.5W
  • Efficiency = 82%
  • TPFET = 96°F
  • TDIODE = 85°F
  • TINDUCTOR = 81°F

Hmm, it seems our efficiency has dropped again.  But not unexpectedly.  Based on the temperatures of the components, it seems like our FET may now be the limiting factor.  And no surprise; the p-channel device I’ve chosen has an on-state resistance of ~0.2Ω.  Using P = IV = I2R, and multiplying by the duty cycle (the switch on-time), I get:

P = I2RD = (22)(0.2)(0.62) = 0.50W

And even at 0.3V, the diode is still dissipating substantial power as well:

P = IV(1-D) = (2)(0.3)(1-0.62) = 0.23W

Now unfortunately, I don’t have a better p-channel MOSFET to try out at the moment.  So I’m just going to have to accept those losses for now (shame on me).  However, there is a way to nearly eliminate the losses of the diode: replace it with another FET!

The Synchronous Buck Converter (via Microchip)

This time I’ll be using an n-channel MOSFET which, as you may know, contains it’s own diode (called the body diode; the p-channel FET contains one as well, but I’ve omitted it in the diagrams above).  But we won’t be relying on that diode to handle any current.  Instead, we’re going to switch on the n-channel FET whenever the p-channel FET turns off (they’ll be complimentary).  In doing so, we’ll create a low resistance path (<0.1Ω) through which the ripple current can continue to flow during the P-FET’s switch-off period.

Sadly, I can’t claim credit for this brilliant idea.  I’m not sure who first thought it up, but it’s called the synchronous buck converter (as opposed to the asynchronous, or standard, buck converter).  I imagine this is because you have to operate the two FETs in sync with one another.  This makes life a little tricky, as you don’t want to accidentally turn on both transistors at once (thus creating a short from power to ground).  But it’s not bad.

Here’s a scope trace showing the n-channel FET’s additional gate drive signal (in purple):

Buck Converter Test #4 Scope Trace

Experiment #4 (More Current, More FET!)

Well I’m sure you’re just dying to know how much of an efficiency improvement this synchronous converter will provide.  Well fear not, here are the results of my last test:

  • PIN = 12.0W
  • POUT = 10.4W
  • Efficiency = 87%
  • TPFET = 96°F
  • TNFET = 84°F
  • TINDUCTOR = 82°F

Indeed, this is an improvement!  We’re not quite back to the 93% efficiency we saw at a load current of 1A, but 87% is still better than 82%, no?

So, lessons learned?  Use quality components.  That means FETs with as low an on-resistance as possible.  And if you don’t want to go with the synchronous converter, make sure you pick a fast diode with low forward voltage.

By the way, although I haven’t done it here, you’ll probably want to wrap your buck converter in a controller of some kind (unless your load current will be fairly constant).  If you don’t, with a constant duty cycle, variations in load will cause your output voltage to change by a fair amount.  Fortunately, If you look around the interwebs, you’ll find a number of ICs that provide buck converter control.  But if you’re clever, you could whip up your own op-amp control circuit.  Or just program an AVR to do the job for you – they’re great at PWM.  Give it a shot and let me know how you make out.

One last thing: if you’ve been counting, you’ll notice that the losses I’ve calculated don’t add up to the difference between input and output power.  Lest we forget, there are still resistive losses in the inductor and output capacitor, as well as switching losses on the transistor(s).  This switching loss has to do with the power dissipated in the FET’s gate capacitance, as well as resistive losses as the transistor ramps between on and off states (nothing happens instantly you know).  The solution?  Again, buy better parts. 🙂

Questions, comments, suggestions, requests?  Feel free to leave them below.  Thanks!

LabVIEW: More Tips and Tricks

Quick post today.  I recently stumbled across this excellent PDF by Nick Golas.  It contains an enormous quantity of time-saving tips for users of LabVIEW (originally hosted by the IEEE here).  What’s great about this particular work is that it’s illustrated with a ton of screenshots.  For instance, I did not know that you could use the mouse scroll wheel, along with the Ctrl key, to quickly flip through stacked structures:

Use Ctrl + Mouse Scroll Wheel to Browse Stacked Structures

I’ve also never noticed the “Retain Wire Values” toolbar button, which does just that: it retains the last values of any wires which have been executed.  You can then apply probes while the VI is stopped and view the last states of your program.

Seriously though, if you use LabVIEW, take a few minutes and check this out.

LabVIEW: Using the Mouse Scroll Wheel

Lately I’ve been doing a lot of work on a fairly complex LabVIEW application.   It utilizes a number of controls and indicators which have vertical scrollbars (e.g. text boxes and arrays).  This gives users access to a great deal of data without over-crowding the front panel.  Unfortunately, LabVIEW does not natively support scrolling via the mouse wheel.  Well, I happen to like the scroll wheel, and so do many of my users.  So this week I finally went online and found a fairly straight-forward means of implementing this functionality.  You don’t need any crazy DLL calls or APIs; LabVIEW’s “Input Device Control” palette offers this functionality (located under the “Connectivity” section).  I found this particular example very helpful.

I did run into one rather odd problem though.  On my computer, the “Scrolling” value I get using the “Acquire Input Data” block is differential, not absolute.  In other words, when I move the wheel one step, the value of “Scrolling” is 120.  If I scroll no further and poll again, “Scrolling” is back to 0.  However, on the second computer I used to test this function, I received an absolute value.  In other words, if I move the wheel one step, the value of “Scrolling” is 120, but then it remains at 120 until I move the wheel again.  For instance, if I move the wheel by one additional step, “Scrolling” is now 240; the overall value is cumulative (an absolute position).

To combat this problem, I came up with a fairly simple (but not exactly elegant) algorithm that attempts to detect the mouse type based on the first few values of “Scrolling.”  If the absolute value of this parameter ever exceeds 3000, we assume the mouse is of the “absolute” variety.  Otherwise, if we’ve seen this value change more than 10 times without exceeding 3000, we assume it is of the “incremental” variety.  Until these 10 changes are seen, all scroll input is ignored.  This can be a bit frustrating, since the first time a user attempts to scroll something, they’ll have to move the wheel for a second or two before the GUI responds.  However, in the case of my application, I then store the mouse type in the registry, so that the next time the program is launched, the scroll wheel is immediately functional.  No big deal.  If anyone out there has better ideas though, feel free to let me know!

Anyway, you can click on the block diagram below to get a larger view of a quick demo application I built.  This demo shows how you might use the scroll wheel to control text boxes, arrays, sliders, and even graph axis scaling.  You can also download the example ZIP file below.  Feel free to leave comments or questions below.  Thanks!

LabVIEW Scroll Wheel Example - Block Diagram

LabVIEW Scroll Wheel Example - Front Panel

Download: scrollwheel_example.zip (85KB)

Explaining the XMega XPlained (Dev. Board)

About two months ago, Atmel announced a smart new set of AVR development boards, the XPlained series.  One of these boards (which I’ve just recently purchased for $30) boasts a shiny new AVR XMega microcontroller.  What?  An XMega you say?  Why yes, haven’t you heard?  Come now, they’ve been around for fully three years at this point.  Well, don’t worry if this is fresh news, you’re not alone.  For some reason, adoption of the powerful new XMega MCU has been slow amongst hobbyists.

The XMega Xplained (click for high-res goodness)

When Atmel introduced their new XMega series of AVR microcontrollers back in 2008, I was pretty sure they’d be a quick sell.  Even in spite of their unavailability in DIP packaging, and this cheesy marketing video.  But sadly, a quick search of Hack a Day currently yields only four articles containing the term “XMega” (versus more than three hundred articles for “ATMega”).  I guess change is hard.  And yet, it’s really not.

The XMegas utilize the same AVR core as the ATMegas, and are fully supported by the free AVR-GCC compiler and AVR Studio (obviously, I guess).  Plus, you can still use your trusty AVRISP mkII programmer to load code onto an XMega.  In other words, the tool-chain is unchanged.  So, with a few register name changes, code from an ATMega will run perfectly well on an XMega.  Sadly though, the XMegas and ATMegas are not pin compatible, so you won’t be able to solder a new XMega onto your Arduino.

Alright, so for those of you keeping track, I guess I’ve now listed three strikes against the XMega which may help to explain its present unpopularity: no DIP packaging, no pin compatibility with the ATMegas, and changes to register names (plus the addition of new registers for new features).  Oh, and odd marketing tactics.  By the way, as a side note, it could be argued that the XMega register scheme is better than that of the old ATMegas.  They’re making good use of structs, so that you now address a port’s direction using PORTX.DIR, rather than DDRX.  And you output to that port using PORTX.OUT.

But let’s now take a look at the data in favor of the XMegas, yes?  To do that, we’ll compare the ATMega1280 (utilized on the Arduino MEGA) against the ATXMega128A1 (utilized on Atmel’s new XPlained development board):

Feature ATXmega128A1 ATMega1280
FLASH Memory 128KB 128KB
Max CLK Speed 32Mhz (PLL) 16Mhz
EEPROM Size 2KB 4KB
RAM Size 8KB 8KB
Voltage Range 1.6 – 3.6V 2.7V – 5.5V
ADC 16, 12-bit, 2Msps 16, 10-bit, 76.9Ksps
DAC 4, 12-bit, 1Msps N/A
USARTs 8 (one supports IrDA) 4
Hardware Encryption 128-bit AES, DES N/A
Timers 8, 16-bit 2, 8-bit and 4, 16-bit
Current Draw, 1Mhz, 1.8V 365uA 500uA
Event System Yes No
Price $10.20 $16.13

Not bad, right?  I’d say the XMega wins this round.  It’s faster, provides substantially better analog to digital conversion, offers digital to analog conversion (in other words, analog outputs – a feature not available on any ATMega), hardware-based encryption (again, not found on any ATMega), lower power consumption, and, wonder of wonders, a lower price.  I’m quite impressed (for what that’s worth) and am particularly excited about putting these new analog features to the test.  In fact, as I mentioned, I’ve just received my XPlained development board and have already written a quick test program to do ADC → DAC pass-through.  But I’ll describe my experiences with the XPlained board a bit later (spoiler alert: they weren’t all pleasant).

So what precisely does the new XMega series offer that makes it, in my opinion, such a substantial improvement over the ATMega series?  Let’s talk speed for a moment.  The old ATMega topped out at 20Mhz, at least officially (though overclocking is possible, as seen in the Uzebox gaming system).  But furthermore, there is no way to adjust the system clock on the fly (although you can, of course, adjust peripheral clocks).  You’d have to make fuse adjustments with an external programmer.  With the new XMega series, you can adjust the system’s clock frequency at run-time.  Both a 2Mhz and a 32Mhz internal RC oscillator are provided, plus a PLL which allows for clock multiplication (1x, 2x, 3x, …, 31x).  According to application note AVR1005, you can even use the PLL to increase the clock speed of your peripherals to a maximum of 128Mhz.  This might be useful for generating high-resolution PWM signals, for computing precise time intervals (think range-finders), or for just blinking an LED really really fast (although perhaps not this fast).  Man, I could’ve used this on my MS thesis

Another neat feature of the XMega series is the brand new event system which allows for high-speed signaling between peripherals.  This is not a communications bus in the traditional sense.  It’s actually more like a set of, shall we say, “personalized” interrupts sent between features.  Event signals can be sent quite rapidly – in no more than two clock cycles – and don’t require the CPU to be active.

The XMega Event System

The XMega’s event system opens up a whole new world of possibilities.  With it, you could tie a set of 16-bit counters together to form one highly-accurate 32-bit counter.  Or, how about this application note example:

You could use one event to synchronize two modules. For instance, you could use a pin change event to do an ADC conversion and an input capture on the Timer/Counter to get exact time-stamps for each conversion.

For more details on the event system, see the “Getting Started with XMega” application note AVR1005 or the “Getting Started with the XMega Event System” note AVR1001.

First Impressions of the XMega XPlained Dev Board

Alright, well let’s get down to business here.  As I mentioned earlier, I’m now the proud owner of a brand new Atmel XMega XPlained development board.  I was putting in an order with Digi-Key the other night when I thought to search for XMega products (yes, shame on me, I haven’t tried them out until now).  I found just one, but it was precisely what I was looking for: low cost ($30.16), USB-powered, and covered in blinking lights (well, nine of them anyways).  So of course I bought it.  I mean, it’s not quite as much of a steal as the $4.30 TI Launchpad, but even at $30, I didn’t even bother to do research before adding it to my cart.   I just figured it would work.  🙂  Bad idea, I know…

So what did I get for my money?  A pretty padded box and the board itself.  Nothing more.  No documentation whatsoever, only a printed messages on the outside of the box requesting I go online for any required drivers and data.

XMega Xplained Unboxing

Now the lack of paper is fine with me; if Atmel wants to save some trees, good for them.  I’d have gone online for datasheets and schematics anyway.  My only gripe here is that Atmel’s site isn’t all that easy to navigate.  In fact I don’t think I ever located a link to the ZIP file associated with AVR1927 (instead I just crossed my fingers, manually typed in the assumed link, and bingo).  But maybe I’m just bad at the internet.  Well for the sake of centralization, here are a few URLs I found helpful when getting started:

The XMega XPlained comes pre-programmed with a cute little application that blinks its nine LEDs and plays different sounds (drums, trumpets, etc. – just one- or two-second clips) when each of the eight different buttons are pressed. And I’ve got to say, the little speaker actually impressed me with its sound quality.  It’s not exactly a M-Audio studio monitor, but it’ll probably hold its own against a speakerphone.  And it’s certainly not being driven by square waves; they’re making good use of the XMega’s analog outputs (DACs).  So what else does the XPlained offer?  Well, here’s the official list:

  • External memory (8MB SDRAM, MT48LC16M4A2TG)
  • Atmel AT32UC3B1256
    • Communication gateway
    • Programmer for Atmel AVR XMEGA
  • Analog input (to ADC)
  • Analog output (from DAC)
    • Mono speaker via audio amplifier
  • Digital I/O
    • UART communication through USB gateway
    • 8 mechanical button switches
    • 8 LEDs (plus one bi-color LED)
    • 8 spare analog pins
    • 24 spare digital pins

Programming the XPlained using FLIP

So the pre-loaded software entertained me for about sixty seconds, after which my desire to reprogram the board overcame my fascination with lights and sound effects.  I didn’t have my AVRISP mkII handy (left it at work again), so I started by looking into reprogramming via the board’s USB connection.  The first thing I needed was a driver for the virtual COM port (Windows 7 did not recognize the XPlained), a single INF file:

USB CDC Driver (Virtual COM Port) – required for USART communications.

I was pleased to find that the instructions provided in the “Getting Started” guide (AVR1927) for using the Flexible In-System Programmer (FLIP) for RS232 programming were quite simple.  I downloaded and installed FLIP via this link.  I also had to import an XML configuration file (provided here), although it sounded like this file should have been included in the latest FLIP installer.  But before adding this file to <Install Directory>Flip 3.4.xbinPartDescriptionFiles, I received an error stating that “the device does not exist” when using BatchISP (the FLIP command line utility).  I also attempted to use the FLIP GUI directly, but for some reason the RS232 communication option was greyed out.  No problem though, I simply threw the programming commands given in the instructions into a simple batch file:

batchisp -device ATXMEGA128A1 -hardware RS232 -port COM25 -baudrate 115200 -operation onfail abort memory flash erase f blankcheck loadbuffer c:xmegatestdefaultxmegatest.hex program verify start reset 0

pause

I’ve highlighted the elements you’ll want to change when using this file.  Including that pause command causes the command window to wait for you to press a key before closing, that way you can take a look at the results of your programming attempt:

FLIP (BatchISP) Command Line Programmer

So using BatchISP (FLIP) worked just fine for me.  The whole programming process took a bit longer than I would have expected (maybe 20 seconds), but it’s not terrible.  The one catch is that you have to unplug the XPlained board, and then plug it back in while holding down switch SW0, every time you want to reprogram.  This is required in order to activate the bootloader.  Doing this gets old fast, and it didn’t seem to please my computer (it would occasionally freeze for a few seconds when the device was quickly plugged back in).  But there is an easier way; keep reading…

Programming the XPlained using the AVRISP mkII

So based on the literature I’ve run across, it seems the preferred means of reprogramming (and debugging) an XMega is via JTAG using either the AVR Dragon ($50), the AVR JTAGICE mkII ($300), or the Cadillac of debugger/programmers, the AVR ONE! ($600 – perhaps this is the reason for the exclamation point).  The new XMega series uses the PDI (Program and Debug Interface) programming interface (as opposed to ISP).  However, it is possible to use the AVRISP mkII programmer (though you cannot use it for debugging), which costs just $35.  And if you’ve done anything with AVRs in the past, you’ve probably got one of these hanging around (I should note that the original AVRISP, the one with the DB9 port, will not work with the XMega series).

Now, to get your AVRISP working with the XMega Xplained, you’ll need to create a simple pin adapter.  You cannot connect directly to the board as the pins are arranged for a 10-pin JTAG connection (I guess Atmel really wants you to use JTAG).  However, you’ll only need to connect four of the six pins present on your AVRISP, as shown in this diagram (found on page 9 of the XMega “Getting Started” guide, AVR1005):

AVRISP Pinout Comparison

These pins can be found on the XPlained’s JTAG connector, as shown in the schematics:

XMega XPlained JTAG Connector

Once you’ve made these connections, you can use AVR Studio to reprogram your device as usual.  Well, almost.  First, you need to make sure it’s fairly up-to-date (I used version 4.18, build 700 with success, but you might go straight to AVR Studio 5, which I’ve also tried with success).  You’ll then need to manually specify the ATXMega128A1 before programming or adjusting fuses.  Plus, and this is key, you’ll want to disable the JTAG interface by using AVR Studio to clear the JTAGEN bit on the fuses tab.  If you don’t, your programming may or may not be successful.  I actually got into an interesting cycle where alternate programming/read events would fail.  I’d perform one operation successfully, but on the next I’d see “Entering programming mode…FAILED.”  But disabling the JTAG interface took care of this issue.  And doing so does not prevent you from re-enabling JTAG later, or from using BatchISP (though you may need to reload the bootloader if you’ve erased it, which may be found in this ZIP).

For more details on programming and debugging an XMega, see this article (and actually, check out all of these “Getting Started with XMega” articles, they’re quite good).

A First Test of the Analog I/O

Now I think I’ve stated this already, but again, I’m pretty excited about the new analog I/O offered on the XMega series.  In particular, the 12-bit digital to analog converters (DACs) open up a whole new world of options.  I mean, there are all sorts of applications out there that might benefit from an on-chip DAC: function generators, analog power supplies, audio processors, lighting controls, you name it!

So the first bit of code I wrote for my XMega is a simple ADC → DAC pass-through.  It’s a touch long to include in this post (because of all the comments), but please feel free to download it here.  The code takes an analog input on ADCA1 (PORTA1, pin 96) in the 0-2.1V range and outputs a proportional analog signal on DAC0 (PORTA2, pin 97) in the 0-3.0V range.  Here’s a screenshot of the results taken using my RPI IOBoard and LabVIEW interfaces.  The bottom graph (red line) shows the sine wave signal being generated by the IOBoard and connected to the XMega’s ADC input.  The top graph (white line) shows the scaled sine wave being measured at the XMega’s DAC output:

XMEGA ADC-DAC Pass-through Test

You may be wondering: why the difference in input and output voltage ranges?  Well, here’s one additional problem I see with the XMega: Vcc (max 3.6V) is not directly available for use as a reference for the A to D conversion, only Vcc/1.6V (which is 3.3/1.6 = 2.0625V, in this case).  Now you can select AVcc (typically tied together with Vcc, perhaps via a filter) as a reference for the DACs, although according to the hardware datasheet, both ADC and DAC reference sources are limited to AVcc-0.6V, or 2.7V on a 3.3V source (which is what you get on the XPlained development board).

Now in testing these specifications, I have found the ADC limit to be fixed as stated, although when I’ve selected AVcc as the reference for the DACs I’ve seen max outputs reach just over 3V.  Honestly, I don’t know what prevents the XMegas from using Vcc as a reference, as this is commonly done with ATMegas.  Oh well!  You just may need to throw in a voltage divider and/or op-amp to compensate.

One other issue I noticed was noise in the ADC signal when measuring values near 0V.  This could be an issue with how I’ve setup my code, or with some other aspect of my hardware.  But you can see this effect in the slightly garbled low points of the sine wave shown in white in the above screenshot.  I guess the bottom line is that I’ll need to play around with this a bit more.  (NOTE: I believe we have solved this issue; it is a problem with the XMega chip itself.  The solution is to use a lower (e.g. 1V) reference for the DAC.  See comments section below.)  Apparently there are also calibration registers for the ADC, and some pretty advanced tweaks you can make.  Take a look at this page on configuring and tuning the XMega ADCs – it’s been a great help to me already.

Conclusions

Overall, I’m cautiously optimistic about the XMega and the XPlained development board.  I’ve encountered a couple of minor issues, and the list of problems in the errata section of the datasheet is frighteningly long.  I should also point out that a previous version of the XPlained, the XPlain, apparently had quite a few more serious issues.  You’ll find references and pictures of the XPlain if you do a bit of Googling.  I’m not sure who’s still selling it, but I can tell you that despite the picture and the name, Digi-Key is shipping the newer XPlained, not the old XPlain (this is where I got mine).

So I still say that the XMega a great leap forward by comparison with the ATMega series.  The only question left is what to do next?

I’ve been thinking about going further with this ADC-DAC application and creating an audio compressor and volume control.  You see, I’ve got this cheap portable speaker that I use with my Blackberry for listening to MP3s.  The trouble is, there’s no remote, and each track seems to play at a slightly different volume.  So I’m thinking of using the XMega to receive IR signals from a remote and then adjust the volume accordingly (by scaling the ADC result before sending it to the DAC).  And at the same time, it could automatically adjust volume, based on the incoming audio signal, within a certain range.  This is called compression.  My setup would require a bit of analog work to get the signals into the correct voltage ranges before and after processing, but a couple of op-amps would likely do the trick without much work.

That said, I’m open to other ideas.  Has anybody out there got suggestions for projects?

The EEWeb Forums

EEWeb LogoSo I don’t often plug websites, but lately I’ve been browsing EEWeb and have found it to be quite a useful and even entertaining resource.  You’ll find a wealth of informative articles on topics ranging from power management to PCB design, plus current news items.  Perhaps most interesting, however, is the EEWeb Forum, where anyone can pose queries related to electrical engineering (example).  Ask a question, and you might get responses from practicing engineers, hobbyists, or even professors.

Plus, as I mentioned, EEWeb even offers a bit of amusement to liven up your day. Check out their web comic, “Return to Zero.”  If you’re an EE, I think you’ll get a laugh or two.