Xmega - Atmega peripheral compatibilty

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

I am currently trying to port an application developed with gcc for ATmega 644, to an XMega 192A3.
I have to say that I am a bit disapointed by the peripherals compatibility: many macros definitions for peripherals use are different. For instance, TCCR0 for timer does not exist on XMega, same for SPE for SPI, etc...
Is there any chance to find somewhere a guide to port an existing avr application to XMega ?
Any hint,
Thanks
Olivier

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

A M644 has a maximum of 256 I\O registers etc. The Xmega 128A1 has 3008...just to give you an idea of the difference.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I don't know of any guide beyond the datasheet. Some of the peripherals have quite different behavior, making a hack+slash port problematic. Interrupts are redone (multi-level), there are numerous USART and SPI modules now, not counting the general memory map changes.

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

I agree that there are many new features in Xmega.

But who can do the most, can do the less. I don't see why there is no compatibility layer or API between both architecture.
To port an existing application, if there is much to rewrite, then the benefit of moving from one 8-bits arch to 8-16 bits is fairly low. Better move to 32 bits architecture in that case.
Disapointed.
Olivier

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

Quote:

I don't know of any guide beyond the datasheet.

Unlike the original AVRs the X datasheets do not contain much in the way of example code but Atmel appears to have put in more work in the app notes to balance this:

http://www.atmel.com/dyn/Product...

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

For me it makes a lot more sense the way they layout the registers, only the other day I went back and developed for a mega mpu after 6 months of developing for xmega and found myself thinking the xmega peripherals are simpler in implementation. Unfortuately there are differences in the peripherals that enhance them but also increases the complexity in setup.
After porting a lot of code I have found that after the setup routines are adapted there is little difference for direct data access (discounting DMA). Worth the agro for me and there are a lot of appnotes that cover pretty much everything.

John.

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

Has anyone define some examples or some mapping for the use of XMega peripheral ?
That could greatly help and speed up the porting of an application from Atmega. Basic things such as timer, serial, adc to start would be nice...
Olivier

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

You have to decide whether you want some portability across Mega and Xmega. It is fairly inevitable that the initialisation is more complex with the xmega. e.g. there are more registers and you have to set port_pin directions etc.

But bog-standard operations can often be handled with normal macros:

#define SPIPORT		PORTD.OUT
#define SPIDDR		PORTD.DIR
#define SPDR		SPID.DATA
#define SPSR		SPID.STATUS
#define SPCR		SPID.CTRL

You will find that the basic operation of a Mega always has a xMega equivalent. But of course the sfr_name and bit_names change.

David.

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

thanks david, it helps.
There are some other defines that I had error with when compiling for the Xmega (i am doing this from memory so it is may be inacurate):

 
   SPIE  /* SPI Interrupt Enable */
   DORD  /* Data Order: MSB first */
   CPOL  /* Clock Polarity: SCK low when idle */
   CPHA  /* Clock Phase: sample on rising SCK edge */
   SPR1  /* Clock Frequency: f_OSC / 128 */
   SPR0
   SPI2X /* doubled clock frequency */

   TCCR0A /* timer stuff */
   TCCR0B 
   WGM01
   OCR0A   
   TIMSK0

Olivier

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

Olivier,

You have to read the Xmega data sheets. And download all the Xmega app notes.

The initialisation is VERY different. But at a guess you are setting up a SPI Master, and wanting a regular CTC Timer0 IRQ.

So the actual "working" code is probably just writing to SPDR and reading a Slave's response. And your Timer ISR() is identical. Just has a different vector name. And you can use the TCC0.PER register + TC0_OVF_vect rather than using TIM0_COMPA_vect'

If you are using the Compare registers, there are A,B,C,D and a lot more functionality.

David.

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

Yes, that's the problem,
I have to read each application notes, run the example (or port it when not under gcc), understand it, make it work as needed, and finally port it to my software. It takes a lot of time. And the next time I will change the architecture, I will have to do that again.
That's a shame that Atmel doesn't make Atmega with 32 K sram, and with ADC 12bits, that would have been enough for my application...

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

The app notes include Driver routines. You should be able to do the initialisations via these drivers.

I think that a learning curve is inevitable. Only you know the likely requirements of your future projects. I am sure that there will be a steady "enlargement" of AVR resources. However this will take some years.

But you may find it worth starting off on the ARM Cortex-M3 route. These devices will be in production for some years in some form or another. One learning curve.

David.