Reference to avrdude issues not planned -- but PRs will be welcome

[mcuee]

There are enhancement requests raised or ideas raised, which were deemed to be not the focus of avrdude project. However, if people are really interested and willing to work on it and come out with PRs, then the project may well review the PR and see if it is a good idea to be included.

[mcuee]

CH341 related enhancements: good to have but not the focus

• CH341A futher improvement -- to support lower clock AVR chips #1441
• CH341A futher improvement -- to support MSVC build #1440

AVR910 related enhancements:

• Enhance AVR910 to support 256KB Flash parts #1442
• AVR910 programmer enhancment ideas #1449
• AVR910 - Universal Programmer Improvement suggestion #1652

linuxgpio enhancement ideas: jtag, PDI and UPDI support. This is nice to have if there are people who are willing to work on them.

• updi support with Linux gpio #1456 (UPDI)
• AVRDUDE linuxgpio/linuxspi and PDI #1561 (PDI)
• JTAG support with linuxgpio? #1494 (JTAG)

AVR32 support:

• [bug #34767] Avrdude to enable AVR Dragon to program AVR32 parts #1434
• [patch #9573] patch to add atmelice avr32 programming support to avrdude #1435

[mcuee]

Other issues.

• Atmel ICE/PowerDebugger TPI issues on MacOS #1412
• DragonFly BSD support #1682
• [patch #9565] Patch for WiFi AVR Programmer, uPDI support for jtagmkII, and serial-over-network improvements #1676

[mcuee]

@stefanrueger and @MCUdude

I understand that @stefanrueger prefers that we do not keep too many issues and discussions (say <=25 to keep in one page).
@MCUdude thinks it is not worth converting old open issues to Discussions.

I am okay with both ideas and I have closed quite a few dicussions recently. Still I prefer to keep this discussion OPEN to keep track. Hopefully this is okay with both of you.

[mcuee]

@stefanrueger and @MCUdude
Looking at the openning issues, I tend to think we can close some of them as not planned and link here.

Any objections? I actually want to keep #1490 but it seems to be a tough one and no one is working on it now.

• Implement Damerau Levenshtein distance checking for parts and memories #1701
• Support ATmega16/32/64/128(A) using FTDI JTAG -- remaining work from #1324 #1490
• To adopt PR #1264 approach of using Readline replacement for MinGW build (Low Priority) #1271
• PICKit 4, SNAP, Atmel ICE and Power Debugger only work with hidapi but not libusb #1221
• Missing TPI, JTAG and UPDI support for the STK600 #1047
• usbasp xmega pdi enhancement #1024
• Rework PICKit2 programmer to use libhidapi instead of libhid (which will make it work under macOS) #883

[stefanrueger]

That is actually a great idea to keep a list of neat ideas or known shortfalls, thanks

[mcuee]

I have closed 4 of the above 7 issues as not planned. We can always reopen them when someone is working on it.

• Support ATmega16/32/64/128(A) using FTDI JTAG -- remaining work from #1324 #1490
• To adopt PR #1264 approach of using Readline replacement for MinGW build (Low Priority) #1271
• PICKit 4, SNAP, Atmel ICE and Power Debugger only work with hidapi but not libusb #1221 (re-open as the root cause was identified)
• Rework PICKit2 programmer to use libhidapi instead of libhid (which will make it work under macOS) #883

I will wait for @MCUdude's comment before closing the remaining three issues..

• Implement Damerau Levenshtein distance checking for parts and memories #1701 --> closed as not planned
• Missing TPI, JTAG and UPDI support for the STK600 #1047
• usbasp xmega pdi enhancement #1024

[mcuee]

The following two issues have been closed as "not planned"

• Missing TPI, JTAG and UPDI support for the STK600 #1047
• usbasp xmega pdi enhancement #1024

[mcuee]

I have closed the following long standing issues as "not planned" due to the lack of capacity in the team and also that we have a documented workaround.

• ftdi_syncbb: very slow D2XX based MSVC build compared to libftdi based MinGW build #1253
• avrdude MSVC build problem with USB composite device (avrdude-libusb library issue) #968