Arduino-CLI script

[coburnw]

Just wanted to share a bash script i use to compile, upload, and monitor my board using arduino-cli on a raspberry pi zero-w.

Using ssh over wifi minimizes the time spent in the cold, dank basement lab. Other than the near painful arduino-cli compile time, it makes a pretty slick development platform. Perhaps a zero-2w would make the burn-n-learn cycle more pleasant.

Assuming Arduino-cli is already installed on your pi and a browser tab is opened to the 'command reference' section of the arduino-cli documentation https://arduino.github.io/arduino-cli/0.27/ here are my notes on how i installed DxCore:

• arduino-cli config add board_manager.additional_urls http://drazzy.com/package_drazzy.com_index.json
• arduino-cli core update-index
• arduino-cli core search
• arduino-cli core install DxCore:megaavr
• arduino-cli core list

Some notes on use:

• It seems UPDI (prog.py) needs the full featured serial port of the zero-w. I had to disable bluetooth to make that hardware available.
• To build the options string, i use the full Arduino gui to configure the DxCore options desired then use cut and paste.
• Botching the configuration of some of the fuses can be disastrous. DxCore, when run in the Arduino GUI, makes a best effort to protect the operator from themselves. When using the cli, all guards are removed.

#!/bin/bash

## BUILD
SKETCH="build.ino"
CHIP="avr64dd32"
BOARD="--fqbn DxCore:megaavr:avrdd"
CORE_OPTIONS="chip=$CHIP,millis=tcb2,printf=default,attach=allenabled,wiremode=mors,appspm=no"
FUSE_OPTIONS="clock=24internal,bodvoltage=1v9,bodmode=enabled,resetupdipins=inputupdi,mvio=enabled,startuptime=8,eesavedd=enable"

OUTPUT_DIR="output"
BUILD_OPTIONS="--warnings all --output-dir $OUTPUT_DIR"
COMPILE="arduino-cli compile $BUILD_OPTIONS $BOARD:$CORE_OPTIONS,$FUSE_OPTIONS ./$SKETCH"

## UPDI
PORT="/dev/serial0"
BAUD="115200"

HEX="$OUTPUT_DIR/$SKETCH.hex"
UPDI="python /home/pi/Arduino/hardware/DxCore/megaavr/tools/prog.py -u $PORT -b $BAUD -d $CHIP"
ERASE="$UPDI -a erase"
UPLOAD="$UPDI -a write -f $HEX"

## FUSES
#
# Consider selections carefully, double check values.
#   for instance: Fuse_5=0xC1 on db32 is safe, yet disables updi on dd32.  Yikes!
#
# the FUSE_OPTIONS above are only to inform the core of your intentions and have no
#   influence on the values below
#
# AVR64DD32 Fuses        #Register #default #description
#FUSE_0="--fuses 0:0x00"  #WDTCFG   #0x00    # watchdog and watchdog-window timeout value
FUSE_1="--fuses 1:0x04"  #BODCFG   #0x00    # 1.9V, continuous active mode only
#FUSE_2="--fuses 2:0x00"  #OSCCFG   #0x00    # internal hf osc
#FUSE_5="--fuses 5:0xD1"  #SYSCFG0  #0xD0    # NOCRC, UPDI, INPUT, retain eeprom
#FUSE_6="--fuses 6:0x0C"  #SYSCFG1  #0x08    # MVIO on, 8ms startup 
#FUSE_7="--fuses 7:0x00"  #CODESIZE #0x00    # Code section size
#FUSE_8="--fuses 8:0x00"  #BOOTSIZE #0x00    # Boot section size (0=all)

PRINT_FUSES="$UPDI --fuses_print"
UPDATE_FUSES="$UPDI $FUSE_0 $FUSE_1 $FUSE_2 $FUSE_5 $FUSE_6 $FUSE_7 $FUSE_8"

## MONITOR
# the arduino cli monitor is pretty basic...
MON_PORT=$PORT
MON_BAUD=$BAUD
MONITOR="arduino-cli monitor -p $MON_PORT --config baudrate=$MON_BAUD"

## BASH Menu
MENU_OPTIONS="Quit Compile Upload Monitor Print-Fuses Update-Fuses Erase"

select opt in $MENU_OPTIONS; do
    if [ "$opt" = "Quit" ]; then
        echo done
        exit
    elif [ "$opt" = "Compile" ]; then
        echo $COMPILE
        $COMPILE
    elif [ "$opt" = "Upload" ]; then
        echo $UPLOAD
        $UPLOAD
    elif [ "$opt" = "Monitor" ]; then
        echo $MONITOR
        $MONITOR
    elif [ "$opt" = "Print-Fuses" ]; then
        echo $PRINT_FUSES
        $PRINT_FUSES
    elif [ "$opt" = "Update-Fuses" ]; then
        echo $UPDATE_FUSES
        $UPDATE_FUSES
    elif [ "$opt" = "Erase" ]; then
        echo $ERASE
        $ERASE
    else
        echo bad option
    fi
done

[SpenceKonde]

Thanks for sharing that.

Compared to a classic AVR the fuses are almost harmless imo. What can you do that breaks anything? You can set the BOD to a voltage higher than the operating voltage, and have soldered down a part that won't tolerate any voltage high enough to take it out of BOR to change it back..... uhhh.... if it's a DD you can turn UPDI into GPIO; similar thing possible on the tinies.

If you upload through the IDE I'm able to ensure that bootsize is always 0 unless:

• Optiboot is in use - then it is 1
• Write from App to anywhere in app is enabled, in which case it's 1 and a trick is used to ensure that the two instructions needed to write to the flash are included in the first 256 words of the application (which can never be self-programmed)
• Write from App to a limited area, in which case it's 1, and no trick is used to put an entry point into the phantom bootloader.
  (in neither of the last two cases is the sketch compiled as if it had a bootloader, we just callthe first part of the app the bootloader to permit self-programming). The other fuses, I think all they can do is make the app fail to work correctly.

There may not be anything else? On classic AVRs, there were only 3 fuses, but one of them could brick it such that a programmer with modified firmware or an hv programmer, or just soft-brick it where you needed to supply a clock (low fuse), and another could turn off programming via ISP altogether and you needed to use HVSP or HVPP to recover (high fuse).

Note however that unlike a classic AVR, the bootloader is before the sketch not after. So the sketch cannot be compiled without knowing whether it will have a bootloader! If it doesn't have a bootloader, it needs to start at 0x00, but if it is using optiboot, it needs to start at 0x200 (512 words 256 instruction words, the minimum bootloader size).
Otherwise, the vectors won't be where the hardware expects so it will vector execution to the wrong place, which is typically very hard to debug. That's why I disable upload using programmer if you have an optiboot board selected. No sketch compiled for use with optiboot will work if you delete the bootloader when you upload it.
You cannot convert a hex file created for one into the other - there are too many places where you'd need to know a truly daunting amount of information about the workings of the program. It's practically a decompiler-difficulty task.

[coburnw]

I recently had to install the core manually, which is a bit of a chore. Thought maybe i'd document it here. This is from a linux point of view, so arduino's file structure might be different on other systems.

manual chip platform install

Manually install the platform if the very latest libraries are desired, you might want to develop on it, or other methods of installation have failed. The toolset is still needed, either via the arduino-cli core install described at the top of this chain, or the manual tools install below.

• The core platform is installed in the hardware directory found in the root of the users Arduino master sketch folder.
• cd ~/Arduino/hardware
• git clone https://github.com/SpenceKonde/DxCore
• git pull and git checkout work nicely.

manual azduino tools install

If possible, the arduino-cli method of core installation is highly recommended, otherwise:

• open http://drazzy.com/package_drazzy.com_index.json in a collapsible json editor (firefox tab)
• locate the package of interest, in this case DxCore, and expand.
• locate the package/tools/version of interest and expand.
• locate the appropriate tarfile for your system as specified in the tools/systems/url field. Use wget to download to a temp directory.
• tar -xf it. It should extract to its own avr folder.
• mv the contents of that avr folder to ''~/.arduino15/packages/[package-name]/tools/[tool-name]/[tool-version]'' folder where text-in-brackets is the field data from the json file. (note the effective change in folder name during move).

So im my case:

• mkdir temp
• cd temp
• wget https://spencekondetoolchains.s3.us-east-1.amazonaws.com/avr-gcc-7.3.0-atmel3.6.1-azduino8-aarch64-pc-linux-gnu.tar.bz2
• tar -xf *.tar.bz2
• mv avr ~/.arduino15/packages/DxCore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino8