[avr-libc-dev] AVR models decoded

[George Spelvin]

Georg-Johann Lay wrote:
> gcc sources provide a good overview of features per core, cf.

Yes, I found that and have turned it into some notes about the
differences.  I intend to combine them with my earlier avr-tiny/avr1
notes into something useful.

But basically, there are two dimensions of memory size and "features".

Memory size is somewhere along the following axis.  I'm conflating ROM
and RAM sizes because it's almost a combined order (with xmega5 being
the exception):

- If a device has <= 128 bytes of RAM, then the pointer registers
  are only 8 bits wide.  SPH is not implemented, and the high bytes of
  X, Y and Z are ignored.  (This is flagged with __AVR_SP8__, or
  its compllement __AVR_HAVE_SPH__.)
  - (This is not the same as -mtiny-stack, which is purely a software
    convention that the stack will be restricted to a single 256-byte
    page, meaning that stack pointer manipulation need not propagate
    carries.)
- Devices with <= 8K of ROM only have the RJMP and RCALL instructions.
  Devices with >= 16K of ROM implement 2-word JMP and CALL.
  (And define __AVR_HAVE_JMP_CALL__)
  (Add verbiage about skip bug here.)
- Devices with <= 64K of ROM only have LPM.  Devices with >= 128K
  of ROM implement the RAMPZ register and ELPM instruction.
  (__AVR_HAVE_ELPM__, and maybe __AVR_HAVE_ELPMX__)
- Devices with <= 128K of ROM have 2-byte PCs and only have IJMP/ICALL.
  Devices with >= 256K of ROM have 3-byte PC registers (use more stack
  and take more time during CALL), and implement the EIND register and
  EIJMP/EICALL instructions.
  (__AVR_3_BYTE_PC__, __AVR_HAVE_EIJMP_EICALL__)
- Devices with <= 64K of RAM (almost all of them) do not implement
  RAMPX/RAMPY/RAMPD.  Devices with > 64K of RAM (only xmega5 and xmega7,
  using their external memory interfaces) implement those registers,
  which provide the high address bits to load-store instructions.

Features go along the second axis.  Each level includes all of the
features of the levels before.

- The "classic" models (avr2 and avr3) do not have MOVW and only have
  the zero-argument form of LPM (= LPM r0,Z).  Note that classic models
  with ELPM do exist (avr31).
- The first enhancement is __AVR_HAVE_LPMX__ and __AVR_HAVE_MOVW__
  (which are actually synonyms).  The MOVW and LPM Rd,Z(+) instructions.
  And, if >64K of ROM, the corresponding ELPM instructions.
  (These are avr25, avr35, and avr4+).
- The second enhancement is multiply support.  (Called __AVR_HAVE_MUL__
  and __AVR_ENHANCED__.)  Multiply support implies MOVW/LPMX support.
- The third enhancement is the XMEGA features.  For software, the
  main issues are:
  - Register file is no longer memory-mapped.
  - Greatly enlarged I/O port range
  - Stack pointer writes don't need to disable interrupts; writing the
    low half disables interrupts for 4 cycles.
  - CCP register to lock important configuration from unwanted change.
  - Some instructions take one cycle less.
- The fourth is the XMEGA RMW instructions.  Not all XMEGA models have
  these, so they're indicated with a separate -mrmw flag.

Here's the chart that makes it all clear:

                Classic +MOVW   +MUL    +XMEGA  +RMW
<= 128 RAM      (-msp8)
<= 8K ROM       avr2    avr25   avr4
16K..64K ROM    avr3    avr35   avr5    xmega2
128K ROM        avr31           avr51   xmega4
>= 256K ROM                     avr6    xmega6
> 64K RAM                               xmega7  (-mrmw)

xmega5 is xmega4 plus the >64K RAM features, but not the >= 256K ROM
features.

(And attiny40 is its own special brand of perverse.)