Archive for May, 2010


Getting started with Xmega: clock management



The Xmega has made some major advances in clock management, likely as a conceptual follow-on to the picoPower AVR. While clock selection used to be both limited to a few options and mostly configured via fuses (at programming time), the Xmega has a very wide range of clocking choices that are entirely run-time configured.

The Xmega has the following clock sources available:

– 2MHz internal RC
– 32MHz internal ring oscillator
– 32.768 internal precision RC
– 400kHz – 20MHz external crystal
– 32.768 external crystal
– External (square wave) clock

In addition there are not only the usual clock dividers, but a PLL capable of anywhere from 2x to 31x multiplication.

All chips power up off the 2MHz internal RC at all times, because it’s the first to come up and is guaranteed to be available. All user code that wishes to use something else must configure it before continuing.

Each clock source has both an enable bit and a ready flag, since various clocks take different (and sometimes relatively long) periods of time to stabilize. The external crystal drivers also have failure detectors with dedicated interrupts that fire after the clock is switched back to the 2MHz fallback.

Several of the key registers are covered by the Configuration Change Protection (CCP) mechanism, which is nearly identical to the mechanism used to change or disable the watchdog timer on conventional AVRs. To write the protected register one must first write the CCP register, then the desired register within some short number of cycles (typically 4). This is to protect mostly from rogue memory pointers drifting into critical registers.

There are a total of 3 dividers, which allow the clock to be dropped by as much as 4096(?)x from the base frequency, in powers of 2. However, the first two have more specific purpose: they allow higher peripheral clocks to specific modules. CLKper4 and CLKper2 drive the high-res timer and External Bus Interface modules, respectively.

To make use of these higher frequencies, the (???) register can be set to predivide the input clock in order to bring it down to the range in which the actual CPU can operate. For instance: 8MHz crystal with 16x PLL gives 128MHz, which when divided /2,/2, gives 32MHz to the CPU, 64MHz to the EBI, and 128MHz to the highres timer extention.

Additionally for those who need the lower parts count you get from running off one of the internal oscillators, the Xmega theoretically offers two DFLL’s (Digital Frequency-Locked Loop) that are supposed to adjust the timings (a la OSCCAL) relative to a 32.768kHz reference, either internal or external. However, this module appears to be particularly buggy, and for the most part can be treated as if it doesn’t exist, at least in current silicon.

I will be posting a form of my clock routines sometime tomorrow to help get people boot-strapped on something other than ~2MHz…


Getting started with Xmega: toolchain


(first edit of iPhone version)

Another major advantage of the Xmega is the fact that it is running the exact same CPU core as the original AVR, which means the toolchain is almost exactly the same. The only major things new to these chips are the linker scripts (since flash addresses are different) and the header files that define the registers for the various peripherals.  However, it is still the case that if your toolchain doesn’t have the necessary changes and is thus aware of the particular chips you’re using, you’re sunk.  The situation is still somewhat inconsistent enough that you may end up with a few challenges between you and writing code for the Xmega.

GCC is the default compiler in the open-source world, and it has been made to work with the AVR even though it’s not strictly the right kind of processor (GCC dislikes Harvard-architecture chips as a rule).  The avr-gcc project maintains the patches necessary to compile for AVR chips, and thus is responsible for managing the patches that make the Xmega work as well.  The current problem is that the various distributors of avr-gcc are responsible for actually bringing those patches into their builds of the software, and that’s where the breakdown is right now.  avr-gcc is in the process of getting their patches folded into the GCC mainline, which will eliminate the problem, but that could still be in the works in 2011…

Xmega support was initially added back when the silicon was still a glimmer in the hobbyists’ eye, and began in earnest when early silicon was delivered to select developers (to te best of my knowledge). As such, full support of the whole range of devices took a little while to fully materialize.  The current set of patches (as of roughly early June 2010) finally contains support for all the Xmega devices Atmel has actually physically shipped, plus a few extras still in the pipeline or available only in select (export) markets.

The Win-AVR bundle, which has recently been discontinued in anticipation of upgrades to AVRStudio, was generally the most up-to-date toolchain you can get.  The “most official” place to get patches would be either the Win-AVR site, or the FreeBSD repository, seemingly dependent on the weather.  Folding into GCC mainline will resolve that problem, but Win-AVR is still the “easiest” place to find what you need.

Unfortunately, distributions like Ubuntu (and its underlying Debian) haven’t been as careful in updating.  The Ubuntu 10.04 avr-gcc packages are no different than the year-old 9.04 packages, and thus contain only small fragments of Xmega support.  A number of scripts and other documents are out there that purport to solve the problem, but the several that I’ve looked at have the same problem of having been inconsistently updated.  As a result it took me longer than it should have to piece together a toolchain for my machine.  I will be posting the .deb’s of those packages in the near future, hopefully before the Open Lab on June 27th.


Getting started with Xmega: programming software


(first edit of iPhone version)

Once you have the required programming hardware for your Xmega, you need to figure out how to actually use it to load your code.  You can’t just shove it at the programmer and hope it does something intelligent (though that would be nice), you have to talk the particular language of each programmer.  At least for the Atmel programmers there’s one main protocol (STK500[v2]), but there are so many variations even within that one protocol as to make anybody’s head spin.  Luckily, that’s why people write programming tools: to hide the (sometimes unnecessary) complexity of the programming hardware.

Right off the bat, I’ll list the default AVRStudio as the most integrated solution. However, that’s about all I can tell you, since I only use it for reference and recovery when I run into problems or complications with my usual method. Hopefully somebody who already uses it or learns how can post further details, which I can fold into this tutorial if desired.

AVRDude is the other major piece of software, and the only one I use to actually load code. It’s an open-source tool capable of using any of several dozen types of programming hardware to flash most every AVR out there (and then some). It works best on Unix-style systems (Linux, Mac) but presumably runs just fine on Windows as well, as it’s packaged with the Win-AVR bundle.

When I put projects together, I typically start with a simple shell script that compiles, preps and downloads the firmware in one go. This is somewhat peculiar to my work patterns as I don’t use an IDE of any sort (not even emacs).  Makefiles are the more common but also somewhat more involved method.  Most projects I create that use more than one source file are implemented with Make, but more on that later.

The actual command to flash the chip is something along the lines of:

avrdude -pavrisp2 -Pusb -cx192a3 -U w:flash:myprog.srec

The -p argument sets the programming tool to be used, and -P tells avrdude which port to use.  usb is the connection method for all of the currently available Xmega-compatible programmers, though my current project uses a bootloader that implements the avr910 protocol over a standard serial port, e.g. /dev/ttyUSB0.  The chip being programmed is given by the -c, and -U specifies an upload operation, in this case writing to flash the contents of myprog.srec.


Getting started with Xmega: programming hardware


(first update pass of iPhone-written draft)

Atmel’s new AVR Xmega chips use a new programming interface called PDI (Program and Debug Interface) that has both advantages and disadvantages vs. the older ISP protocol used by the original AVR series. The main advantages are the reduced pin count, and the use of the same 2×3 pin connector (if you’re confused, read on…). The disadvantage is that it’s a new protocol that isn’t quite as well supported yet.

While the old ISP protocol is basically SPI with the chip-select line driving RESET, for a total of 6 lines (GND, VCC, SS/RESET, SCK, MISO, MOSI), the PDI protocol is bidirectional synchronous serial, using only 4: GND, VCC, CLK, DATA. This reduction in pin count has two advantages: the number of pins used on the actual chip is lower, and custom programming interconnects can get smaller. The main effect of this on the Xmega is that the PDI lines are strictly dedicated to programming: no more carefully sharing the SPI bus with your real peripheral[s]!

Now back to the part about it being the same old connector: Atmel realized that everybody had developed a significant, um, “attachment” to both their existing programming tools and the connector itself (as opposed to say JTAG’s varied and invariably larger pinouts), and forcing everybody to buy brand new tools just wasn’t going to happen. They also determined that the bidirectional bus of PDI could be effectively implemented by some of their “older” tools!

As a result, they did something that seems far too rare in any industry: add new functionality to already-sold hardware by enhancing the firmware. Duh! you say, but you’d be surprised how often it doesn’t happen.

The gist of this all is that for the most part, any of Atmel’s tools in the last several years have been updated to program the Xmega’s. Off the top of my head (while sitting on a ferry…) at least these programmers are supposed to work:

– Dragon

All these programmers use the STK500 protocol with an “XPROG” extended mode, which grants access to all the newer memory (flash) regions of the Xmega chips.

I haven’t particularly looked for any third-party support for the PDI protocol in other programmers, so at this point you’re mostly stuck with the above devices.  However, the AVR-ISP MkII isn’t really all that expensive, running $35.36 from Digikey.  While I applaud people who design their own bootstrap programmers and such, I really never got the obsessive need to spend so much effort to save a Jackson or two.  I know how much work it takes to implement a programmer like this, because I’ve been required to do so for some commercial projects.  I’m writing one right now as it turns out…  Development effort can run into the $1000’s if you value your time at all.

That being said, I am going to be writing my own PDI stack in the near future, because of the requirements of a commercial project very similar to the one that had me writing such code last time.  It will be released to the public in a form that I believe will be far more modular and easy to integrate into other software projects.  More on that later.


Writing “nano-curses” for microcontrollers


My main contract these days is developing into a software stack that needs to both send a lot of debugging and status data, and receive commands over the serial debug port (which in the next generation will be Bluetooth…).  The problem is, I need to be able to deal with this in the main codebase in a relatively sane manner.  That means using xterm command sequences, but hiding them behind some kind of API. The obvious candidate would be curses, of course.

So, I’m developing a microcontroller version of curses, that’s intended to be as lightweight as possible given the complexity of the problem.  The first major cost is the terminal buffer, which has to be at least a byte for every character on the screen.  I might experiment later with a non-buffered curses, especially as this is not intended to run over “slow” connections in the first place (at least for my application).  The real challenge is going to be figuring out things like subwindow scrolling rules, and all the quirks like keeping track of the cursor when a tab is inserted, etc.

I plan on releasing this code as open-source once it’s reasonably usable, and I have somewhere on my as-yet-nonexistant website to put it…


“Rev 1” Xmega adapter art


I’d mentioned a post or so back that I found assembly costs to suffer from the use of QFN chips, and that I was going to redesign the Xmega adapters to use PQFP instead.  Here they are:

I call these the “rev1” boards because the first round of QFN’s were the real functional test.  These boards have identical schematics, just different parts implementing it.  The pins are now surface-mount on the bottom of the board, which doesn’t even come close to offsetting the costs of the QFN when it comes to assembly (quoted at Screaming Circuits).  I’ve also switched the A3 boards back to 0603 caps, since while I can do 0402’s by hand (the first rev0 A3 board is assembled and working as well!), I don’t think they’re going to scale well for production.  They spend half their time stuck to the tools instead of the board…

I’m going to turn a set of 3 of each of these with the next group order to make sure I can do the bottom-side headers, then these will be the “final product” boards until something else needs to change…


Xmega board up and running!


This morning I soldered up the first of the A4 boards, and it works great so far!  I’m working on thorough “boundary scan” testing in the form of hooking up LEDs to each of the pins and making sure the chip soldered properly, and if that passes I have a perfectly functional board.

For those who got boards and parts kits last night at DorkbotPDX, here are ZIP files of the final Eagle and Gerber files the boards were made from:

One thing I forgot to mention to everybody is that the crystal has to be connected via a pair of solder jumpers right up against it.  The soldermask is supposed to be missing from between them, and the gerbers show that it’s supposed to be, but the boards look like they have some in there anyway.  What it boils down to is that you need to make sure you glob plenty of solder in there, either paste or after the fact.

After some research into the costs associated with making these in quantity, I came to the conclusion that a redesign was in order, to use the PQFP parts instead of QFN.  The resulting boards are a hair wider, and use surface-mount headers on the bottom, but are schematically identical to this first batch of boards.  The A3 version might actually end up being a 900mil board though, since the PQFP-64 isn’t liable to fit on even the wider 600mil board…  The resulting boards will end up my upcoming webshop, hopefully within a few weeks.