[En-Nut-Discussion] Support for Atmel ATxmega128A1
Bengt Florin
bengt at florin.se
Fri Feb 26 11:34:36 CET 2010
Dear all,
I have been working with the xmegas some time now and I must say that the
differences are mainly on the onboard peripherals. The performance and
structure of peripherels are quite impressive. As Ulrich says you now can do
both DMA and use the new 'event handling system' to further reduce CPU
overhead in some cases. That said I still think 'normal' use of both main
and background tasks will be around for some time. Another nice new feature
is the possibility to have prioritized interrupts. Three levels is what we
get now.
As for avr-gcc, things work as usual. Although not all xmegas are supported
by today and an annoying difference exists between Linux(Ubuntu 9.10) and
Win(WinAVR 20100110)releases even is they has the same avr-gcc version
(4.3.3).
For porting from mega all interrupt vectors are different and all code that
handles internal peripherals must be rewritten or revised. This should
anyhow not be too hard to do.
However, when porting to one xmega is done, porting to all xmegas are done
at the same time. All xmegas share the same structure of peripherals,
although they may contain different number of peripherals of course.
As for avr-libc, this should also be faily compatible for xmegas. Some
functions may still need to be implemented. I'm not sure whether support for
eeprom, boot loader and sleep is 100% complete as I haven't had time to use
them yet. This is anyhow no real problem as you can always access the
registrers directly and do what you want.
You can connect huge amounts of external RAM to the larger xmegas. Both SRAM
and SDRAM may be used. Today avr-gcc does NOT support access to more than
64KB RAM. You can always access more by usage of own code (We are talking
assembler here) that manipulates RAMPZ the get the full 24-bit address
range. Release schedule for avr-gcc talkes about 24-bit pointers for
releases 4.4 or 4.5, so it will most likely not be ready in near future. The
other compilers (icc & IAR) seem to manage 24-bit pointers already.
The normal AVRISP mk-II (the USB i.e.) programs the xmegas. I did have some
problem with avrdude, as you need the latest version to make it work. The
version bundled in Ubuntu 9.10 is way to old. Later AVRStudio works on the
other hand excellent, but do not try to run it under Wine.
If you want to play with xmegas be aware of the XPLAIN board from Atmel. It
does NOT have the 6-pin AVRISP compatible connector. You have to make you
own adapter cable which is really annoying and almost impossible for a
SW-guy. I instead recommend the Olimex board PX128A1. Pricing is about the
same, some 40-50Euro.
Xmegas are the future of 8-bit controllers and pricing seems to be lower
than for corresponding megas. I would not recommend new designs with plain
old megas if you don't need some of the variants with peripherals not
available in xmegas today, e.g. CAN etc.
So shortly said, if you like the megas, you gonna love the xmegas.
No, I'm not supported by Atmel.
Best Regards,
/bengt florin
-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Ulrich Prinz
Sent: den 25 februari 2010 21:02
To: Ethernut User Chat (English)
Subject: Re: [En-Nut-Discussion] Support for Atmel ATxmega128A1
Hi!
The difference in programming XMega compared to Non-X-mega is not the
language or the compiler, its the way of programming.
The Xmegas offer a very interesting DMA and interrupt implementation
together with a highly configurable I/O interface. This offers a programmer
to write more or less totally reactive structures.
Or as an example: If you normally programmed a main() that starts things
that request and activate things by running in a loop, an Xmega does require
a main() only for some chip and I/O setup. The rest of the software is
programmed as interrupt routines together with sort of pipes that shift data
between the interfaces via DMA. It's a bit like a DSP works. I like the way
but it's not everyones way.
But you can use the AVRX like any other AVR but you'll have to implement the
new init for all the periphals, as you need to assign GPIO ports to them.
I do not have any of these chips, but was on a training for them, so I had a
short glimpse into the new system. Looks interesting, but before one and a
half year there where almost no chips available. May be I order some for my
SDK600 after all these expositions are over.
Best regards, Ulrich
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
More information about the En-Nut-Discussion
mailing list