search

avrdudes / avrdude

AVRDUDE is a utility to program AVR microcontrollers
GNU General Public License v2.0
704 stars 136 forks source link

Parts with *L, *PV and *V suffixes + others are missing in avrdude.conf #1092

Closed MCUdude closed 1 year ago

MCUdude commented 2 years ago

Here's a list I've generated by going through the adtf files for ATmega and ATtinys: These should probably be added to avrdude.conf.in sometime...

Missing part:   Same signature as:
ATmega1280V ATmega1280
ATmega1281V ATmega1281
ATmega128L  ATmega128
ATmega164PV ATmega164P
ATmega168PV ATmega168P
ATmega168V  ATmega168
ATmega169PV ATmega169P
ATmega16L   ATmega16
ATmega2560V ATmega2560
ATmega2561V ATmega2561
ATmega324PV ATmega324P
ATmega329PV ATmega329P
ATmega329V  ATmega329
ATmega32L   ATmega32
ATmega48PV  ATmega48P
ATmega48V   ATmega48
ATmega640V  ATmega640
ATmega644PV ATmega644P
ATmega644V  ATmega644
ATmega649V  ATmega649
ATmega64L   ATmega64
ATmega88PV  ATmega88P
ATmega88V   ATmega88
ATmega8L    ATmega8
Missing part:   Same signature as:
ATtiny13V   ATtiny13
ATtiny25V   ATtiny25
ATtiny261V  ATtiny261
ATtiny45V   ATtiny45
ATtiny461V  ATtiny461
ATtiny85V   ATtiny85
ATtiny861V  ATtiny861
MCUdude commented 2 years ago

Here's a list @stefanrueger posted in #1091. None of these are currently supported by Avrdude. Some of them may be ignored, while others should perhaps be added:

IMO we should add the ATtiny, ATmega, ATxmega, and AT90PWM parts.

//{mcu_name,       mcuid,  family, {sig,    na, ture}, flstart,  flsize, pgsiz, nb, bootsz, eestart, eesize, ep, rambeg, ramsiz, nf, nl,  ni,       isr_names}, // Source

  {"ATtiny22",          13,  F_AVR8, {0x1E, 0x91, 0x06},       0, 0x00800,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0080,  1,  1,   3,   vtab_attiny22}, // avr-gcc 12.2.0
  {"ATmega8HVA",        47,  F_AVR8, {0x1E, 0x93, 0x10},       0, 0x02000, 0x080,  0,      0,       0, 0x0100,  4, 0x0100, 0x0200,  1,  1,  21, vtab_atmega16hva}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVA",       51,  F_AVR8, {0x1E, 0x94, 0x0C},       0, 0x04000, 0x080,  0,      0,       0, 0x0100,  4, 0x0100, 0x0200,  1,  1,  21, vtab_atmega16hva}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVB",       52,  F_AVR8, {0x1E, 0x94, 0x0D},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVBrevB",   53,  F_AVR8, {0x1E, 0x94, 0x0D},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega16M1",        54,  F_AVR8, {0x1E, 0x94, 0x84},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVA2",      55,  F_AVR8, {0x1E, 0x94, 0x0E},       0, 0x04000, 0x080, -1,     -1,      -1,     -1, -1, 0x0100, 0x0400,  2,  1,  22, vtab_atmega16hva2}, // avr-gcc 12.2.0
  {"ATmega32HVB",       60,  F_AVR8, {0x1E, 0x95, 0x10},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega32HVBrevB",   61,  F_AVR8, {0x1E, 0x95, 0x10},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega32C1",        62,  F_AVR8, {0x1E, 0x95, 0x86},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega32U6",        66,  F_AVR8, {0x1E, 0x95, 0x88},       0, 0x08000, 0x080,  4, 0x0200,      -1,     -1, -1, 0x0100, 0x0a00,  3,  1,  38, vtab_atmega32u6}, // avr-gcc 12.2.0, boot size (manual)
  {"ATmega64HVE",       74,  F_AVR8, {0x1E, 0x96, 0x10},       0, 0x10000, 0x080,  4, 0x0400,      -1,     -1, -1, 0x0100, 0x1000,  2,  1,  25, vtab_atmega64hve2}, // avr-gcc 12.2.0, boot size (manual)
  {"ATmega64C1",        75,  F_AVR8, {0x1E, 0x96, 0x86},       0, 0x10000, 0x100,  4, 0x0400,       0, 0x0800,  8, 0x0100, 0x1000,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega64HVE2",      77,  F_AVR8, {0x1E, 0x96, 0x10},       0, 0x10000, 0x080,  4, 0x0400,       0, 0x0400,  4, 0x0100, 0x1000,  2,  1,  25, vtab_atmega64hve2}, // atdf, avr-gcc 12.2.0
  {"ATmega323",        109,  F_AVR8, {0x1E, 0x95, 0x01},       0, 0x08000, 0x080,  4, 0x0200,      -1,     -1, -1, 0x0060, 0x0800,  2,  1,  21,  vtab_atmega323}, // avr-gcc 12.2.0, boot size (manual)
  {"AT43USB320",       162,  F_AVR8, {0xff,   -1,   -1},       0, 0x10000,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0200, -1, -1,   0,            NULL}, // avr-gcc 12.2.0
  {"AT43USB355",       163,  F_AVR8, {0xff,   -1,   -1},       0, 0x06000,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0400, -1, -1,   0,            NULL}, // avr-gcc 12.2.0
  {"AT76C711",         164,  F_AVR8, {0xff,   -1,   -1},       0, 0x04000,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x07a0, -1, -1,   0,            NULL}, // avr-gcc 12.2.0
  {"AT86RF401",        165,  F_AVR8, {0x1E, 0x91, 0x81},       0, 0x00800,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0080,  0,  1,   3,  vtab_at86rf401}, // avr-gcc 12.2.0
  {"AT90PWM1",         166,  F_AVR8, {0x1E, 0x93, 0x83},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0200,  3,  1,  32, vtab_at90pwm316}, // atdf, avr-gcc 12.2.0
  {"AT90PWM81",        173,  F_AVR8, {0x1E, 0x93, 0x88},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0100,  3,  1,  20, vtab_at90pwm161}, // atdf, avr-gcc 12.2.0
  {"AT90SCR100",       175,  F_AVR8, {0x1E, 0x96, 0xC1},       0, 0x10000, 0x100,  4, 0x0200,      -1,     -1, -1, 0x0100, 0x1000,  3,  1,  38, vtab_at90scr100}, // avr-gcc 12.2.0, boot size (manual)
  {"AT90PWM161",       177,  F_AVR8, {0x1E, 0x94, 0x8B},       0, 0x04000, 0x080,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  20, vtab_at90pwm161}, // atdf, avr-gcc 12.2.0
  {"AT90S2323",        187,  F_AVR8, {0x1E, 0x91, 0x02},       0, 0x00800,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0080,  1,  1,   3,   vtab_attiny22}, // avr-gcc 12.2.0
  {"AT90C8534",        194,  F_AVR8, {0xff,   -1,   -1},       0, 0x02000,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0100, -1, -1,   0,            NULL}, // avr-gcc 12.2.0
  {"AT94K",            196,  F_AVR8, {0xff,   -1,   -1},       0, 0x08000,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0fa0, -1, -1,   0,            NULL}, // avr-gcc 12.2.0
  {"ATA5272",          197,  F_AVR8, {0x1E, 0x93, 0x87},       0, 0x02000, 0x080,  0,      0,       0, 0x0200,  4, 0x0100, 0x0200,  3,  1,  37,    vtab_ata5272}, // atdf, avr-gcc 12.2.0
  {"ATA5505",          198,  F_AVR8, {0x1E, 0x94, 0x87},       0, 0x04000, 0x080,  0,      0,       0, 0x0200,  4, 0x0100, 0x0200,  3,  1,  20,  vtab_attiny167}, // atdf, avr-gcc 12.2.0
  {"ATA5700M322",      199,  F_AVR8, {0x1E, 0x95, 0x67}, 0x08000, 0x08000, 0x040,  0,      0,       0, 0x0880, 16, 0x0200, 0x0400,  1,  1,  51, vtab_ata5702m322}, // atdf
  {"ATA5702M322",      200,  F_AVR8, {0x1E, 0x95, 0x69}, 0x08000, 0x08000, 0x040,  0,      0,       0, 0x0880, 16, 0x0200, 0x0400,  1,  1,  51, vtab_ata5702m322}, // atdf, avr-gcc 12.2.0
  {"ATA5781",          201,  F_AVR8, {0x1E, 0x95, 0x64},      -1,      -1,    -1,  0,      0,       0, 0x0400, 16, 0x0200, 0x0400,  1,  1,  42,    vtab_ata8515}, // atdf
  {"ATA5782",          202,  F_AVR8, {0x1E, 0x95, 0x65}, 0x08000, 0x05000, 0x040,  1, 0x5000,       0, 0x0400, 16, 0x0200, 0x0400,  1,  1,  42,    vtab_ata8515}, // atdf, avr-gcc 12.2.0
  {"ATA5783",          203,  F_AVR8, {0x1E, 0x95, 0x66},      -1,      -1,    -1,  0,      0,       0, 0x0400, 16, 0x0200, 0x0400,  1,  1,  42,    vtab_ata8515}, // atdf
  {"ATA5787",          204,  F_AVR8, {0x1E, 0x94, 0x6C}, 0x08000, 0x05200, 0x040,  0,      0,       0, 0x0400, 16, 0x0200, 0x0800,  1,  1,  44,    vtab_ata5835}, // atdf
  {"ATA5790",          205,  F_AVR8, {0x1E, 0x94, 0x61},       0, 0x04000, 0x080,  1, 0x0800,       0, 0x0800, 16, 0x0100, 0x0200,  1,  1,  30,    vtab_ata5790}, // atdf, avr-gcc 12.2.0
  {"ATA5790N",         206,  F_AVR8, {0x1E, 0x94, 0x62},       0, 0x04000, 0x080,  1, 0x0800,       0, 0x0800, 16, 0x0100, 0x0200,  1,  1,  31,    vtab_ata5791}, // atdf, avr-gcc 12.2.0
  {"ATA5791",          207,  F_AVR8, {0x1E, 0x94, 0x62},       0, 0x04000, 0x080,  1, 0x0800,       0, 0x0800, 16, 0x0100, 0x0200,  1,  1,  31,    vtab_ata5791}, // atdf, avr-gcc 7.3.0
  {"ATA5795",          208,  F_AVR8, {0x1E, 0x93, 0x61},       0, 0x02000, 0x040,  1, 0x0800,       0, 0x0800, 16, 0x0100, 0x0200,  1,  1,  23,    vtab_ata5795}, // atdf, avr-gcc 12.2.0
  {"ATA5831",          209,  F_AVR8, {0x1E, 0x95, 0x61}, 0x08000, 0x05000, 0x040,  1, 0x5000,       0, 0x0400, 16, 0x0200, 0x0400,  1,  1,  42,    vtab_ata8515}, // atdf, avr-gcc 12.2.0
  {"ATA5832",          210,  F_AVR8, {0x1E, 0x95, 0x62},      -1,      -1,    -1,  0,      0,       0, 0x0400, 16, 0x0200, 0x0400,  1,  1,  42,    vtab_ata8515}, // atdf
  {"ATA5833",          211,  F_AVR8, {0x1E, 0x95, 0x63},      -1,      -1,    -1,  0,      0,       0, 0x0400, 16, 0x0200, 0x0400,  1,  1,  42,    vtab_ata8515}, // atdf
  {"ATA5835",          212,  F_AVR8, {0x1E, 0x94, 0x6B}, 0x08000, 0x05200, 0x040,  0,      0,       0, 0x0400, 16, 0x0200, 0x0800,  1,  1,  44,    vtab_ata5835}, // atdf
  {"ATA6285",          213,  F_AVR8, {0x1E, 0x93, 0x82},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0140,  4, 0x0100, 0x0200,  2,  1,  27,    vtab_ata6289}, // atdf, avr-gcc 12.2.0
  {"ATA6286",          214,  F_AVR8, {0x1E, 0x93, 0x82},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0140,  4, 0x0100, 0x0200,  2,  1,  27,    vtab_ata6289}, // atdf, avr-gcc 12.2.0
  {"ATA6289",          215,  F_AVR8, {0x1E, 0x93, 0x82},       0, 0x02000, 0x040,  4, 0x0100,      -1,     -1, -1, 0x0100, 0x0200,  2,  1,  27,    vtab_ata6289}, // avr-gcc 12.2.0, boot size (manual)
  {"ATA6612C",         216,  F_AVR8, {0x1E, 0x93, 0x0A},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  26, vtab_atmega328p}, // atdf, avr-gcc 12.2.0
  {"ATA6613C",         217,  F_AVR8, {0x1E, 0x94, 0x06},       0, 0x04000, 0x080,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  26, vtab_atmega328p}, // atdf, avr-gcc 12.2.0
  {"ATA6614Q",         218,  F_AVR8, {0x1E, 0x95, 0x0F},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  3,  1,  26, vtab_atmega328p}, // atdf, avr-gcc 12.2.0
  {"ATA6616C",         219,  F_AVR8, {0x1E, 0x93, 0x87},       0, 0x02000, 0x080,  0,      0,       0, 0x0200,  4, 0x0100, 0x0200,  3,  1,  20,  vtab_attiny167}, // atdf, avr-gcc 12.2.0
  {"ATA6617C",         220,  F_AVR8, {0x1E, 0x94, 0x87},       0, 0x04000, 0x080,  0,      0,       0, 0x0200,  4, 0x0100, 0x0200,  3,  1,  20,  vtab_attiny167}, // atdf, avr-gcc 12.2.0
  {"ATA8210",          221,  F_AVR8, {0x1E, 0x95, 0x65}, 0x08000, 0x05000, 0x040,  1, 0x5000,       0, 0x0400, 16, 0x0200, 0x0400,  1,  1,  42,    vtab_ata8515}, // atdf, avr-gcc 7.3.0
  {"ATA8215",          222,  F_AVR8, {0x1E, 0x95, 0x64},      -1,      -1,    -1,  0,      0,       0, 0x0400, 16, 0x0200, 0x0400,  1,  1,  42,    vtab_ata8515}, // atdf
  {"ATA8510",          223,  F_AVR8, {0x1E, 0x95, 0x61}, 0x08000, 0x05000, 0x040,  1, 0x5000,       0, 0x0400, 16, 0x0200, 0x0400,  1,  1,  42,    vtab_ata8515}, // atdf, avr-gcc 7.3.0
  {"ATA8515",          224,  F_AVR8, {0x1E, 0x95, 0x63},      -1,      -1,    -1,  0,      0,       0, 0x0400, 16, 0x0200, 0x0400,  1,  1,  42,    vtab_ata8515}, // atdf
  {"ATA664251",        225,  F_AVR8, {0x1E, 0x94, 0x87},       0, 0x04000, 0x080,  0,      0,       0, 0x0200,  4, 0x0100, 0x0200,  3,  1,  20,  vtab_attiny167}, // atdf, avr-gcc 12.2.0
  {"M3000",            226,  F_AVR8, {0xff,   -1,   -1},       0, 0x10000,    -1, -1,     -1,      -1,     -1, -1, 0x1000, 0x1000, -1, -1,   0,            NULL}, // avr-gcc 12.2.0
  {"ATxmega32C3",      236, F_XMEGA, {0x1E, 0x95, 0x49},       0, 0x09000, 0x100,  1, 0x1000,       0, 0x0400, 32, 0x2000, 0x1000,  6,  1, 127, vtab_atxmega256c3}, // atdf, avr-gcc 12.2.0
  {"ATxmega32D3",      237, F_XMEGA, {0x1E, 0x95, 0x4A},       0, 0x09000, 0x100,  1, 0x1000,       0, 0x0400, 32, 0x2000, 0x1000,  6,  1, 114, vtab_atxmega384d3}, // atdf, avr-gcc 12.2.0
  {"ATtiny416auto",    290, F_AVR8X, {0x1E, 0x92, 0x28},       0, 0x01000, 0x040,  1,      0, 0x01400, 0x0080, 32, 0x3f00, 0x0100, 10,  1,  26,  vtab_attiny817}, // atdf
  {"ATtiny3214",       313, F_AVR8X, {0x1E, 0x95, 0x20},       0, 0x08000, 0x080,  1,      0, 0x01400, 0x0100, 64, 0x3800, 0x0800, 10,  1,  31, vtab_attiny3214}, // avr-gcc 12.2.0
stefanrueger commented 2 years ago

Ahh, I see the V and L suffixes do not signify different parts in the sense that ATmega328PB and ATmega328P are different parts with different pin assignments, different functionality, different ATDF files, different compiler headers, or in the sense that ATmega328 and ATmega328P are different with BOD disable only available on the 328P and different signature and different ATDF file.

The V and L suffixes signify variants of the same part with the same pin assignments, the same function blocks, the same ATDF file and the same compiler headers and the same __AVR_DEVICE_NAME__ macro, the same signature --- albeit with different Vcc or different frequency ranges.

Do they imply a difference for how AVRDUDE, the physical programmers or bootloaders can program these parts? What's the benefit of different avrdude.conf entries? What's different for the user? Might they fret over which part to specify when both ATmega2560V and ATmega2560 are on offer as different parts and they don't know what's on the board b/c the print is illegible?

If they are added at all I suggest riding close to the ATDF sheet and use the same part entry, but devise a new optional component called variants that is a list of strings that each can be specified at -p? Here an example of what I mean:

#------------------------------------------------------------
# ATmega1280
#------------------------------------------------------------

part
    desc                   = "ATmega1280";
    id                     = "m1280";
    variants               = "ATmega1280V", "ATmega1280-16AU", "ATmega1280-16CU", "ATmega1280V-8AU", "ATmega1280V-8CU";
    prog_modes             = PM_SPM | PM_ISP | PM_HVPP | PM_JTAG;
    mcuid                  = 138;
...

So, the user could specify -pATmega1280V or -pATmega1280-16CU etc and get to the same part with the same id.

stefanrueger commented 2 years ago 
$ head ATmega1280.atdf
<?xml version='1.0' encoding='UTF-8'?>
<avr-tools-device-file xmlns:xalan="http://xml.apache.org/xalan" xmlns:NumHelper="NumHelper" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" schema-version="0.3" xsi:noNamespaceSchemaLocation="../../schema/avr_tools_device_file.xsd">
  <variants>
      <variant ordercode="ATmega1280V-8AU" speedmax="8000000" tempmin="-40" tempmax="85" vccmin="1.8" vccmax="5.5" package="TQFP100" pinout="TQFP"/>
      <variant ordercode="ATmega1280V-8CU" speedmax="8000000" tempmin="-40" tempmax="85" vccmin="1.8" vccmax="5.5" package="CBGA100" pinout="CBGA"/>
      <variant ordercode="ATmega1280-16AU" speedmax="16000000" tempmin="-40" tempmax="85" vccmin="2.7" vccmax="5.5" package="TQFP100" pinout="TQFP"/>
      <variant ordercode="ATmega1280-16CU" speedmax="16000000" tempmin="-40" tempmax="85" vccmin="2.7" vccmax="5.5" package="CBGA100" pinout="CBGA"/>
  </variants>
  <devices>
    <device name="ATmega1280" architecture="AVR8" family="megaAVR">
mcuee commented 2 years ago

The V and L suffixes signify variants of the same part with the same pin assignments, the same function blocks, the same ATDF file and the same compiler headers and the same AVR_DEVICE_NAME macro, the same signature --- albeit with different Vcc or different frequency ranges.

Do they imply a difference for how AVRDUDE, the physical programmers or bootloaders can program these parts? What's the benefit of different avrdude.conf entries? What's different for the user?

I believe they make no differences for avrdude so we do not really need to differentiate them.

mcuee commented 2 years ago

Here's a list @stefanrueger posted in #1091. None of these are currently supported by Avrdude. Some of them may be ignored, while others should perhaps be added:

IMO we should add the ATtiny, ATmega, ATxmega, and AT90PWM parts.

Yes I agree on this one. So I have labeld this issue as Enhancement.

MCUdude commented 2 years ago

Do they imply a difference for how AVRDUDE, the physical programmers or bootloaders can program these parts? What's the benefit of different avrdude.conf entries? What's different for the user?

It's just for the sake of convenience, and to be consistent. The user may type the whole chip name, including the suffix, and Avrdude will figure out the rest. We have added "identical" parts that use the same atdf files before, so I thought we should be consistent (ATmega8A, ATmega16A etc.) EDIT: these parts actually have their own atdf files.

ATmega32A can be powered from 2.7-5.5V, while the "classic" ATmega32 must be powered from 4.5-5V. The ATmega32L can be powered from 2.7-5.5V, but can only run a maximum clock speed of 8 MHz. The same goes for ATmega16, ATmega64 and ATmega128. All these are "old" chips, and it appears that the L suffix has been replaced with either V or *PV.

No V or PV part is rated to run higher faster than 10 MHz, but they can run all the way down to 1.8V

If they are added at all I suggest riding close to the ATDF sheet and use the same part entry, but devise a new optional component called variants that is a list of strings that each can be specified at -p? Here an example of what I mean:

The last part in the part name -16au for instance has little to do with the chip, and more about the package it comes in. Instead of keeping track of every part number Microchip has ever used, why not just ignore everything after a - in the part name? This way, -p atmega2560v-8au will be interpreted as -p atmega2560v, and the rest is all good.

MCUdude commented 2 years ago

But I do agree that a variants field may be a good idea. However, I think we should stick with the part name before the -, and ignore the rest as it makes no difference.

But if ATmega2560V is a variant of ATmega2560, why shouldn't ATmega32A be a variant of ATmega32? To Avrdude it makes no difference since the only thing that differs from Avrdude's point of view is the part name:

https://github.com/avrdudes/avrdude/blob/eb7bdfd422e10c279f03282df79709046c556fea/src/avrdude.conf.in#L5611-L5618

Wouldn't it be better to have all variants of a chip with identical signatures at the same place?

#------------------------------------------------------------
# ATmega32
#------------------------------------------------------------

part
    desc                   = "ATmega32";
    id                     = "m32";
    variants               = "ATmega32A", "ATmega32L"

...

part
    desc                   = "ATmega1280";
    id                     = "m1280";
    variants               = "ATmega1280V"
stefanrueger commented 2 years ago

Why shouldn't ATmega32A be a variant of ATmega32?

To be consistent with avr-libc and avr-gcc. They have different ATDF files (with slight differences), hence different __AVR_DEVICE_NAME__ macros, quite possibly (mildly) different io header files. The user will see them as different and might expect them to be treated as different entities (even though it makes no difference to AVRDUDE). It would be great if all -m arguments for avr-gcc can be used as -p arguments of AVRDUDE.

The ATmega32L and ATmega32 in contrast are not afforded a difference in the programming environment, so it might confuse users (who have not waded deep into hardware and/or datasheet territory) to have different parts with different ids in avrdude.conf

So, my suggestion is to stay close to the ATDFs.

I agree packaging info is not needed.

MCUdude commented 2 years ago

Why shouldn't ATmega32A be a variant of ATmega32?

To be consistent with avr-libc and avr-gcc.

Good point. That would perhaps make maintenance more straightforward in the long run.

I agree packaging info is not needed.

Good. But I don't think it would be much work to make Avrdude ignore everything after the - in the name? This way, anyone, even those who don't RTFM can either the part number and it will just work. -p atmega324pb-abtvao? No problem!

stefanrueger commented 2 years ago

Yes, it's not hard to replace the first - in the -p string with a nul terminator.

stefanrueger commented 2 years ago

Another idea is to extend the syntax of AVRPART desc to enable lists: desc = "ATmega32", "ATmega32L"; Fun fact: PROGRAMMER id has the list syntax, but it's nowhere utilised so far.

The real hard work, of course, is describing the other parts, as they are not merely variants.

mcuee commented 1 year ago 
//{mcu_name,       mcuid,  family, {sig,    na, ture}, flstart,  flsize, pgsiz, nb, bootsz, eestart, eesize, ep, rambeg, ramsiz, nf, nl,  ni,       isr_names}, // Source

  {"ATtiny22",          13,  F_AVR8, {0x1E, 0x91, 0x06},       0, 0x00800,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0080,  1,  1,   3,   vtab_attiny22}, // avr-gcc 12.2.0
  {"ATmega8HVA",        47,  F_AVR8, {0x1E, 0x93, 0x10},       0, 0x02000, 0x080,  0,      0,       0, 0x0100,  4, 0x0100, 0x0200,  1,  1,  21, vtab_atmega16hva}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVA",       51,  F_AVR8, {0x1E, 0x94, 0x0C},       0, 0x04000, 0x080,  0,      0,       0, 0x0100,  4, 0x0100, 0x0200,  1,  1,  21, vtab_atmega16hva}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVB",       52,  F_AVR8, {0x1E, 0x94, 0x0D},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVBrevB",   53,  F_AVR8, {0x1E, 0x94, 0x0D},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega16M1",        54,  F_AVR8, {0x1E, 0x94, 0x84},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVA2",      55,  F_AVR8, {0x1E, 0x94, 0x0E},       0, 0x04000, 0x080, -1,     -1,      -1,     -1, -1, 0x0100, 0x0400,  2,  1,  22, vtab_atmega16hva2}, // avr-gcc 12.2.0
  {"ATmega32HVB",       60,  F_AVR8, {0x1E, 0x95, 0x10},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega32HVBrevB",   61,  F_AVR8, {0x1E, 0x95, 0x10},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega32C1",        62,  F_AVR8, {0x1E, 0x95, 0x86},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega32U6",        66,  F_AVR8, {0x1E, 0x95, 0x88},       0, 0x08000, 0x080,  4, 0x0200,      -1,     -1, -1, 0x0100, 0x0a00,  3,  1,  38, vtab_atmega32u6}, // avr-gcc 12.2.0, boot size (manual)
  {"ATmega64HVE",       74,  F_AVR8, {0x1E, 0x96, 0x10},       0, 0x10000, 0x080,  4, 0x0400,      -1,     -1, -1, 0x0100, 0x1000,  2,  1,  25, vtab_atmega64hve2}, // avr-gcc 12.2.0, boot size (manual)
  {"ATmega64C1",        75,  F_AVR8, {0x1E, 0x96, 0x86},       0, 0x10000, 0x100,  4, 0x0400,       0, 0x0800,  8, 0x0100, 0x1000,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega64HVE2",      77,  F_AVR8, {0x1E, 0x96, 0x10},       0, 0x10000, 0x080,  4, 0x0400,       0, 0x0400,  4, 0x0100, 0x1000,  2,  1,  25, vtab_atmega64hve2}, // atdf, avr-gcc 12.2.0
  {"ATmega323",        109,  F_AVR8, {0x1E, 0x95, 0x01},       0, 0x08000, 0x080,  4, 0x0200,      -1,     -1, -1, 0x0060, 0x0800,  2,  1,  21,  vtab_atmega323}, // avr-gcc 12.2.0, boot size (manual)
  {"AT43USB320",       162,  F_AVR8, {0xff,   -1,   -1},       0, 0x10000,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0200, -1, -1,   0,            NULL}, // avr-gcc 12.2.0
  {"AT43USB355",       163,  F_AVR8, {0xff,   -1,   -1},       0, 0x06000,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0400, -1, -1,   0,            NULL}, // avr-gcc 12.2.0
  {"AT90PWM1",         166,  F_AVR8, {0x1E, 0x93, 0x83},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0200,  3,  1,  32, vtab_at90pwm316}, // atdf, avr-gcc 12.2.0
  {"AT90PWM81",        173,  F_AVR8, {0x1E, 0x93, 0x88},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0100,  3,  1,  20, vtab_at90pwm161}, // atdf, avr-gcc 12.2.0
  {"AT90PWM161",       177,  F_AVR8, {0x1E, 0x94, 0x8B},       0, 0x04000, 0x080,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  20, vtab_at90pwm161}, // atdf, avr-gcc 12.2.0
  {"AT90S2323",        187,  F_AVR8, {0x1E, 0x91, 0x02},       0, 0x00800,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0080,  1,  1,   3,   vtab_attiny22}, // avr-gcc 12.2.0
  {"AT90C8534",        194,  F_AVR8, {0xff,   -1,   -1},       0, 0x02000,    -1, -1,     -1,      -1,     -1, -1, 0x0060, 0x0100, -1, -1,   0,            NULL}, // avr-gcc 12.2.0
  {"ATxmega32C3",      236, F_XMEGA, {0x1E, 0x95, 0x49},       0, 0x09000, 0x100,  1, 0x1000,       0, 0x0400, 32, 0x2000, 0x1000,  6,  1, 127, vtab_atxmega256c3}, // atdf, avr-gcc 12.2.0
  {"ATxmega32D3",      237, F_XMEGA, {0x1E, 0x95, 0x4A},       0, 0x09000, 0x100,  1, 0x1000,       0, 0x0400, 32, 0x2000, 0x1000,  6,  1, 114, vtab_atxmega384d3}, // atdf, avr-gcc 12.2.0
  {"ATtiny3214",       313, F_AVR8X, {0x1E, 0x95, 0x20},       0, 0x08000, 0x080,  1,      0, 0x01400, 0x0100, 64, 0x3800, 0x0800, 10,  1,  31, vtab_attiny3214}, // avr-gcc 12.2.0

It seems to me some of the parts never got released and some parts are obsolete.

Eg: ATmega32U6 has never been released. Ref: https://eecs.oregonstate.edu/education/docs/datasheets/at90usb.pdf Ref: http://ww1.microchip.com/downloads/en/devicedoc/7593s.pdf

ATtiny22 is said to be the same as the obsolete AT90S2343 (obsolete in 2001). Ref: https://www.avrfreaks.net/forum/attiny22l-spec-sheet

I believe ATtiny3214 never really got released either.

But things like ATmega32C1, ATmega64C1, ATxmega32C3, ATxmega32D3, AT90PWM1/81/161 are still in production.

stefanrueger commented 1 year ago

OK, if a part never saw the light of day, obvs part descriptions are not needed. Howeverl, if a part is obsolete or out of production, AVRDUDE should still be able to program it, or?

I'd argue that the AVRDUDE project should at least provide part descriptions for those with atdf files, but perhaps not the ATA devices as they tend to be problematic (they are often hybrid dual-chip devices, sometimes the datasheet is only available under NDA, some have flash at an offset, which requires changes in the code base). This reduces the list to

$ grep '{"' src/avrintel.c  | grep -v avrdude | grep atdf | grep -v '"ATA'
  {"ATmega8HVA",        47,  F_AVR8, {0x1E, 0x93, 0x10},       0, 0x02000, 0x080,  0,      0,       0, 0x0100,  4, 0x0100, 0x0200,  1,  1,  21, vtab_atmega16hva}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVA",       51,  F_AVR8, {0x1E, 0x94, 0x0C},       0, 0x04000, 0x080,  0,      0,       0, 0x0100,  4, 0x0100, 0x0200,  1,  1,  21, vtab_atmega16hva}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVB",       52,  F_AVR8, {0x1E, 0x94, 0x0D},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega16HVBrevB",   53,  F_AVR8, {0x1E, 0x94, 0x0D},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega16M1",        54,  F_AVR8, {0x1E, 0x94, 0x84},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega32HVB",       60,  F_AVR8, {0x1E, 0x95, 0x10},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega32HVBrevB",   61,  F_AVR8, {0x1E, 0x95, 0x10},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  2,  1,  29, vtab_atmega32hvbrevb}, // atdf, avr-gcc 12.2.0
  {"ATmega32C1",        62,  F_AVR8, {0x1E, 0x95, 0x86},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega64C1",        75,  F_AVR8, {0x1E, 0x96, 0x86},       0, 0x10000, 0x100,  4, 0x0400,       0, 0x0800,  8, 0x0100, 0x1000,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega64HVE2",      77,  F_AVR8, {0x1E, 0x96, 0x10},       0, 0x10000, 0x080,  4, 0x0400,       0, 0x0400,  4, 0x0100, 0x1000,  2,  1,  25, vtab_atmega64hve2}, // atdf, avr-gcc 12.2.0
  {"AT90PWM1",         166,  F_AVR8, {0x1E, 0x93, 0x83},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0200,  3,  1,  32, vtab_at90pwm316}, // atdf, avr-gcc 12.2.0
  {"AT90PWM81",        173,  F_AVR8, {0x1E, 0x93, 0x88},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0100,  3,  1,  20, vtab_at90pwm161}, // atdf, avr-gcc 12.2.0
  {"AT90PWM161",       177,  F_AVR8, {0x1E, 0x94, 0x8B},       0, 0x04000, 0x080,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  20, vtab_at90pwm161}, // atdf, avr-gcc 12.2.0
  {"ATxmega32C3",      236, F_XMEGA, {0x1E, 0x95, 0x49},       0, 0x09000, 0x100,  1, 0x1000,       0, 0x0400, 32, 0x2000, 0x1000,  6,  1, 127, vtab_atxmega256c3}, // atdf, avr-gcc 12.2.0
  {"ATxmega32D3",      237, F_XMEGA, {0x1E, 0x95, 0x4A},       0, 0x09000, 0x100,  1, 0x1000,       0, 0x0400, 32, 0x2000, 0x1000,  6,  1, 114, vtab_atxmega384d3}, // atdf, avr-gcc 12.2.0
  {"ATtiny416auto",    290, F_AVR8X, {0x1E, 0x92, 0x28},       0, 0x01000, 0x040,  1,      0, 0x01400, 0x0080, 32, 0x3f00, 0x0100, 10,  1,  26,  vtab_attiny817}, // atdf

The remaining ones (no atdf file and not ATA) are: ATtiny22 ATmega16HVA2 ATmega32U6 ATmega64HVE ATmega323 AT43USB320 AT43USB355 AT76C711 AT86RF401 AT90SCR100 AT90S2323 AT90C8534 AT94K M3000 ATtiny3214

For these, obvs, only those needed to be considered which exist out there (even though out of production).

If ATtiny22 is the same as AT90S2343 then it could have a very simple entry, indeed:

#------------------------------------------------------------
# ATtiny22
#------------------------------------------------------------

part parent "m328"
    desc                   = "ATtiny22";
    id                     = "2343";
    mcuid                  = 13;
;
mcuee commented 1 year ago

I'd argue that the AVRDUDE project should at least provide part descriptions for those with atdf files, but perhaps not the ATA devices.

I will agree with this one.

SpenceKonde commented 1 year ago

Two comments here that speak against "it has an atdf" being the only qualifier. The ATtiny3214 did have an atdf (it was in some versions of the ATPACKs), even though they never shipped any. So just because it has an atdf, shouldn't automatically qualify it.

Also, are you aware of the extent to which the ATmega__HVx are bizarro parts? Some of them are ATA's in all but name (the 64HVE2 is a dual-die part, with the second die being a LIN controller, and which is not described in the datasheet except in the most bare-bones terms, not enough to use it, and while the header on every page says ATmega32HVE2/ATmega64HVE2, the bottom of the page says Atmel ATA9999 Datasheet. Don't know why, just reporting observations. It's also not in production anymore). I would consider those to be ATA's baased on that - it's got all the hallmarks: incomplete docs, the bizzare feature set that is targeted at a very narrow niche. Since it looks to have come out in 2013 and is already out of production, it sounds like it wasn't exactly a hot seller.... At least some of the other HVx's are limited to max 1 MHz clock speed, and apparently designed for management of multi-cell battery stacks....

stefanrueger commented 1 year ago

@SpenceKonde OK, that leaves the following (also requiring there to be avr-gcc support)

$ grep '{"' src/avrintel.c  | grep -v avrdude | grep atdf | grep -v '"ATA' | grep -v "[0-9]HV" | grep avr-gcc
  {"ATmega16M1",        54,  F_AVR8, {0x1E, 0x94, 0x84},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega32C1",        62,  F_AVR8, {0x1E, 0x95, 0x86},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega64C1",        75,  F_AVR8, {0x1E, 0x96, 0x86},       0, 0x10000, 0x100,  4, 0x0400,       0, 0x0800,  8, 0x0100, 0x1000,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"AT90PWM1",         166,  F_AVR8, {0x1E, 0x93, 0x83},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0200,  3,  1,  32, vtab_at90pwm316}, // atdf, avr-gcc 12.2.0
  {"AT90PWM81",        173,  F_AVR8, {0x1E, 0x93, 0x88},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0100,  3,  1,  20, vtab_at90pwm161}, // atdf, avr-gcc 12.2.0
  {"AT90PWM161",       177,  F_AVR8, {0x1E, 0x94, 0x8B},       0, 0x04000, 0x080,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  20, vtab_at90pwm161}, // atdf, avr-gcc 12.2.0
  {"ATxmega32C3",      236, F_XMEGA, {0x1E, 0x95, 0x49},       0, 0x09000, 0x100,  1, 0x1000,       0, 0x0400, 32, 0x2000, 0x1000,  6,  1, 127, vtab_atxmega256c3}, // atdf, avr-gcc 12.2.0
  {"ATxmega32D3",      237, F_XMEGA, {0x1E, 0x95, 0x4A},       0, 0x09000, 0x100,  1, 0x1000,       0, 0x0400, 32, 0x2000, 0x1000,  6,  1, 114, vtab_atxmega384d3}, // atdf, avr-gcc 12.2.0
MCUdude commented 1 year ago

@stefanrueger how difficult would it be to make the parser only check and match the first part of the target name? We can always deal with missing parts as users request support for them.

Here are a few examples:

-p [target] Part name in avrdude.conf
atmega1280v atmega1280
atmega1280-16au atmega1280
atmega328pb-an atmega328pb
atmega32l-8pu atmega32
atmega32a-aur atmega32a
mcuee commented 1 year ago

@MCUdude and @stefanrueger

I think we should ignore the part -xx whch mainly talks about speed grade and packaging and they do not really matter for avrdude. However, it is still good to add the avriants like V and L.

Screenshot 2023-04-08 180249 Screenshot 2023-04-08 180526

#------------------------------------------------------------
# ATmega1280
#------------------------------------------------------------

part
    desc                   = "ATmega1280";
    id                     = "m1280";
    variants               = "ATmega1280V";
    prog_modes             = PM_SPM | PM_ISP | PM_HVPP | PM_JTAG;
    mcuid                  = 138;

#------------------------------------------------------------
# ATmega32
#------------------------------------------------------------

part
    desc                   = "ATmega32";
    id                     = "m32";
    variants               = "ATmega32L";
    prog_modes             = PM_SPM | PM_ISP | PM_HVPP | PM_JTAG | PM_JTAGmkI;
    mcuid                  = 58;
MCUdude commented 1 year ago

But what is a variant and what is not? IMO, ATmega32A is a variant of ATmega32 (binary compatible and the same device signature), but it has its own entry in avrdude.conf.

mcuee commented 1 year ago

But what is a variant and what is not? IMO, ATmega32A is a variant of ATmega32 (binary compatible and the same device signature), but it has its own entry in avrdude.conf.

To me this is simple. ATmega32A has a different datasheet and webpage from ATmega32. ATmega32L shares the same datasheet with ATmega32.

In general A is not a variant. L and V are variants but there may be some exceptions.

mcuee commented 1 year ago

The reason why I am against adding the -xx in the variants list is that it will bloat avrdude.conf file. You will have 9 variants for ATmega32A. Then there are 10 variants for ATmega32/32L.

Screenshot 2023-04-08 181738

MCUdude commented 1 year ago

My idea was to only add the main parts, and let Avrdude "filter out" suffixes like "v", "l" and -16pu. The approach I was suggesting would in theory not add anything to avrdude.conf, not even variants.

mcuee commented 1 year ago

My idea was to only add the main parts, and let Avrdude "filter out" suffixes like "v", "l" and -16pu. The approach I was suggesting would in theory not add anything to avrdude.conf, not even variants.

It should be easy to filter out -16pu. But I think you still have to change avrdude.conf no matter what so that avrdude knows that V and L parts, either by adding extra entries in avrdude.conf, or by using variants. The idea of using variants seems to be neat to me.

And I belive there are exceptions that L may be not a variant. For example, it seems there is only ATtiny15L but no real ATtiny15 out in the market. http://ww1.microchip.com/downloads/en/devicedoc/doc1187.pdf

MCUdude commented 1 year ago

But I think you still have to change avrdude.conf no matter what so that avrdude knows that V and L parts, either by adding extra entries in avrdude.conf, or by using variants.

I think it should be trivial for Avrdude to figure out that atmega1280v is just a variant of atmega1280 without explicitly specifying it in avrdude.conf. Avrdude knows that atmega1280 is a valid part, but atmega1280v is not, according to avrdude.conf. So all Avrdude has to do is find the closest match. Finding and adding all variants to avrdude.conf is quite a job, and if it isn't strictly necessary, why spend the time?

mcuee commented 1 year ago

But I think you still have to change avrdude.conf no matter what so that avrdude knows that V and L parts, either by adding extra entries in avrdude.conf, or by using variants.

I think it should be trivial for Avrdude to figure out that atmega1280v is just a variant of atmega1280 without explicitly specifying it in avrdude.conf. Avrdude knows that atmega1280 is a valid part, but atmega1280v is not, according to avrdude.conf. So all Avrdude has to do is find the closest match. Finding and adding all variants to avrdude.conf is quite a job, and if it isn't strictly necessary, why spend the time?

Maybe we should let @stefanrueger decide which way to go. It seems to me with his strong skills to parse Atmel atdf files, it should be pretty easy for him to find the variants.

And you actually have listed down the main ones in your first two posts.

stefanrueger commented 1 year ago

let Avrdude "filter out" suffixes like "v", "l" and -16pu.

I understand the motivation about cutting off the packaging info after a -.

I don't think AVRDUDE can say with confidence that v or l suffixes are variants in absence of explicit external knowledge. It may have been so in the past, but who knows what happens in the future? As such there needs to be a table somewhere that tells AVRDUDE which parts, when suffixed with v or l, are essentially the same for purposes of programming, uploading or downloading. And that table needs to have its root in datasheets or .atdf files.

[atmega1280 known but atmega1280v not] all Avrdude has to do is find the closest match

There are counter-examples where parts that differ in a single suffix letter are quite different (think ATmega328pb vs ATmega328p). Traditionally AVRDUDE has relied on infos in datasheets and .atdf files as externalised in the acrdude.conf. I strongly suggest that we should not start guesswork, and in particular where it is unsupported by datasheets.

Coincidently, given the precise definitive nature that part names should have, I am against AVRDUDE mapping ghost names to existing parts, eg, it would be wrong for AVRDUDE to accept ATmega328PA as ATmega328P because the suffix A wouldn't matter for other parts in terms of AVRDUDE programming. That part doesn't exist, and that should be the end of it rather than auguring typos or otherwise. Also, I'd find it not great if AVRDUDE accepted ATmega328P-16CU because there simply isn't a 100 pin ball grid array of that type. I am actually not sure the assumption that packaging is irrelevant is true. The 328p does not have pinouts on the DIP package for ADC6/7. Not relevant for AVRDUDE in its current functionality, but well, there just might be better counter-examples lurking in the 300+ strong different parts that AVRDUDE knows something about.

So, I would only consider variants what Microchip document as such. That's a field in the .ATDF file. Can be done (and translated to sth like a variants field in avrdude.conf automatically) and I can do that some day when I review avrdude.conf next.

What's the problem that we are trying to solve? When a user rocks up with a part and a .hex file, they are likely to have received the latter from someone with instructions how to put that on the device, incl the part name. If they compiled the .hex themselves, well, they should know the part name from using the compiler.

I find it far more important to add unknown parts to avrude.conf (b/c then all of a sudden that, for example, ATmega16M1 part that currently cannot be programmed can be dealt with.)

mcuee commented 1 year ago

@stefanrueger

So, I would only consider variants what Microchip document as such. That's https://github.com/avrdudes/avrdude/issues/1092#issuecomment-1232279890. Can be done (and translated to sth like a variants field in avrdude.conf automatically) and I can do that some day when I review avrdude.conf next.

That would be nice.

I find it far more important to add unknown parts to avrude.conf (b/c then all of a sudden that, for example, ATmega16M1 part that currently cannot be programmed can be dealt with.)

I will agree with this one. Basically this means the following parts as per your previous post.

$ grep '{"' src/avrintel.c  | grep -v avrdude | grep atdf | grep -v '"ATA' | grep -v "[0-9]HV" | grep avr-gcc
  {"ATmega16M1",        54,  F_AVR8, {0x1E, 0x94, 0x84},       0, 0x04000, 0x080,  4, 0x0200,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega32C1",        62,  F_AVR8, {0x1E, 0x95, 0x86},       0, 0x08000, 0x080,  4, 0x0200,       0, 0x0400,  4, 0x0100, 0x0800,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"ATmega64C1",        75,  F_AVR8, {0x1E, 0x96, 0x86},       0, 0x10000, 0x100,  4, 0x0400,       0, 0x0800,  8, 0x0100, 0x1000,  3,  1,  31, vtab_atmega64m1}, // atdf, avr-gcc 12.2.0
  {"AT90PWM1",         166,  F_AVR8, {0x1E, 0x93, 0x83},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0200,  3,  1,  32, vtab_at90pwm316}, // atdf, avr-gcc 12.2.0
  {"AT90PWM81",        173,  F_AVR8, {0x1E, 0x93, 0x88},       0, 0x02000, 0x040,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0100,  3,  1,  20, vtab_at90pwm161}, // atdf, avr-gcc 12.2.0
  {"AT90PWM161",       177,  F_AVR8, {0x1E, 0x94, 0x8B},       0, 0x04000, 0x080,  4, 0x0100,       0, 0x0200,  4, 0x0100, 0x0400,  3,  1,  20, vtab_at90pwm161}, // atdf, avr-gcc 12.2.0
  {"ATxmega32C3",      236, F_XMEGA, {0x1E, 0x95, 0x49},       0, 0x09000, 0x100,  1, 0x1000,       0, 0x0400, 32, 0x2000, 0x1000,  6,  1, 127, vtab_atxmega256c3}, // atdf, avr-gcc 12.2.0
  {"ATxmega32D3",      237, F_XMEGA, {0x1E, 0x95, 0x4A},       0, 0x09000, 0x100,  1, 0x1000,       0, 0x0400, 32, 0x2000, 0x1000,  6,  1, 114, vtab_atxmega384d3}, // atdf, avr-gcc 12.2.0
mcuee commented 1 year ago

There is an interesting note from Spence Konde. We already have ATmega32M1 and ATmega64M1 insideavrdude.conf.in`. https://github.com/SpenceKonde/AVR-Guidance/blob/master/AVRFamilies_And_Compatibility/ArduinoCores.md

ATmega16M1/32M1/64M1/32C1/64C1 parts This family is the only set of parts that I think "deserves" a core and doesn't have one.

MCUdude commented 1 year ago

We should focus on the missing parts then.

ATmega16M1/32M1/64M1/32C1/64C1 parts This family is the only set of parts that I think "deserves" a core and doesn't have one.

There already exists an Arduino core for ATmega16/32/64M1: https://github.com/thomasonw/ATmegaxxM1-C1

And it has the ATmega16M1 in its avrdude.conf file:

#------------------------------------------------------------
# ATmega16m1
# Note: This should work with arduino 1.8.11 +
# changed by Geraldjust
#------------------------------------------------------------

part
    desc            = "ATmega16M1";
    id              = "m16m1";
    has_jtag         = yes;
    stk500_devcode   = 0xA0;
    avr910_devcode   = 0x45;
    signature        = 0x1e 0x94 0x84;
    chip_erase_delay = 9000;
    pagel            = 0xD7;
    bs2              = 0xA0;
    reset            = dedicated;
    pgm_enable       = "1 0 1 0  1 1 0 0    0 1 0 1  0 0 1 1",
                       "x x x x  x x x x    x x x x  x x x x";

    chip_erase       = "1 0 1 0  1 1 0 0    1 0 0 0  0 0 0 0",
                       "x x x x  x x x x    x x x x  x x x x";

    timeout   = 200;
    stabdelay   = 100;
    cmdexedelay   = 25;
    synchloops    = 32;
    bytedelay   = 0;
    pollindex   = 3;
    pollvalue   = 0x53;
    predelay    = 1;
    postdelay   = 1;
    pollmethod    = 0;

    pp_controlstack     =
        0x0E, 0x1E, 0x0F, 0x1F, 0x2E, 0x3E, 0x2F, 0x3F,
        0x4E, 0x5E, 0x4F, 0x5F, 0x6E, 0x7E, 0x6F, 0x7F,
        0x66, 0x76, 0x67, 0x77, 0x6A, 0x7A, 0x6B, 0x7B,
        0xBE, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00;
    hventerstabdelay    = 100;
    progmodedelay       = 0;
    latchcycles         = 6;
    togglevtg           = 0;
    poweroffdelay       = 0;
    resetdelayms        = 0;
    resetdelayus        = 0;
    hvleavestabdelay    = 15;
    chiperasepulsewidth = 0;
    chiperasepolltimeout = 10;
    programfusepulsewidth = 0;
    programfusepolltimeout = 5;
    programlockpulsewidth = 0;
    programlockpolltimeout = 5;

    idr                 = 0x22;
    spmcr               = 0x68;
    allowfullpagebitstream = yes;

    memory "eeprom"
        paged           = no; /* leave this "no" */
        page_size       = 4;  /* for parallel programming */
        size            = 512;
        min_write_delay = 3600;
        max_write_delay = 3600;
        readback_p1     = 0xff;
        readback_p2     = 0xff;
        read            = " 1 0 1 0 0 0 0 0",
                          " 0 0 0 x x x x a8",
                          " a7 a6 a5 a4 a3 a2 a1 a0",
                          " o o o o o o o o";

        write           = " 1 1 0 0 0 0 0 0",
                          " 0 0 0 x x x x a8",
                          " a7 a6 a5 a4 a3 a2 a1 a0",
                          " i i i i i i i i";

  loadpage_lo = "  1   1   0   0      0   0   0   1",
        "  0   0   0   0      0   0   0   0",
        "  0   0   0   0      0   0  a1  a0",
        "  i   i   i   i      i   i   i   i";

  writepage = "  1   1   0   0      0   0   1   0",
        "  0   0   x   x      x   x   x  a8",
        " a7  a6  a5  a4     a3  a2   0   0",
        "  x   x   x   x      x   x   x   x";

  mode    = 0x41; 
  delay   = 20;
  blocksize = 4;
  readsize  = 256;
      ;

    memory "flash"
        paged           = yes;
        size            = 16384;
        page_size       = 128;
        num_pages       = 128;
        min_write_delay = 4500;
        max_write_delay = 4500;
        readback_p1     = 0xff;
        readback_p2     = 0xff;
        read_lo         = " 0 0 1 0 0 0 0 0",
                          " 0 0 0 a12 a11 a10 a9 a8",
                          " a7 a6 a5 a4 a3 a2 a1 a0",
                          " o o o o o o o o";

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

        loadpage_lo     = " 0 1 0 0 0 0 0 0",
                          " 0 0 0 x x x x x",
                          " x x a5 a4 a3 a2 a1 a0",
                          " i i i i i i i i";

        loadpage_hi     = " 0 1 0 0 1 0 0 0",
                          " 0 0 0 x x x x x",
                          " x x a5 a4 a3 a2 a1 a0",
                          " i i i i i i i i";

        writepage       = " 0 1 0 0 1 1 0 0",
                          " 0 0 0 a12 a11 a10 a9 a8",
                          " a7 a6 x x x x x x",
                          " x x x x x x x x";

  mode    = 0x41; 
  delay   = 6;
  blocksize = 128;
  readsize  = 256;
      ;

    memory "lfuse"
        size            = 1;
        write           = "1 0 1 0  1 1 0 0  1 0 1 0  0 0 0 0",
                          "x x x x  x x x x  i i i i  i i i i";

        read            = "0 1 0 1  0 0 0 0  0 0 0 0  0 0 0 0",
                          "x x x x  x x x x  o o o o  o o o o";
        min_write_delay = 4500;
        max_write_delay = 4500;
      ;

    memory "hfuse"
        size            = 1;
        write           = "1 0 1 0  1 1 0 0  1 0 1 0  1 0 0 0",
                          "x x x x  x x x x  i i i i  i i i i";

        read            = "0 1 0 1  1 0 0 0  0 0 0 0  1 0 0 0",
                          "x x x x  x x x x  o o o o  o o o o";
        min_write_delay = 4500;
        max_write_delay = 4500;
      ;

    memory "efuse"
        size            = 1;
        write           = "1 0 1 0  1 1 0 0  1 0 1 0  0 1 0 0",
                          "x x x x  x x x x  x x i i  i i i i";

        read            = "0 1 0 1  0 0 0 0  0 0 0 0  1 0 0 0",
                          "x x x x  x x x x  x x o o  o o o o";
        min_write_delay = 4500;
        max_write_delay = 4500;
      ;

    memory "lock"
        size            = 1;
        read            = "0 1 0 1  1 0 0 0   0 0 0 0  0 0 0 0",
                          "x x x x  x x x x   x x o o  o o o o";

        write           = "1 0 1 0  1 1 0 0   1 1 1 x  x x x x",
                          "x x x x  x x x x   1 1 i i  i i i i";
        min_write_delay = 4500;
        max_write_delay = 4500;
      ;

    memory "calibration"
        size            = 4;
        read            = "0 0 1 1  1 0 0 0    x x x x  x x x x",
                          "0 0 0 0  0 0 a1 a0  o o o o  o o o o";
      ;

    memory "signature"
        size            = 3;
        read            = "0  0  1  1   0  0  0  0   x  x  x  x   x  x  x  x",
                          "x  x  x  x   x  x a1 a0   o  o  o  o   o  o  o  o";
      ;
  ;
mcuee commented 1 year ago

We should focus on the missing parts then.

ATmega16M1/32M1/64M1/32C1/64C1 parts This family is the only set of parts that I think "deserves" a core and doesn't have one.

There already exists an Arduino core for ATmega16/32/64M1: https://github.com/thomasonw/ATmegaxxM1-C1

And it has the ATmega16M1 in its avrdude.conf file

@MCUdude Nice finding. The only thing is that it seems not updated for a while.

@SpenceKonde You may want to update your document here. https://github.com/SpenceKonde/AVR-Guidance/blob/master/AVRFamilies_And_Compatibility/ArduinoCores.md

mcuee commented 1 year ago

@MCUdude

I see that you mentioned there is a PR for Optiboot bootloader for ATmega16M1/32M1/64M1. https://github.com/thomasonw/ATmegaxxM1-C1/issues/18 https://github.com/Optiboot/optiboot/pull/176

Then I also notice that @stefanrueger has the urboot hex files for ATmega16M1/32M1/64M1/32C1/64C1. In fact there are urboot hex files for AT90PWM1/81/161 as well. https://github.com/stefanrueger/urboot.hex/tree/main/mcus

The only question is that I do not have the chips to test them. Not so sure who have the chips.

Still we can always add them in avrdude first based on the info available, without testing.