You can use any GPIO you like on the Minnow to trigger a reset of the Mega to initiate the bootloader. The Yún does just that to program the on-board ATMega chip through a script they have chosen to call "run-avrdude":
#!/bin/sh
echo 1 > /sys/class/gpio/gpio21/value
avrdude -q -q -c linuxgpio -C /etc/avrdude.conf -p m32u4 -U efuse:r:/tmp/efuse:d
read EFUSE < /tmp/efuse
rm -f /tmp/efuse
if [ "x$EFUSE" = "x203" ] # 203 = 0xCB
then
avrdude -c linuxgpio -C /etc/avrdude.conf -p m32u4 -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xCB:m -Uflash:w:$1:i $2
else
avrdude -c linuxgpio -C /etc/avrdude.conf -p m32u4 -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xFB:m -Uflash:w:$1:i $2
fi
echo 0 > /sys/class/gpio/gpio21/value
You could do something similar to initiate the bootloader on the remote board - connect any GPIO pin to the RESET line of your Mega board, then perform the following logical actions:
- Set the GPIO to OUTPUT
- Set the GPIO to LOW
- Delay a few ms
- Set the GPIO to INPUT
- Run avrdude.
By setting the GPIO to INPUT you are emulating an open-drain output. If you were just to drive the GPIO HIGH it would hold the RESET pin HIGH and you wouldn't be able to use the USB interface, nor the RESET button. By setting it to INPUT it is then effectively disconnected from the RESET pin so won't interfere.
The Yún again has a script that works in that way, "reset-mcu":
#!/bin/sh
echo 18 > /sys/class/gpio/export
echo "high" > /sys/class/gpio/gpio18/direction
echo 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio18/value
echo 18 > /sys/class/gpio/unexport
I have a similar setup to you but using a BeagleBone Black and a PONTECH Quick240 PIC32 based controller. In my IDE UECIDE I set up a special board definition with the following programmer added to it which performs the manual reset through GPIO and runs the upload program (pic32prog) all in one operation:
upload.local.name=Local upload
upload.local.using=script
upload.local.script.0=__builtin_bullet::Entering programming mode...
upload.local.script.1=__builtin_gpio::7::low
upload.local.script.2=__builtin_delay::100
upload.local.script.3=__builtin_gpio::20::low
upload.local.script.4=__builtin_delay::100
upload.local.script.5=__builtin_gpio::20::hiz
upload.local.script.6=__builtin_delay::100
upload.local.script.7=__builtin_gpio::7::hiz
upload.local.script.8=__builtin_delay::100
upload.local.script.9=__builtin_bullet::Uploading sketch...
upload.local.script.10=${core.root}/tools/linux_arm/pic32prog::-S::-d::${port}::-B::${upload.maxbaud}::-p::${build.path}/${filename}.hex
upload.local.script.11=__builtin_bullet::Resetting board...
upload.local.script.12=__builtin_delay::100
upload.local.script.13=__builtin_gpio::20::low
upload.local.script.14=__builtin_delay::100
upload.local.script.15=__builtin_gpio::20::hiz
sketch.upload=local
That one is a little different in that you have to hold a second GPIO LOW while you reset the board to initiate the bootloader, hence the two GPIOs in use there.