What's the current best practice for using a Raspberry Pi (say, a 4) as a ISP programmer to flash MCUs like the ATmega16U and ATmega328P on UNOs and clones?
Is linuxspi still a thing? Is powering the AVR off the Pi's 3V3 rail still recommended? Is installing the Arduino IDE enough or do you need a custom build of avrdude?
Or would one have more success and reliability connecting the Pi to an Arduino in "Arduino as ISP" mode?
Probably this one would be the best solution, I can't answer any of the other questions though.
Buy a USBasp and plug it into the PI's USB port.
Should be fine. The AVR won't need much current.
To use the PI's SPI pins, you would need a custom version of AVRdude. Developing that would require very high level of expertise and lots of time. Just buy a USBasp.
The linuxspi programmer is available in the versions of AVRDUDE distributed by Arduino from 6.3.0-arduino14 and newer (Arduino includes some additional patches in their AVRDUDE build):
There was a bug in the initial implementation of the linuxspi programmer that caused it to fail when the command was not ran as root:
That bug was fixed at the time the linuxspi programmer patch was merged in the official AVRDUDE codebase:
However the introduction of that fixed implementation of linuxspi came after the version of AVRDUDE that Arduino is using in the official boards platforms. It is only available in version 7.0.0 and newer of AVRDUDE.
Even though they are not yet used by the official Arduino boards platforms, Arduino does already produce builds of AVRDUDE 7.x, including the Linux ARM builds needed for use on a RPi SBC:
You will also have it already on your machine if you are using the latest version of any of the MCUdude board platforms (e.g., MiniCore).
If you check section 26.3 of the ATmega8U2/16U2/32U2 datasheet and section 29.3 of the ATmega48A/PA/88A/PA/168A/PA/328/P datasheet, you'll see that 3.3 V is out of spec for these microcontrollers when clocked at 16 MHz.
So technically it is not recommended. However, at least with the ATmega328P, we know from experience that it is possible to use the microcontroller under these out of spec conditions. There is a possibility that it will work unreliably under these conditions, which makes it inadvisable to run under these conditions during normal operation even if it seems you can get away with it after some quick experiments. However, it is more reasonable to do so only temporarily for the purposes of occasionally flashing the board. It is likely that even if there is some unreliability, that will only manifest as a failed flashing process that will succeed after a retry or two.
I don't have experience using the ATmega16U2 family of chips under these conditions so I can't guess at whether it is feasible or not. The safe approach is to power the target board at 5 V and use a level converter between the RPi and the target.
It seems that @liteyear is already familiar with the subject, but in case anyone else is interested in the linuxspi programmer in general, this article by SparkFun is a good read:
https://learn.sparkfun.com/tutorials/raspberry-pi-stand-alone-programmer
Wonderful food for thought thank you!
The advice about avrdude 7 and MCUdude is well received and got me thinking and researching further.
I see the ATmega16U datasheet has exactly the same clock speed / supply voltage graph. However, it also reminded me I use the Arduino default 4.3V BOD fuse setting! So I have doubts about compatibility/convenience.
The USBasp advice is also well received. I'm cautious, because other than being somewhat redundant, it's really not much different from the Arduino as ISP I use now, and I've had all sorts of flakey reliability issues that turn out to be dependent on USB hubs / adaptors. Still, I really like dedicated hardware for this sort of thing, so I'm still leaning this way. I'm currently considering the more expensive Pololu equivalent, if only because it's ready to go with the 6-pin cable.
Thanks for the advice so far. Please keep the tales of success/caution coming.
FWIW, I've now tried the USBasp and the Pololu variant in anger. Conclusion: they work, but each bring their own special bundle of glitchiness and special condition requirements. At least we found which way to hold the tongue to get fairly predictable behaviour from the USBasp, so will persevere. It's possible the ribbon cables have something to do with the glitchiness too.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.