Arduino-cli: support to ATmega328P (Old Bootloader)

[amamory]

Bug Report

I tried to upload the blink example to an Arduino Mega and it worked. However, when I tried to do the same with Arduino nano, the upload wont work with arduino-cli. This upload works when using arduino IDE because I can set the type of bootloader with Tools > Processor > ATmega328P (Old Bootloader). As far as I know, this is not possible with arduino-cli.

Current behavior

./arduino-cli upload -v -p /dev/ttyUSB0 -b arduino:avr:nano MyFirstSketch/

avrdude: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

     System wide configuration file is "/home/lsa/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/etc/avrdude.conf"
     User configuration file is "/home/lsa/.avrduderc"
     User configuration file does not exist or is not a regular file, skipping

     Using Port                    : /dev/ttyUSB0
     Using Programmer              : arduino
     Overriding Baud Rate          : 115200

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00

Expected behavior

It seems that arduino-cli only uploads with baud rate 115200, but the Nano requires 57600 bps.

Environment

• CLI version (output of arduino-cli version):
  arduino-cli: arduino-cli Version: 0.7.1 Commit: 7668c46
  arduino version: arduino-1.8.10
• OS and platform: Ubuntu 18.04

[per1234]

It's already supported, you just need to specify the cpu option atmega328old in the FQBN:

./arduino-cli upload -v -p /dev/ttyUSB0 -b arduino:avr:nano:cpu=atmega328old MyFirstSketch/

More information: https://github.com/arduino/arduino-cli/issues/138

[ericonr]

This should be documented more clearly somewhere, though. I only found out about it because I managed to find this issue.

[rustbuckett]

Agreed. I've been at this for 3 hours. I can finally go to bed.

[raczey]

Do you know that you need to push REST button on Arduino just before you start uploading a new sketch?

[ubidefeo]

@raczey this has not been true for several years.
probably for outdated or badly manufactured boards it might still be necessary, but all our current offering does not require that

[raczey]

@ubidefeo Well, I have this issue with Power_Management_HAT from Waveshare while communicate directly RPi <-> Arduino via UART. So it means it is a 'badly manufactured' board? :(

[matthijskooijman]

@ubidefeo Well, I have this issue with Power_Management_HAT from Waveshare while communicate directly RPi <-> Arduino via UART. So it means it is a 'badly manufactured' board? :(

That HAT is an Arduino-like board in itself (on top of a rpi), so whatever holds for official boards does not necessarily hold for that board at all. In this case, I see that the board you linked can be programmed through USB using a CP2102 USB-to-serial, which does have the auto-reset set up correctly, but you can also do UART (and/or serial printing) from the Rpi UART directly, which seems to have no provision for autoreset. So in this particular case, it's just a limitation of the way the Rpi UART is used (In this case, I would not necessarily call it bad design, since doing the autoreset properly there is likely a bit more tricky). Maybe they intended this Rpi-UART link for serial output, rather than also for firmware uploads.

In any case, none of this auto-reset talk is at all relevant to the issue at hand, so let's not waste more words on this here.