Switching from Mega to Xmega?

Go To Last Post
41 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am a hobbyist considering switching from Mega to Xmega. Obviously the hardware is different, but if I fire up CodeVision and start programming like I do with a Mega, what issues am I likely to encounter? How seamless is the transition? I suppose it depends on the complexity of the project?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a hobbyist one of the first differences you will notice is that the Xmegas don't come in PDIP packages.

Not really a problem, however, if you have already made the transition to surface mounted components.

There are a number of differences, but no insurmountable hurdles. You will quickly realize there are more options for the I/O pins. You can't lock yourself out of the chip by selecting the incorrect clock Fuse, as Xmegas always startup using one of their (many) clocks, and you then configure the clock for the source and frequency you want.

They have a priority Interrupt system, a different ADC module, a DAC module, DMA, and the Event System.

The list goes on and on, but if you tackle your projects one piece at a time its no big deal.

The Xmega E series is the newest, (and the smallest), of the Xmega series.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IMPORTANT! Xmegas only work up to 3.6V, no 5V versions. Oh and the ADC is a pain. :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
IMPORTANT! Xmegas only work up to 3.6V, no 5V versions. Oh and the ADC is a pain. :?

Can you elaborate on the ADC? Why is it a pain? Will the code that I currently use for my Atmega32 ADC stuff not work for it?

Also, I see that some Megas have a picopower feature - how does this compare to the picopower features on the Xmegas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lavadisco wrote:
Will the code that I currently use for my Atmega32 ADC stuff not work for it?
None of the low-level code will work as is. Devices have completely different peripherals.

On the other hand, I find Xmega ADC quite nice.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Can you elaborate on the ADC? Why is it a pain? Will the code that I currently use for my Atmega32 ADC stuff not work for it?

Besides the two additional bits the xmega adc has somewhat different operating modes from the mega, and due to the nature of the silicon just plan from the beginning to do offset and gain calibration in your system. This will help you extract the best performance. Your existing code can work with appropriate adc setup register and flag changes. Read the adc section of the manual carefully.

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Will the code that I currently use for my Atmega32 ADC stuff not work for it?
When you start using the Xmegas the only usable knowledge you can use from the AVRs it the Atmel logo and R0-R31, nothing else!

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

John, this is your opinion regarding the Xmegas, and in my opinion, switching from megas to Xmegas is not hard at all !

lavadisco, a few things to help you start:
- You'll need 2 datasheets instead of 1: the first one being the "Xmega family" datasheet (i.e. Xmega AU Manual), which describes all the modules and the registers that this family has, the second one being the actual device datasheet (i.e. Xmega128A1U datasheet), which describes the pinout, the modules available for that particular chip, the memory organization and the electrical characteristics.
- As John (js) said, be careful that you can only use 3.6V max as a power supply.
- As alexru said, all the low level stuff will have to be rewritten, since it's a different architecture.
- I would add to Tom (tpappano)'s post that you cannot use Vcc as Vref for the ADC. Vref HAS to be at max. Vcc - 0.7V

I repeat, there is a small learning step, but your actual knowledge is not wasted.

And do take a look at the application notes on the Atmel website, there is a nice collection of application for each module with examples and source code, I found them very useful to begin with.

Have a nice day,
Kraal

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, I switched a few years ago and it was pretty easy. The new architecture is very nice, the datasheets mostly clear and easy to work with.

Get yourself a JTAGICE3 for debugging is my tip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I am a hobbyist considering switching from Mega to Xmega.

Interesting choice - why do you pick Xmega and not SAM D2x/SAM3/SAM4 which would appear to be the "step up" with more of a future?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can SAM really be compared to XMEGA though? In terms of low power operation, ease of use, suitability for certain tasks like precise instruction timing, fast wake up/interrupt response etc?

I'm asking, because when I looked briefly at them a while back they didn't meet my low power requirements, but it wasn't an in-depth study.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This:

www.arm.com/files/pdf/Cortex-M0_...

Says 11.2uW/MHz, not sure how the Xmega compares? I guess that figure implies 3.4uA at 3.3V for 1MHz?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For compute/milliamp ARM Cortex-M is better than XMEGA and the RF megaAVR; not a huge difference but a significant difference.
Not all applications are compute bound.
Otherwise, some posts on this forum show some advantages for XMEGA.
One reliability advantage for XMEGA is it has no core voltage regulator.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
this is your opinion regarding the Xmegas, and in my opinion, switching from megas to Xmegas is not hard at all !
Of course it's my opinion and I didn't say that the Xmegas were bad or anything about being hard to switch. I said
Quote:
When you start using the Xmegas the only usable knowledge you can use from the AVRs it the Atmel logo and R0-R31, nothing else!
which was my experience after having used the 90Sxxx, Megas and Tinys for almost 15 years. And the bit about the registers is only useful if you need to work with assembler.

So to help out the OP and maybe me to see things clearly can you please explain the similarities between, say the Mega 32 which the OP knows and any of the Xmegas? ie

Chip programming
Fuses
Clock management
I/O management and use (set up, read, writing etc.)
Timers
ADC
EEPROM (not used myself in Xmegas)
Other peripherals

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
So to help out the OP and maybe me to see things clearly can you please explain the similarities between, say the Mega 32 which the OP knows and any of the Xmegas? ie

Instruction set? 8)

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Instruction set?

Irrelevant for C.
I guess if all the peripherals are different, the fact that the core CPU is similar is relatively meaningless.
The compiler will be the same, and have the same bugs/features...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Instruction set?
Yep, that's one great thing about it, I was able to port maybe 90+% of my 7K ASM project to the Xmegas...well once I pulled my last few strands of hair trying to understand the rest of the chip. :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi John,

I didn't mean to sound aggressive. I felt that, given that you are a "superfreak" with more than 22k posts, your opinion is perhaps more listened to. And when you say that almost all the usable knowledge of OP is not applicable, that may stop her/him from going further.

I find the Xmega very pleasant to work with. New features like the event system (direct peripheral to peripheral interaction), the DAC, the DMA, etc... can simplify the program flow. Now I'll try to answer some of the points you asked (but I'm not a Xmega expert).
Chip programming: ISP is replaced by PDI, which use only 2 wires (instead of 4 with ISP). On some Xmegas, you can also have JTAG. For accessing memories from firmware (i.e. bootloader, or read a LUT from flash, or even EEPROM), you'll have to use the NVM (Nonvolatile Memory) controller.
Fuses: what about them ? it works the same way as a mega.
Clock mgmt: There are more possibilities with the Xmegas, and since they always start on their internal 2Mhz clock, you can't brick them with a bad fuse setting (maybe with the BOD, I'm not sure). You have 3 prescaler stages to dispatch the clock to different peripheral. One thing that bothers me is that you can't clock a timer (PWM) from a higher speed than sysclock (unless you use the resolution expander, but sometimes you just want to go faster and don't want a better resolution).
I/O: on the mega you have DDR for direction, PORT for output and PIN for input. On the Xmega, DDR is replaced by PORTx.DIR (it works exactly the same), but you have 3 more registers which are PORTx.DIR(SET/CLR/TGL) to respectively set, clear and toggle the specified pin (i.e. PORTC.DIRSET = PIN6_bm; // Set PC6 as output). PORT is replaced by PORTx.OUT(-/SET/CLR/TGL) and PIN is replaced by PORTx.IN.
The timers have better functionnality compared to a mega, the ADC is faster with better resolution.

For the rest of the peripherals, of course OP will have to dig in the family manual and the application notes, just like he did when he started with the mega32. More or less it's the same, you set up your peripheral by writing values to the according registers. The name will differ and there will be more registers by peripheral, but not much...
I'm not saying that you can copy/paste your mega32 code and it will work just like that, but the Atmel logo and R0-R31 is not the ONLY usable knowledge you got from working with the mega32.

And I got a captcha for my post, yay !

Have a nice day,
Kraal

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John
Can you please give examples of the last 10%
I can't see where you can get into problems?
(And yes I know that there some odd things like high low of 16bit IO needs to be read in opposite order etc.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
This:

www.arm.com/files/pdf/Cortex-M0_...

Says 11.2uW/MHz, not sure how the Xmega compares? I guess that figure implies 3.4uA at 3.3V for 1MHz?

The datasheet says it is orders of magnitude worse: http://www.atmel.com/Images/Atme...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Can you please give examples of the last 10%
Clock setting, I/O setting, ADC (a dog for my purposes but managed to get it to work satisfactorily), timers in particular the new TCC4 and TCC5 in the E5 family.

By the way the board has just gone trough AU$4,200.00 EMI/EMC tests and passed.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Wed. Aug 6, 2014 - 08:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The datasheet says it is orders of magnitude worse

Eh? I posted something about the M0+, the nearest Cortex there is to mega/xmega and you post a datasheet for an M4?

Yup I'm sure a Ferrari drinks more petrol than a Fiat 500 too ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would agree that a M0+ is nearest to an Xmega.

In terms of power consumption, you generally get best results by running at full speed for a short time and sleeping for a long time. An M4F @ 240MHz certainly takes a lot of current when running.

Yes, a 32-bit CPU is faster when doing 32-bit maths. But most MCU tasks are manipulating SFRs and GPIO ports. In which case, it does not make much difference.

You choose an MCU for the suitability and performance of its peripherals (and its price).

Returning to the subject of this thread.
The CV Wizard will look after a lot of the fiddly bits of an Xmega in much the same way as you would with a Mega.

The high-level structure of your app will be much the same whether you use Mega, Xmega, M0+, ...

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is also important: AVcc - 0.6 is the maximum limit for XMEGA ADC reference, which makes some problems (for example, when connecting 4 wire resistive touch panels).

Ozhan KD
Knowledge is POWER

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It is also important: AVcc - 0.6 is the maximum limit for XMEGA ADC reference,

Is that still true? I thought that was one of the "features" of the faulty ADC in the early Xmega but now they've been replaced by USB enabled equivalents the ADC was "fixed". cf Atxmega128A1U versus ATxmega128A1 etc.

EDIT: sorry, I'm wrong, just checked 128A1U data and it still has AVcc-0.6 (why are these things always in the "other" of the two datasheets?!?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Eh? I posted something about the M0+, the nearest Cortex there is to mega/xmega and you post a datasheet for an M4?

My bad, in your previous post you mentioned the SAM4.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

My bad, in your previous post you mentioned the SAM4.

It's a trade up route: tiny->mega->xmega->M0+->M3->M4

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
In terms of power consumption, you generally get best results by running at full speed for a short time and sleeping for a long time. An M4F @ 240MHz certainly takes a lot of current when running.

It really depends if you are CPU or peripheral bound. In any case running at high speed can often compromise your sleep mode by requiring a lot of current, and thus necessitating a more capable power supply which probably won't be as efficient at low load.

High speeds usually need higher supply voltages as well, so if you can keep the speed down you more than make up for the extra on time.

As an example a produce I designed uses the ADC to take 100 samples per second. To reduce power as much as possible it powers the ADC down between samples. Actually each sample is 5 measurements averaged. Anyway, current consumption was too high, around 3.5mA with a 250KHz clock at 3.6V. I put in a 2.7V regulator with 0.5uA quiescent current. Idle current was unchanged (~2uA) but during sampling I was down to 1.7mA. I could have gone lower if it were not for the need to use a 2.048V ADC reference and 0.6V overhead for AVCC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I forgot one thing XMEGA don't have registers memory mapped.
So some general routines don't work :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi sparrow2, can you please explain what you meant by registers memory mapped ?

Have a nice day,
Kraal

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If Z point to 16 (R31=0 R30=16) the instruction

Ld r24,Z

will do the same as

mov r24,r16

But you can't do that on a Xmega (and tiny's with only 16 registers).
And that can really bloat the code size if you make many general functions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, thank you for the explanation. Is it something you use only in asm, or also commonly in C ?

Have a nice day,
Kraal

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Ok, thank you for the explanation. Is it something you use only in asm, or also commonly in C ?

C has it's own idea of how registers will be accessed so that kind of "trick" is only for Asm code. Of course you can link to .S files in C and you can even inline asm() in the C code but if you do that you must work within the bounds of the compilers own rules about register usage (the so called ABI - Application Binary Interface) so you generally don't do stuff like that in a C program unless there's some critical core loop where you must get the best performance possible (like DDS or video generation or something).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK thanks Cliff.

Have a nice day,
Kraal

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use it in ASM.
It's bad that the compiler don't use it. It should for something like -Os so the code could be smaller.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It's bad that the compiler don't use it.

I don't get it. You are suggesting it's used to replace:

 mov r24,r16 

but that's already 1 word and 1 cycle - how can it be "better" than that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it's not general!
What I showed was just to explain it to Kraal.
and yes this is to simple.
-Os is about small code not fast, I hate to see code like this:

; i++;
LDS r24,low
LDS r25,high
ADIW r24,1
STS low,r24
STS high,r25

18 byte of code (it's fine for -O2 10 clk).
It should be something like this:

i++;
LDI ZL,low(&low)
LDI ZH,high(&low)
Rcall plusplus

8 byte but yes 19clk. (and 12 byte one time only)

Ok that don't explane the "mov r24,r16" before you have functions you pass pointers, and here you can pass something placed in registers.

Add
And it really make a difference if you have 32 bit calcluations.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

electronic.designer wrote:
It is also important: AVcc - 0.6 is the maximum limit for XMEGA ADC reference, which makes some problems (for example, when connecting 4 wire resistive touch panels).
I have also found the Mega ADC was inaccurate when measuring voltages close to AVCC. Am I the only one?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How can you measure something higher than Vref (since Vref HAS to be at maximum AVcc - 0.6V)?

Or were you talking about Vref ?

Have a nice day,
Kraal

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I am a hobbyist considering switching from Mega to Xmega.

What a tough crowd!

I say give it a try!

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kraal wrote:
How can you measure something higher than Vref (since Vref HAS to be at maximum AVcc - 0.6V)?
I was talking about Mega, not Xmega. I should have made that clearer.