Arduino communication with ROS via UART

Question

I am trying to program an Arduino Mega(Crius) from a Minnowboard Max A2 via an UART (Hardware Flow Control Off) interface.

I can successfully communicate with the ROS (robot Operating System) on the Ubuntu 12.04 installed on the Minnowboard Max via the UART1 port available on the Minnow Board.

The Crius UART has a FTDi compatible port with a DTR pin. Unfortunately the MinnowBoard does not have any DTR pin to communicate with the Arduino (Only CTS/RTS pins for 1 of the 3 UART ports). Thus I cannot upload any sketch to the Arduino via the Minnowboard over the UART. I must always connect to the onboard FTDi-USB chip of the crius and upload the sketch.

Is there any workaround to upload the sketch to the Arduino via the UART from the Minnowboard ?

Answer 1

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:

1. Set the GPIO to OUTPUT
2. Set the GPIO to LOW
3. Delay a few ms
4. Set the GPIO to INPUT
5. 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.