Implement Damerau Levenshtein distance checking for parts and memories about avrdude HOT 5 OPEN

Avrdude supports m328p, t817 and x128a1u. Would it be possible to implement support for 128da32 as well?

As in PR #1703?

from avrdude.

There are subtle but important differences between programmer, part and memory names:

• Programmer names are arbitrary product names, sometimes modified by the AVRDUDE project; it makes sense to get help for typos
• Part names are the official ones; small changes, even a letter, can make a big difference for programming, eg, the fuse bitfields between the ATmega328P and ATmega328PB are different. It is unclear to me whether DL can help the user. They really have to get the right part that's in front of them. But if it's implemented it is a bit more involved than for the programmer: the part id, their official part name, any of the full variant part names or their initial part up to a dash can be used to address a part; for example, we have

    m16        = ATmega16
      - ATmega16:       N/A,    Fmax=16 MHz, T=[N/A,    N/A], Vcc=[N/A,     N/A]
      - ATmega16-16AQR: TQFP44, Fmax=16 MHz, T=[N/A,    N/A], Vcc=[4.5 V, 5.5 V]
      - ATmega16-16AU:  TQFP44, Fmax=16 MHz, T=[-40 C, 85 C], Vcc=[4.5 V, 5.5 V]
      - ATmega16-16AUR: TQFP44, Fmax=16 MHz, T=[-40 C, 85 C], Vcc=[4.5 V, 5.5 V]
      - ATmega16-16MQ:  MLF44,  Fmax=16 MHz, T=[-40 C, 85 C], Vcc=[4.5 V, 5.5 V]
      - ATmega16-16MU:  MLF44,  Fmax=16 MHz, T=[-40 C, 85 C], Vcc=[4.5 V, 5.5 V]
      - ATmega16-16MUR: MLF44,  Fmax=16 MHz, T=[-40 C, 85 C], Vcc=[4.5 V, 5.5 V]
      - ATmega16-16PU:  PDIP40, Fmax=16 MHz, T=[-40 C, 85 C], Vcc=[4.5 V, 5.5 V]
      - ATmega16L-8AQ:  TQFP44, Fmax=8 MHz,  T=[-40 C, 85 C], Vcc=[2.7 V, 5.5 V]
      - ATmega16L-8AQR: TQFP44, Fmax=8 MHz,  T=[N/A,    N/A], Vcc=[2.7 V, 5.5 V]
      - ATmega16L-8AU:  TQFP44, Fmax=8 MHz,  T=[-40 C, 85 C], Vcc=[2.7 V, 5.5 V]
      - ATmega16L-8AUR: TQFP44, Fmax=8 MHz,  T=[N/A,    N/A], Vcc=[2.7 V, 5.5 V]
      - ATmega16L-8MU:  MLF44,  Fmax=8 MHz,  T=[-40 C, 85 C], Vcc=[2.7 V, 5.5 V]
      - ATmega16L-8MUR: VQFN44, Fmax=8 MHz,  T=[N/A,    N/A], Vcc=[2.7 V, 5.5 V]
      - ATmega16L-8PU:  PDIP40, Fmax=8 MHz,  T=[-40 C, 85 C], Vcc=[2.7 V, 5.5 V]
  

  In this example one can use m16, ATmega16, ATmega16L and 14 full variant names such as ATmega16-16MU that all point to the same part m16. If a user types ATmega16-16MV, should the user be advised to use ATmega16-16MU, ATmega16-16MQ, and other variants? Probably best to suggest just one entry ATmega16 (m16). If the user types t16 should they be advised of just other ids m16, t11, t12, t13, t15? Probably better to suggest full names, too as in ATmega16 (m16), ATtiny11 (t11), ...
• Memory names can be abbreviated as long as they are unique for the part: flash, flas, fla and fl will work. What should be suggested for fls? Always the full name flash or the closest abbreviations?
• Memory names are matched case sensitive, but programmer and part names are treated case insensitive. DL will be implemented for case insensitive matches (which is probably what you want)

I think it's OK to limit suggestions for a part if the programmer has unambiguously been specified and hence the supported programming interfaces are known.

from avrdude.

Part names are the official ones; small changes, even a letter, can make a big difference for programming, eg, the fuse bitfields between the ATmega328P and ATmega328PB are different. It is unclear to me whether DL can help the user. They really have to get the right part that's in front of them

OK, this might be more difficult to solve than I first imagined. I'd think that we should only suggest the full name (atmega328p, not m328p), and ignore subtypes (ATmega328P-AU). So if the user uses -c m328L or ATmega328P-AY, suggest atmega328p as the most possible option, not m328p.

Memory names can be abbreviated as long as they are unique for the part: flash, flas, fla and fl will work

I think we should always suggest the full memory name to prevent confusion.

Memory names are matched case sensitive, but programmer and part names are treated case insensitive. DL will be implemented for case-insensitive matches (which is probably what you want)

I think case-insensitive matches for memories would be the best. A user may write -U EEPROM:w:data.hex:i, because EEPROM is usually written with capital letters. However, suggestions would always be that the actual memory name is in avrdude.conf is; eeprom in lover case.

Off topic:
Avrdude supports m328p, t817 and x128a1u. Would it be possible to implement support for 128da32 as well?

from avrdude.

Off topic:
Avrdude supports m328p, t817 and x128a1u. Would it be possible to implement support for 128da32 as well?

Good idea.

from avrdude.

Avrdude supports m328p, t817 and x128a1u. Would it be possible to implement support for 128da32 as well?

As in PR #1703?

PR #1703 looks good.

from avrdude.