This is the mail archive of the
mailing list for the GCC project.
Re: [Patch,AVR] Add xmega support
Weddington, Eric schrieb:
This patch adds support for xmega cores and does the following:
Please commit. And thanks! :-)
As I wrote, the device <-> core assignments are the same as in
which I don't understand. The assignments are:
avrxmega2: ELPM=0, RAMPD=0, EIND=0
avrxmega4: ELPM=0, RAMPD=0, EIND=0
avrxmega5: ELPM=0, RAMPD=1, EIND=0
avrxmega6: ELPM=1, RAMPD=0, EIND=0/1
avrxmega7: ELPM=1, RAMPD=1, EIND=0
* xmega2 and xmega4 are duplicates of each other
* xmega6 mixes devices with EIND (>128 KiB Flash)
with non-EIND (<= KiB Flash) devices.
There are 8 combinations in the ELPM x RAMPD x EIND
cross product. As EIND implies ELPM, 6 combinations remain:
ELPM=0, RAMPD=0, EIND=0 -> xmega2 = xmega4
ELPM=0, RAMPD=1, EIND=0 -> xmega5
ELPM=1, RAMPD=0, EIND=0 -> xmega6 *clash*
ELPM=1, RAMPD=0, EIND=1 -> xmega6 *clash*
ELPM=1, RAMPD=1, EIND=0 -> xmega7
ELPM=1, RAMPD=1, EIND=1 -> ---
Can you shed some light on that?
The current non-xmega architectures assume that only
devices with the same amount of flash segments are
present in one archirecture. This is no more true with
192 KiB devices that have 3 segments and are in the same
arch with 4-segment and/or 2-segment devices.
An ISA-question: Is xmega ISA binary upward
compatible to respective non-xmega, i.e. can the
same ISA simulator be used, for example?
The patches are untested because avrtest does not
support xmega. Would you run tests and compare results
for ATmega128 against, for example ATXmega128A3?
There should be no differences and the same out-of-flash
or out-of-ram crashes.
Do you have an update for avrtest?
I had a look into it but it's complete mess because GPRs are
accessed by their RAM address and it would take some time to
clean up that mess.