Add AVR64DAnnS, AVR32DAnnS and AVR32SDnn

[stefanrueger]

This PR

• Adds UART info to avrintel.c
• Updates avrintel.c from ATDF files
• Updates variants in avrdude.conf from ATDF files
• Adds AVR64DA28S, AVR64DA32S, AVR64DA48S and AVR64DA64S
• Adds AVR32DA28S, AVR32DA32S and AVR32DA48S
• Adds AVR32SD20, AVR32SD28, AVR32SD32

The last one addresses #1952

@askn37 Are you available for review?

[askn37]

No changes were found that would cause any problems.

[stefanrueger]

Thanks @askn37 for looking at this!

I am unclear about hvupdi_variant and what it should be for SD parts. This variable is not well documented, neither in the source code nor in the tex documentation. It used to have values 0, 1 or 2. I think(!) the HV_IMPLEMENTATION variable in the .atdf corresponds to hvupdi_variant in avrdude.conf. I quickly reviewed what AVRDUDE uses and what the .atdfs say and came up with the following differences:

Part	avrdude	.atdf
atmega1608	0	1
atmega1609	0	1
atmega808	0	1
atmega809	0	1
avr32sd20	2	3
avr32sd28	2	3
avr32sd32	2	3

The ATmega(16|8)0(8|9) entries may well be an error (@MCUdude can you confim?) and we can fix that here or in a dedicated PR, but what is hvupdi_variant 3? And how does that affect the use of avupdi_variant in AVRDUDE?

[stefanrueger]

@janegilruud Do you know what's the significance of the new HV_IMPLEMENTATION value 3 that the new AVR32SDnn parts seem to have? Previously that parameter could only have values 0, 1 and 2. AVRDUDE implements this parameter as hvupdi_variant.

The data sheets for AVR32DU28 (hvupdi_variant = 2) and AVRSD28 (hvupdi_variant = 3) do not seem to differ wrt high-voltage UPDI rescue:

[janegilruud]

@stefanrueger, I'm sorry, but I don't. I don't work at Microchip any more. Even though I remember the SD device were being designed, this has been introduced after I left. I'm sure @mraardvark can answer, or I'll get in touch with them and get the answer. (I know where they live ;-) )

[janegilruud]

Apparently Type 3 has some new type of handshake. As I thought @mraardvark has the details, but he's in a different timezone right now.