avrdude 8.2 release discussion

[mcuee]

We have just released avrdude 8.1. So 8.2 release will probably not so soon -- probably toward the end of year 2025 or early 2026, if no serious bugs are reported.

[mcuee]

Let's see if the users have some wishes for avrdude.

Areas we can draw the potential improvements:

1. Issues
   https://github.com/avrdudes/avrdude/issues

2. Known limitations
   https://github.com/avrdudes/avrdude/wiki/Known-limitations-of-avrdude

3. Issues known but not planned -- PRs are welcome from the community

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

4. New inputs and ideas from the community

...

[mcuee]

If we look at the current issues, they are mainly in the following areas.

1. CMake and github actions

• To add libserialport support to Windows MSVC build #1552
• CMake improvement -- using pkg-find to find the libraries #1797
• avrdude Python binding CMake configuration improvement #1914
• Upload avrdude-gui artifacts for Windows #1946
• GitHub deploy action for avrdude failed to run #2038 --> PR Update deploy.yml to use download-artifact@v4 #2040 fixed this issue
• github avrdude_packing_release action failed #2039

2. libavrdude related

• Using libavrdude as a standalone library #819
• To improve the documentation of libavrdude functions #1057
• Unable to build libavrdude dynamic library under Windows and macOS #1414

3. Documentation related

• To improve the documentation of libavrdude functions #1057
• avrdude documentation improvement  #1674

We also want to provide more examples on how to use avrdude CLI and Terminal interface.

4. Other things -- Enhancement / Bugs

• linuxgpio/libgpiod: using GPIOs on different chips #2027
• AVR32 support -- low priority #1882
• PICKit 4, SNAP, Atmel ICE and Power Debugger only work with hidapi but not libusb #1221
• Endianness related errors and warnings while running avrdude -c '*/u' on s390x #1917

[mcuee]

@stefanrueger, @MCUdude and @dl8dtl

Personally I think we can spend a bit of time of the Documentation side. You sure have a lot of good examples on using avrdude CLI and terminal interface. We can document them either in the user manual or the FAQ page.
https://avrdudes.github.io/avrdude/8.1/avrdude_7.html#Example-Command-Line-Invocations
https://avrdudes.github.io/avrdude/8.1/avrdude_10.html#Terminal-Mode-Examples
https://github.com/avrdudes/avrdude/wiki/FAQ

When it comes to the avrdude pdf/html documentations, there are also areas of improvement we can do.

Examples:
https://avrdudes.github.io/avrdude/8.1/avrdude_20.html#Programmer-Specific-Information
https://avrdudes.github.io/avrdude/8.1/avrdude_25.html#Platform-Dependent-Information (I will work on this)
https://avrdudes.github.io/avrdude/8.1/avrdude_44.html#Troubleshooting (I will work on this)

[mcuee]

@stefanrueger

I noticed that there are quite some repeated entry here. Not so sure why.
https://avrdudes.github.io/avrdude/8.1/avrdude_45.html
C. List of Programmers

These repeated entries also appeared in the Index.

Example:
https://avrdudes.github.io/avrdude/8.1/avrdude_60.html#index_split-8_cp_letter-X

[mcuee]

For libavrdude, @dl8dtl has done a good example with the Python binding. Maybe it is good to have some C or C++ based examples as well.

[stefanrueger]

libavrdude documentation is going to be really hard. We missed the opportunity to deploy in-code documentation as we went along. In reality, contributors rarely gave libavrdude second thoughts. Function signatures change frequently, what they do changes at the drop of a hat when it becomes necessary to better model AVR features, structures regularly change fields and these are accessed by direct component rather than access functions. All this implies that the binary interface to libavrdude changes frequently with updates to git main. We have recently gone to the trouble of incrementing the SOVERSION of libavrdude post release, so that each release has at least a unique version number (from v7.2 onwards?). As the project went ahead with improving user interaction and as the AVR parts developed further the main.c code (that deploys libavrdude) became increasingly complex.

Sooo, any developer wanting to use libavrdude is likely to have to go through what presumably @dl8dtl did when he developed the rather advanced SWIG GUI (that he understated as proof of concept), namely looking at main.c and read the source of libavrdude functions in lieu of documentation to use them correctly.

But yes, if we find a neat toy example (and programming a GUI is decidedly not one of these) we might demonstrate the use of libavrdude.

[MCUdude]

I just wrote a post over at the Avrfreaks forum where I announced that 8.1 is now available. The forum users are generally happy that this tool is being maintained and kept up-to-date, but there are users who complain that there is no GUI. Avrdude will always be a command line tool, and we have a python SWIG example that provide a GUI.

But I get their point. A GUI tool that can be installed through an installer, or simply an executable without any dependencies would be very nice. I'm not talking about something that exposes all features Avrdude has to offer. That would be very difficult and would make the GUI less intuitive.

I've never created a cross-platform GUI program before, so I don't know what I'm talking about.

But how difficult would it be to create a "mouse-based" application that:

• Either utilizes libavrdude or an Avrdude binary
• Can be installed on most/any operating system without any dependency nightmare
• Is easy to install. As in an installer that bundles everything that's necessary to get going
• Should still work even though you just got an OS update
• Only provides basic Avrdude functionality, similar to how the device programming window in Microchip Studio works, with the possibility of expanding the exposed functionality in the future.

We do have the python SWIG example, but this isn't a single installer, and it's also more of a proof of concept rather than a polished and tested application that most people would feel right at home with.

Microchip Studio 7 is soon EOL, and MPLAB X IPE is neither intuitive nor good. There has to be a market for a good, open-source GUI application that works on most operating systems.
Any thoughts?

[mcuee]

I'd be in favour of expanding @dl8dtl's GUI. We haven't had any feedback from users about this. Is it b/c it's not easy to install?

I will say it is very easy to build under Linux. The issue is that no distribution maintainers have bundled the Python GUI. It has quite a lot of dependencies under Linux, especially for Ubuntu/Debian side with no meta package for PySide 2 (and no PySide 6 yet).

macOS is slightly tricky (if the user has Python installation with both HomeBrew and the system) but not that difficult if using a virtual environment and adopt a simple fix to CMake files (refer to my draft PR). The main problem is that Homebrew formula does not include Python binding as of now. The homebrew formula does not even support libserialport as of now.

Windows is always more difficult -- the GUI works only with the MSVC build and we need to figure out how to bundle it properly. I tend to believe there is a way to create an installer for Windows but I do not know how to do that myself.

[mcuee]

As for expanding the GUI functionality, I think the suggestions from Hans is very good. Unfortunately none of us are a GUI programmer. I am not even a programmer myself.

Maybe we need some help from the community here. I think we do not need a very experienced Python programmer. PySide6 (along with PyQt6) is a pretty popular Python GUI.

QT is very popular. So a contributor can also use other language like C++ if he or she prefers not to use Python.

[MCUdude]

As for expanding the GUI functionality, I think the suggestions from Hans is very good. Unfortunately none of us are a GUI programmer. I am not even a programmer myself.

Thanks! These are only my suggestions, but I don't think they are unreasonable from a user perspective. I have never touched Qt (which I believe @dl8dtl used), and I have no idea how the .UI files go together with the Python program. But I'll be more than happy to work together with @dl8dtl to improve upon the existing GUI.

Avrdude is packed with features, but most users would mostly need a small subset of all the functionality Avrdude has to offer.
What are your thoughts on this @dl8dtl?

macOS is slightly tricky (if the user has Python installation with both HomeBrew and the system) but not that difficult if using a virtual environment and adopt a simple fix to CMake files (refer to my draft PR)

Actually, it wasn't all that difficult to make it work once I figured out the extra packages had to install through Homebrew (swig and pyside. I'm using the Python 3 installation that the OS is delivered with. All we really need is a script the user can run (a double-clickable file ideally), and then run the Python GUI application. On Windows I don't know what it would take to make it reasonably easy to install. It doesn't have to be an installer either.

[mcuee]

@MCUdude

You may want to start with the tutorial here to see how you feel about PySide6 (along with PyQt6 which is quite similar).
https://www.pythonguis.com/pyside6-tutorial/

They have instructions for packing for Windows an macOS as well.
https://www.pythonguis.com/tutorials/packaging-pyside6-applications-windows-pyinstaller-installforge/
https://www.pythonguis.com/tutorials/packaging-pyside6-applications-pyinstaller-macos-dmg/

[mcuee]

I have created a zip file containing the Python GUI and Python Virtual Env for Windows 11 in the avrdude 8.1 release. Let's see if it helps people to run the Python GUI under Windows.
https://github.com/avrdudes/avrdude/releases/download/v8.1/avrdude-v8.1-windows-python-x64.zip

Instruction to run the Python GUI.

• Upload avrdude-gui artifacts for Windows #1946 (comment)

[mcuee]

@stefanrueger @MCUdude and @dl8dtl
Time flies. Let's see whether we want to come out a new release by end of June 2026.

[stefanrueger]

Yes, June is good. I personally will be offline from 12 July 2026 onwards, so an end-of-June release will give some puncture time in case the release broke something significant and needs a quick follow-up release.

[MCUdude]

@mcuee it's possible to use the statically built macOS avrdude binary as long as it's not downloaded using a web browser. I know, it's dumb. But this means that I can use the Avrdude 8.1 binaries directly in my Arduino cores, and they will work for all platforms. I've done so here: https://github.com/MCUdude/TinyCore

This means that I don't have to wait for Arduino themselves to release signed binaries, which is definitely a good thing. However, now that the latest version of Avrdude will be installed on lots of computers, maybe you could look into what it would take to get libserialport to be compiled with the statically built Avrdude binaries?

[mcuee]

@MCUdude
I believe there is no easy solution now for macOS as I could not figure out how to carry out cross-build with libserialport.

Maybe some others can help.

[mcuee]

Related issues:

• Add libserialport for future avrdude release arduino/crossbuild#13
• Update libusb, libusb-compact, libftdi and hidapi library version arduino/crossbuild#14
• Cross build for Apple macOS arm64 arduino/crossbuild#17
• Make an 8.1 release arduino/avrdude-packing#35

[mcuee]

Something new to explore:
https://github.com/arduino/qdl-packing/blob/main/.github/workflows/release.yml

[stefanrueger]

Does anyone in the team have a 32-bit AVR? It's just there has been code for these parts in AVRDUDE for quite some time, but we have never tested these parts for releases, at least not since 7.0. If that works we might be able to generate quite a few AT32... parts for avrdude.conf as the 32-bit parts seems to be a lot more systematic than the 8-bit ones.

[mcuee]

@MCUdude and @dl8dtl
Just wonder if you have access to AVR32 parts. Thanks.

[mcuee]

I have the following board with a not-supported AVR32 (AT32UC3A3256).

But I need to dig out the board first. It was courtesy of Atmel back in 2011 along with AT90USBKey and AVR Dragon (for testing of libusb-win32 project as Atmel was using libusb-win32 in FLIP tools under Windows).
https://www.microchip.com/en-us/development-tool/at32uc3a3-xpld

[mcuee]

AVR32 related issues.

• AVR32 support -- low priority #1882
• Support AT32UC3L series #1484
• [patch #9573] patch to add atmelice avr32 programming support to avrdude #735
• [bug #34767] Avrdude to enable AVR Dragon to program AVR32 parts #239