avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] -mmcu=avrxmega confusion


From: Georg-Johann Lay
Subject: [avr-gcc-list] -mmcu=avrxmega confusion
Date: Mon, 20 Feb 2012 14:09:41 +0100
User-agent: Thunderbird 2.0.0.24 (X11/20100302)

At current, avr-tools' xmega core <-> device mapping looks as follows:

binutils:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-avr.c?rev=1.79&content-type=text/x-cvsweb-markup&cvsroot=src

gcc:
http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr-mcus.def?revision=184269&view=markup
http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr-devices.c?revision=184269&view=markup

Or, in prose:

avrxmega2: ELPM=0, EIND=0, RAMPD=0
    atxmega16a4
    atxmega16d4
    atxmega16x1
    atxmega32a4
    atxmega32d4
    atxmega32x1

avrxmega4: ELPM=0, EIND=0, RAMPD=0
    atxmega64a3
    atxmega64d3

avrxmega5: ELPM=0, EIND=0, RAMPD=1
    atxmega64a1
    atxmega64a1u

avrxmega6: ELPM=1, EIND=1, RAMPD=0
    atxmega128a3
    atxmega128b1
    atxmega128d3
    atxmega192a3
    atxmega192d3
    atxmega256a3
    atxmega256a3b
    atxmega256a3bu
    atxmega256d3

avrxmega7: ELPM=1, EIND=0, RAMPD=1
    atxmega128a1
    atxmega128a1u

Could someone explain this to me?
For the compiler's perspective, devices are filed under core architectures that
differ in instruction set architecture (ISA) or special function register (SFR)
layout like address of SREG.

xmega all have the same SFR addresses -- at least as far as only addresses are
concerned which the compiler is using, for example SP or RAMPZ.

The ISA decomposes on the basis of availability of the following instructions
and SFRs:

EIJMP/EIND, ELPM, JMP, RAMPD

Other instructions like MUL, MOVW don't matter here because all xmega ISA
support them.

JMP, ELPM, EIJMP depend only on the flash size and there are the implications

EIJMP => ELPM => JMP

so that in the (EIJMP, ELPM, JMP, RAMPD) quadruple only the following elements
are of interest:

(EIJMP, ELPM, JMP, RAMPD) = (0, 0, 0, 0)
(EIJMP, ELPM, JMP, RAMPD) = (0, 0, 0, 1)

(EIJMP, ELPM, JMP, RAMPD) = (0, 0, 1, 0)
(EIJMP, ELPM, JMP, RAMPD) = (0, 0, 1, 1)

(EIJMP, ELPM, JMP, RAMPD) = (0, 1, 1, 0)
(EIJMP, ELPM, JMP, RAMPD) = (0, 1, 1, 1)

(EIJMP, ELPM, JMP, RAMPD) = (1, 1, 1, 0)
(EIJMP, ELPM, JMP, RAMPD) = (1, 1, 1, 1)

Currently there are no devices with <= 8 KiB if flash so that the 2
combinations 0000 and 0001 are not needed.

However, the current mapping from above is

0010:
avrxmega2: ELPM=0, RAMPD=0, EIND=0
    atxmega16a4
    atxmega16d4
    atxmega16x1
    atxmega32a4
    atxmega32d4
    atxmega32x1

0010:
avrxmega4: ELPM=0, EIND=0, RAMPD=0
    atxmega64a3
    atxmega64d3

0011:
avrxmega5: ELPM=0, EIND=0, RAMPD=1
    atxmega64a1
    atxmega64a1u

1110 and 0110:
avrxmega6: ELPM=1, EIND=0/1, RAMPD=0
    atxmega128a3
    atxmega128b1
    atxmega128d3
    atxmega192a3
    atxmega192d3
    atxmega256a3
    atxmega256a3b
    atxmega256a3bu
    atxmega256d3

0111:
avrxmega7: ELPM=1, EIND=0, RAMPD=1
    atxmega128a1
    atxmega128a1u

Enumerating the quadruples starting at 0 we have:

avrxmega0 = (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 0, 0)
avrxmega1 = (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 0, 1)

avrxmega2 = (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 1, 0)
avrxmega3 = (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 1, 1)

avrxmega4 = (EIJMP, ELPM, JMP, RAMPD) = (0, 1, 1, 0)
avrxmega5 = (EIJMP, ELPM, JMP, RAMPD) = (0, 1, 1, 1)

avrxmega6 = (EIJMP, ELPM, JMP, RAMPD) = (1, 1, 1, 0)
avrxmega7 = (EIJMP, ELPM, JMP, RAMPD) = (1, 1, 1, 1)

And thus the following mapping:


0010:
avrxmega2: ELPM=0, EIND=0, RAMPD=0
    atxmega16a4
    atxmega16d4
    atxmega16x1
    atxmega32a4
    atxmega32d4
    atxmega32x1
    atxmega64a3
    atxmega64d3

0011:
avrxmega3: ELPM=0, EIND=0, RAMPD=1
    atxmega64a1
    atxmega64a1u

0110:
avrxmega4: ELPM=1, EIND=0, RAMPD=0
    atxmega128a3
    atxmega128b1
    atxmega128d3

0111:
avrxmega5: ELPM=1, EIND=0, RAMPD=1
    atxmega128a1
    atxmega128a1u


1110:
avrxmega6: ELPM=1, EIND=1, RAMPD=0
    atxmega192a3
    atxmega192d3
    atxmega256a3
    atxmega256a3b
    atxmega256a3bu
    atxmega256d3

avrxmega0/1/7: empty

The current device core assignment allows code like
void foo0 (void) {}

void (*pfoo)(void) = foo0;

int main()
{
    pfoo();
    return 0;
}

to be compiled

avr-gcc eijmp.c -o eijmp.elf -mmcu=atxmega128a3 -save-temps -dp -Os

and the compiler emit EICALL and the elf disassembly reads

00000220 <main>:
 220:   e0 91 00 20     lds     r30, 0x2000
 224:   f0 91 01 20     lds     r31, 0x2001
 228:   19 95           eicall
 22a:   80 e0           ldi     r24, 0x00       ; 0
 22c:   90 e0           ldi     r25, 0x00       ; 0
 22e:   08 95           ret

which is not what I'd expect for a device with <= 64 Ki words flash.

Obviously there is some device/core/ISA/avrxmega(n) confusion throughout the
tools that must be resolved.

Thoughts?

Johann



reply via email to

[Prev in Thread] Current Thread [Next in Thread]