As Microchip introduces new AVR families, they seem to follow now the
scheme to have "AVR", the number of KiB flash, two letters, and the
number of pins of the device. Extend the regular expression to match
these (and thus also future devices) when displaying the device
selection groups.
AVR-LA devices have 10 fuses, yet the GUI so far only had entries for
(up to) 9 fuses. Thus, selecting an AVR-LA device, it eventually
threw an exception for trying to touch GUI elements that don't exist.
The GUI device selection dialog roughly classifies individual
AVRs, to allow restricting the selection box. For the new
AVR-LA devices, it makes sense to group them to the AVR-D* and
AVR-E* devices, instead of falling back to "Other".
The cleanliness and consistency of avrdude.conf owes much to AVRDUDE's
ability to print its own understanding of avrdude.conf entries using
developer options -c*/s and -p*/s.
Unfortunately, comments around memory entries are lost when using these
options, so it's better to not put them into the configuration.
The type component of the programmer structure can be, and on a number of
occasions has been, confused with the type component of the avrdude.conf
file. The latter is solely used to set the initpgm component. The former
is an internally used structure component that the user does not see.
Hence it is justified, and desirable, to rename the type component of the
programmer to avoid future confusion.
The type component of the programmer is set at runtime. As such it does
not need to be part of the raw dump of the configuration values for the
developer option -c*/r. As the type component is not used in the raw dump,
the removed code does not serve a purpose.
The automatically generated log files are only ever a starting point for
more investigation. The -vv verbosity seems just right for this. Then the
log file can serve better to make an informed decision whether or not to
raise an issue.
