Closed MCUdude closed 1 year ago
To sum up my somewhat vague question and add a few others:
mainline
? If yes, why does it differ so much from the other branches?avrdude 6.3-arduinoN
version so I can help out getting these fixes/improvements back to the main repo?@MCUdude Thanks for your interest, I would be very glad if Arduino could be shipping an unmodified avrdude version indeed.
However, I'm not quite involved in this repo, so I'll have to defer to @facchinm for your questions.
Hi @MCUdude , closing this repo and posting all the relevant patches to the official avrdude's revamped home is still one of my wildest dreams :slightly_smiling_face: . Unfortunately I'm not involved anymore in tool packaging inside Arduino; the request to provide upstream builds and create the PRs is in @arduino/team_tooling backlog but I can't give an estimation of its deadline.
About the patches, some of them were only needed by the Yun peculiar setup, while others were part of a strange project to be able to program both 16u2 and 328p with the same programmer on a Uno.
The reason why the branches diverged so much is that we were proving prebuilts for megaAVR (atmega4809 and friends) while the feature was not yet mainlined; when it finally happened, the branches had diverged so much that backporting the new relevant patches (with the extra svn-to-git passage) was easier than rebasing on master.
Thanks for your reply @facchinm!
When looking at the Arduino avrdude changelog and comparing it with the official Avrdude repo, pretty much all improvements have made it back to the official repo. Do you think it would be possible to convince the tooling team to ship Avrdude 7.0 once released, with modifications if needed? For developers like me that are providing 3rd party Arduino cores, the 7.0 release is a big deal.
My favorites:
-c arduino
programming optionThanks so much for your initiative @MCUdude, and for the excellent work you have been doing on AVRDUDE!
I can comment on the little piece of this mess that I had some involvement with:
Way back in 2013, @kcuzner implemented a linuxspi
programmer for AVRDUDE (documented, patch). This awesome thing allows you to use the native SPI interface of a Linux SBC as an efficient programmer.
Upstream AVRDUDE was not quick to act on this, but Arduino pulled it into their build in 2016 (https://github.com/facchinm/avrdude/commit/d7eacf839c4e040b155b2903f605d94201fc5463).
It came to my attention via a request to add it as one of the official programmer options: https://github.com/arduino/Arduino/issues/7795
While I was experimenting with that possibility, I discovered there was a problem with the implementation that made it unusable in that application (https://github.com/kcuzner/avrdude/issues/10). I submitted a pull request (https://github.com/kcuzner/avrdude/pull/17) to the repository where the patch was staged with the thought that the patch author would be the most appropriate to decide on whether it was the right approach, and if so to push that into the upstream submission. That was accepted and so I also submitted it to Arduino's AVRDUDE code base (https://github.com/facchinm/avrdude/pull/2), since it already contained the original linuxspi patch that contained the bug.
A patch for a revised implementation of the linuxspi programmer was later submitted upstream (https://savannah.nongnu.org/patch/?9816) and this was eventually merged in https://github.com/avrdudes/avrdude/commit/40b0b104d6967ca75929706996b3dede304b9b25.
I have tested the upstream linuxspi programmer from the current nightly build of AVRDUDE and found that https://github.com/kcuzner/avrdude/issues/10 does not occur. So my diverging commit https://github.com/facchinm/avrdude/commit/aa0d28f774147fb03f8b18cd065586c7a93a2b0b can safely be disregarded for the purposes of the upstream sync initiative.
I found there is a breaking change to the format of the -P
flag. The port format supported by the linuxspi programmer of Arduino's AVRDUDE is /dev/spidev0.0
, while the upstream linuxspi uses the format /dev/spidev0.0:/dev/gpiochip0
.
The formats are incompatible in either direction:
Using upstream AVRDUDE with the port format supported by Arduino's AVRDUDE:
$ avrdude -p atmega328p -c linuxspi -U "flash:w:blink.hex:i" -P /dev/spidev0.0
avrdude: error: Unknown port specification. Please use the format /dev/spidev:/dev/gpiochip[:resetno]
avrdude: opening programmer "linuxspi" on port "/dev/spidev0.0" failed
avrdude done. Thank you.
Using Arduino's AVRDUDE with the port format supported by upstream AVRDUDE:
$ avrdude -p atmega328p -c linuxspi -U "flash:w:blink.hex:i" -P /dev/spidev0.0:/dev/gpiochip0
avrdude: error: Unable to open SPI port /dev/spidev0.0:/dev/gpiochip0
avrdude: error: Unable to open SPI port /dev/spidev0.0:/dev/gpiochip0
[...]
avrdude: error: Unable to open SPI port /dev/spidev0.0:/dev/gpiochip0avrdude: error: AVR device not responding
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
There is also an incompatibility between the -b
flag used by the linuxspi programmer of Arduino's AVRDUDE and the same flag used by the linuxspi programmer of upstream AVRDUDE, but I believe that to be an upstream bug, which I have reported here: https://github.com/avrdudes/avrdude/issues/927
Thanks for the information @per1234! Avrdude is written in "classic" C, so the code is fairly easy to read and understand IMO.
I found there is a breaking change to the format of the -P flag. The port format supported by the linuxspi programmer of Arduino's AVRDUDE is /dev/spidev0.0, while the upstream linuxspi uses the format /dev/spidev0.0:/dev/gpiochip0.
I don't think it would be easy to convince Jörg to accept /dev/spidev0.0
as a valid SPI port, but I don't think it's really a problem since /dev/spidev0.0:/dev/gpiochip0
can be used. AFAIK Arduino doesn't prove an official solution that relies on linuxspi
for uploads. If we are able to get a default SPI port into Avrdude, the -P
wouldn't even be necessary if using a Raspberry Pi.
I think you can read the latest (and briefest) on the matter over at https://github.com/arduino/avrdude-build-script/issues/15#issuecomment-1541556556 Maybe you could even get some of this forever needed testing going.
I'm closing this issue as the Arduino Avrdude "fork" has been moved over to arduino/avrdude-build-script
Hi @facchinm and @matthijskooijman!
Ever since the Avrdude project was moved over from Savannah to Github, it has seen numerous bug fixes and improvements. One of the most important ones is support for "pyupdi/pymcuprog" style UPDI programming, where a USB to serial adapter can work as a full-blown UPDI programmer with just an external resistor. A new major release, Avrdude 7.0 is soon to be released, and it would be great if Arduino could start bundling 7.0, or at least a fork, where all 7.0 features are present.
I believe this repo exists because the Avrdude project was "dead" for several years, and you needed a way to fix reported issues. However, the commit history in this repo is a bit of a mess and scattered over several branches, where some of the commits from Savannah were later reverted without explaining why.
I was hoping that you perhaps could put in a little effort and copy over some of the "Arduino improvements" over to the official Avrdude repo. I'll be glad to help, but I'm having a real hard time keeping track of which "Savannah commits" have been included, ignored, or reverted, or which commits are real improvements that never made it back to Savannah.
Thanks!