A few years back Atmel announced a new line of chips, the XMega series. We see the name bouncing around here and there, but when [Michael Kleinigger] mentioned that he’s seen very few project using these chips we realized that not only is he right, but we know next to nothing about them. Just give his XMega review post a whirl and you’ll be up to speed in no time.
He compares an XMega128A1 side-by-side with an ATmega1280. For those that abhor reading paragraphs full of words, there’s a table that can give you the quick facts like how the XMega costs less and runs faster. But we know from past discussions (like the one on PWM) that [Mike] knows his stuff so the whole thing’s worth a read. He’ll lead you through the programming tool chain (which hasn’t changed), a bit about the new event system, and then finish with a demo program on the Xplained development board.
35 thoughts on “Regarding Atmel’s Xmega Chips”
Hmm, looks like we broke the site… I can’t connect.
The problem with the XMega is Atmel has nothing inexpensive (last I checked) that will program them. Even SparkFun (stupidly IMHO) disables the JTAG interface on their breakout, so it is ICP(?) or nothing – the Dragon could flash via JTAG but you need JTAG enabled, and there is no way to do that with a Dragon. You need their $300? programmer-debugger.
The Xplain board is nice, but only has one of the 8 ports, isn’t that cheap, and doesn’t turn into a programmer for external Xmegas.
Looks like Google cached the site.
Linking to a website hosted on a home DSL/cable connection is a BAAAD idea. The guy will thank you for his internet connection bill and what effectively amounts to a DDOS attack :(
Does that link actually work for anybody?
Here’s the cached article:
Look up AVR ISP Mk.II
It will only programme but with so many IOs I just use printf() with one of the uarts.
And for the reasons the XMega doesn’t really have much of a following: I think it’s too close to the ARM offerings that spring up everywhere. If you’re gonna have to read yourself into a whole new set of peripherials, you can just as wel get an ARM. For example, the ATXmega the guy described is about E4.50 on digikey. For about the same price, you can have a LPC1227 which is a nice 45MHz Arm Cortex-M0 32-bit CPU with the same memory specs and a load of peripherials too. For 2 bucks more, you can even have a LPC1754 which is a 100MHz Cortex-M3.
@Sprite_tm: yeah, it would have been a great chip in 2003 or so :)
@tz Doesn’t Dragon also program via ISP (emulating AVRISPII)?
An Atmel rep. dropped off an Xplained board with an AVR Dragon too me at work but I never got round to looking at them. There was also some kind of capacitive touch “shield” he dropped off. Looked pretty cool tbf.
Interesting article, even if I did have to read the google cached page.
It may have the same effect as a DDOS attack, but it certainly is not, since the goal of a DDOS attack is to disrupt service and I don’t think that is Hack a Days intent. Actually it is simply a case of overloading the hosting server / bandwidth. This happens to a lot of sites when they suddenly become popular, even those hosted on paid hosting sites.
It is not Hack A Days responsibility to look at the type of connection a link has. Many business are run from cable modems and DSL and host websites and other servers quite successfully on them. The fault is entirely with the author who probably didn’t anticipate getting Hack a Day’d, or doesn’t want to pay for the needed hardware and bandwidth to accommodate one surge of visitors in ten years.
These programmers are about $23 on eBay and $30 from more sensible places:
They’re called AVRISP Mk II and we use them a lot.
@tz: The entry level programmer (isp MkII) works, they just changed the protocol from SPI to PDI.
As Sprite_tm said, I think the market for anything more complicated than an 8-bit micro is rapidly evaporating in favor of low-end ARM chip.
There’s also a lot of issues with silicon bugs in the xmegas, and the fact that you have to deal with Atmel’s sometimes dodgy part availability (at least for small quantities).
I like them a lot, I think the peripherals are great and the move to struct style hardware definitions is a lot nicer than the plain AVRs. There’s a small niche for them as a step up without having to get a whole new tool-chain setup, but I don’t think they’ll do great long term.
Comfile Technologies has a whole line of Atmega-based microcontrollers, boards, and even a new Arduino lookalike.
I’ve used the cb320, cb280, ct1721 in a variety of projects with good success.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=103269 The AVR fanbois (I am a registered freak myself) themselves have a thread about why Avrfreaks dislike the xmega.
I think in 2008 it was Product of the year in Electronic Products Magazine, except it was vapourware.
Xprotolab uses one of the xmega family, but there are better options out there as already pointed out. Xmega could be good enough if you have committed a lot of time and money to AVR family though.
@tz You can program many of the xmegas through the dragon via JTAG. I frequently use it to program xmega128’s and as stated above the ISP MKII programmer will pick up many of the rest through PDI.
On another note: the event systems in these little processors are crazy. I have a system using an ISM band wireless solution that is able to stay in sleep mode while it sees an interrupt from the rf transceiver, captures the data over SPI and stores it via DMA into a buffer than can be read once I do wake the processor up.
Actually the other fun fact to point out is that Mouser/Digikey won’t sell to non-US customers if the xmega has cryptography functionality (most of them I think). They claim it contravenes some export law; others have actually looked into it and that’s not the case – I got a dev board from Mattair and to my knowledge they didn’t send him to prison.
So you’re stuck with your local distributor, which in some cases can mean major expense.
In my work, I do side-channel attacks on the AES-crypto-engine. Pro: Hardware crypto is far more secure than on SW. (but its still possible to beat it)
With the Xmega familiy, a new nomenclauture (and an elsewise arrangement for port registers) for application programming was introduced. It is more comfortable and needs less code!
Well, some features, like Bootloader support and other things are not even implemented in Avrdude, so I recommend to use Avrstudio to program them. And the AVR ISP MkII with an updated firmware.
There are far too few sources for xmegas available, like open libraries, example code, open source projects,… – I think that’s why they are so underrepresented.
IMHO the hobbyists have not even started to max out the potential. Xmegas are a possible 8Bit-substitute for atmegas.
I think it’s worth noting that Atmel is advertising that these chips have better USB support than ever before. While, yes, they are easier to hook up to the bus itself, there are no devices in the parametric that has actual otg/host mode support. The AT90USB* (ATMega series) has otg support with plenty of support via LUFA (http://www.fourwalledcubicle.com/LUFA.php).
I still wonder why the hackers haven’t switched to ARM. I did AVR for years and then tried an Atmel SAM7. Wow! Way faster and very easy to program. Yes there are a *lot* more registers but its the same exact concepts, just more of them.
I think the biggest problem is when people who know AVR only know how to use prepackaged libraries. My teacher in college was Pascal Stang, the guy that wrote the very famous procyon avrlib. I used it when he taught us, but after a few years the library was lacking support for some new chips, so I decided to just learn how to read a datasheet and use registers to configure the UART and A2D. It took a bit of time but it was well worth the learning, because then when I picked up ARM it was really simple.
Everyone should know how to enable and configure the UART of an AVR without any libraries. I’m sure plenty of you do but its a core skill that I think lots of people don’t learn, and it really hurts them.
Oh, and I should note that the new SAM3 ARM chips kick even more ass.
I have to believe that the disdain for these chips is because they don’t come in DIP packaged versions, because they’re pretty awesome.
What sets these guys apart is the peripherals–I’ve never seen an 8-bit mcu with as powerful on-chip peripherals as this. Multiple timers, each having multiple compare interrupts. Four channel DMA (i think…). ADC + DAC. UART, i2c, spi, all the regulars. I/O ports that have lots and lots of control registers so that various operations can now be performed with a single write.
However, my personal favorite is the event system, which allows various peripherals to communicate with each other in a limited manner, allowing conditions on one to trigger a response on another without an ISR. This is especially useful for triggering the DMA, or simply just cascading two 16-bit timers together into one 32-bit timer (it corrects for the delay, as well).
All in all, they’re pretty sweet. Some things, like the ADC, take a bit of getting used to, but that’s only because it frankly has a ton of features (in this instance, input multiplexers allowing single ended or differential measurement, with or without gain, with configurable reference voltage, and unsigned or signed output).
Oh, I forgot to mention that Atmel has spent a lot of effort documenting each and every peripheral. Some are better than others, but there is a driver to get you started with just about anything.
To be fair, the coding style (and the structs associated with each peripheral) may be daunting at first, but it’s really clearly explained in an app note, and makes work a lot more efficient, as well as making code effortless to modify for different devices.
These guys really aren’t replacements for Atmegas–they’re a new beast, and the level of integration of the peripherals makes them replacements for ARMs in certain situations where some real time routines can be replaced with hardware peripherals, or in situations where you would have to use an Atmega along with external support chips (DACs, ADC front ends, RTCs).
And before I get called a blind fanboi: There are still a handful of silicon errors, which is annoying, but nothing that’s really an issue (for me, at least). Also, the number of timer interrupts (and the interrupt priority system) have severely degraded my coding skills. Instead of making a nice scheduler that uses one timer, I can give half of my periodic bits of code their own timer interrupt. The chip I primarily use (Atxmega256A3) has 4 X 16 bit timers with 4 compare/capture interrupts each, and 3 X 16 bit timers with 2 compare/capture interrupts.
I foresee a mass exodus to ARM devices in the near future.
The cost of the cortex parts has gotten so low that it is crazy to pay more than 4 dollars for an AVR in single quantity.
The other thing I’ve noticed is that the PIC18 series has gotten way cheaper than the AVR on the whole. The only thing preventing that from taking off is the lack of a decent free compiler.
I have a few xmegas running a project called openservo on them. While the chip is fairly fast, the silicon bugs in several modules just drove me away.
Eventually, just before I gave up on them, i tried to get quotes for pcb assembly… And to my horror found they are extremely hard to get in quantity
FYI, the server’s back up and running… bad timing getting this article posted today (internet trouble on one end and a slow backup server on the other), but that’s really no excuse. Thanks for the comments all.
I’m seconding the programming issue. I ran face-first into this problem when trying to program an XMega with the AVR Dragon. The AVR XMega supports both PDI and JTAG programming, but the JTAGEN fuse bit must be cleared (it is set by default). While the Dragon (supposedly) supports PDI on certain chips, it does not support PDI with the XMega I was using (even though it was listed as being supported on Atmel’s website). I ended up having to buy a second programmer to set the fuse bit so that I could use the first programmer. Time and money wasted.
They really aren’t worth the trouble, in my opinion.
Oh, and there are _two separate_ datasheets for the XMega, each with information the other does not have.
“Oh, and there are _two separate_ datasheets for the XMega, each with information the other does not have.”
This is technically true, but not really an issue. The device family datasheet contains everything you need to know about, say, the XMEGA A family. All the registers, programming, etc… The device specific datasheet tells you which peripherals a specific chip has, the pin assignments, and the errata for the chip.
Once you’ve completed your board layout, the device specific datasheet shouldn’t really need to be looked at again. The point of separating the datasheets is because code for the chips is extremely modular. To port code from one chip in the A family to another, all you need to do is change the device in the makefile, and reassign hardware peripherals if the new xmega doesn’t have that instance of the peripheral. Properly written XMEGA code will only require that a *single line* be change which peripheral is used by your code.
I won’t even go near an Xmega until the errata in the data sheet is down to less than one page. :3
If Atmel can work out the supply and QC issues, AND get the ridiculous amount of errata down to two or three things WITH work-arounds, I might give them a go. The ADC problems were definitely a deal-breaker for me.
From my perspective, what’s the motivation for me to switch to a buggy-as-hell yet theoretically-bad-ass new uC, when there are ARMs and regular ATmegas (the ATmega32U4 for instance, which I love) available? All with great ‘biospheres’ of support, IDEs, libraries, and such?
I know, all of this has been mentioned, but I’d rather stand and be counted. Does anyone else think Atmel is starting to trip over its own feet?
I’ve just given up on Atxmegas. The documentation for the ‘D’ series is awful (they cannot even cut and paste properly from the the A series manuals). Too many features don’t work. Great shame that the folks at Atmel do not sort their act out – could have been a very classy family.
OK – I will look into an AVR ISP mk II – thought I would note they should update the dragon. At the time I was experimenting with them about a year ago, this was NOT an option.
JTAG would work, but if the fuse bit has it disabled, you need a PDI mode programmer to enable it so it doesn’t help.
AVR Dragon does PDI – this works fine with xmega, I’m using it right now to program the one on my Xprotolab.
The AVR Dragon works very well on all of my projects whether XMega or not. You don’t have to buy the AVR/ISP. The main strength of XMega for me is the amount of I/O. One of my projects uses four independent SPIs. The other AVRs would have involved a lot of bit bashing and might not have been fast enough.
FYI, the link to this article is now at http://www.nlvocables.com/blog/?p=545
Please be kind and respectful to help make the comments section excellent. (Comment Policy)