…on -p \*

  -p \*/c  check address bits in SPI commands
  -p \*/d  description of core part features
  -p \*/o  opcodes for SPI programming parts and memories
  -p \*/s  show avrdude.conf entries of parts
  -p \*/ss show full avrdude.conf entry as tab separated table
  -p \*/w  wd_... constants for ISP parts
  -p \*/\* all of the above except -p \*/s
  -p \*    same as -p\*/\*

When an SPI command has a lone 'a' the initialisation now is as would be
expected by all commands that take an address. Atmel's opcodes for SPI
programming are consistent in this respect. This commit makes specifying
the bit number in avrdude.conf optional. Instead of

 read_lo = "0 0 1 0 0 0 0 0  0 0 a13 a12 a11 a10 a9 a8  a7 a6 a5 a4 a3 a2 a1 a0  o o o o o o o o";

one can now use

 read_lo = "0 0 1 0 0 0 0 0  0 0 a a a a a a  a a a a a a a a  o o o o o o o o";

… = NULL;

This commit changes the philosophy whenever avrdude.conf encounters the
same memory of a part for the second time or whenever a memory is
described that, through inheritance, already existed: AVRDUDE no longer
zaps the memory, it rather extends it.

Therefore, avrdude.conf.in's entry for ATmega128RFA1, which inherits from
the ATmega2561, needs a line `load_ext_addr = NULL;` in its flash memory
description to zap the inherited load_ext_addr SPI command.

Other than this, avrdude.conf.in needs no other change in order to effect
the same internal representation proving earlier updates to the .conf.in
file correct that manually ensured inheritance of memory contents.

As the address bit numbers in the SPI opcodes are highly systematic, they
don't really need to be specified. Each bit can therefore be described as one
of the characters 0 (always 0), 1 (always 1), x (don't care, but will be set
as 0), a (a copy of the correct bit of the byte or word address of read,
write, load, pagewrite or load extended address command of memories with more
than one byte), i (input bit for a load/write) or o (output bit from a read).
The bits therefore do not need to be individually separated.

If a string in the list of strings that describe an SPI opcode does *not*
contain a space *and* is longer than 7 characters, it is interpreted as a
compact bit-pattern  representation. The characters 0, 1, x, a, i and o will
be recognised as the corresponding bit, whilst any of the characters ., -, _
or / can act as arbitrary visual separators, which are ignored. Examples:

  loadpage_lo = "0100.0000--000x.xxxx--xxaa.aaaa--iiii.iiii";

  loadpage_lo = "0100.0000", "000x.xxxx", "xxaa.aaaa", "iiii.iiii";

  loadpage_lo = "0100.0000", "000x.xxxx.xxaa.aaaa", "iiii.iiii";

  loadpage_lo = "0100.0000-000x.xxxx--xxaa.aaaa-iiii.iiii";

  loadpage_lo = "0100.0000/000x.xxxx/xxaa.aaaa/iiii.iiii";

The compact format is an extension of the current format, which remains
valid. Both, the compact and the traditional specification can be mixed in
different strings, albeit not in the same string:

  load_ext_addr = "0100.1101", "0000.0000.0000", "0 0 0 a16", "0000.0000";

…ii.iiii"

…ndaries

The function avr_set_addr_mem(AVRMEM *mem, int opnum, unsigned char *cmd,
unsigned long addr) is meant to replace avr_set_addr(OPCODE *op, unsigned
char *cmd, unsigned long addr) in future.

avr_set_addr_mem() has more information about the context of the task in that
it knows the memory size, memory page size, whether or not the memory is a
flash memory (which gets words addressees supplied) and, crucially, knows
which SPI operation it is meant to compute the address bits for.

avr_set_addr_mem() first computes the interval of bit numbers that must be
supplied for the SPI command to stand a chance to work. The function only
sets those address bits that are needed. Once all avr_set_addr() function
calls have been replaced by avr_set_addr_mem(), the SPI commands that need an
address can afford to declare in avrdude.conf all 16 address bits in the
middle two bytes of the SPI command. This over-declaration will be corrected
during runtime by avr_set_addr_mem(). One consequence of this is that parts
can inherit smaller or larger memories from parents without the need to use
different SPI codes in avrdude.conf. Another consequence is that
avr_set_addr_mem() can, and does, tell the caller whether vital address bits
were not declared in the SPI opcode. During parsing of avrdude.conf this
might be utilised to generate a corresponding warning. This will uncover
problematic SPI codes in avrdude.conf that in the past went undetected.

… size_t

…for c/make