Micro-controllers are simple boards that can run C/C++ programs. They are easy to use and amazingly power efficient, but their simplicity typically makes them incompatible with
resin.io since the resin service requires that a board can run Linux in order to manage Linux containers. A couple of weeks ago, however, one of our users explained how they were using resin.io to update their Raspberry Pi and an attached Arduino.
I've expanded their explanation slightly to create this guide to an Arduino update mechanism within the resin.io ecosystem.
The basic workflows is this:
- Connect your Arduino to a resin.io device via USB-serial.

- Change some Arduino code.

- Push your your project to resin.io. This uses a Makefile to build your Arduino binary(from
blink.ino
) on our builders and ship everything to the resin device in container.

- When the container lands on the device check if there is a difference between the new version of Arduino code and previous version (which is stored in
/data
to persist through resin updates)
- If there is a difference raise a flag to signal the uploading of the binary to the Arduino via the serial cable.

- Arduino is updated with new code (a longer delay in the blink sequence).

Let's take a look at some code
Because the
Makefile and resin.io abstract all of the tricky stuff, the logic is actually very simple.
A Dockerfile is the basis for all resin projects, so lets start there. First we need to install some native dependencies in our Dockerfile:
RUN apt-get update && apt-get install -y --no-install-recommends \
arduino \
g++ \
gcc \
usbutils \
make
Next, we trigger a build of our Ardiuno firmware from our Arduino source file using this
"all-in-one" Makefile. It allows you to pass build configurations via environment variables. As you can see we are building for the
leonardo
board. Full documentation on the Makefile can be found
here.
WORKDIR /app
ENV ARDUINODIR /usr/share/arduino
ENV BOARD leonardo
RUN cd blink && make
Once the container hits the device we'll need to run a script to compare the code in blink.ino
against the previous version. We declare our entry point like so:
CMD ["bash","start.sh"]
In start.sh
we have a flag PROGRAMMER
which indicates whether there is an update for our Arduino. If the flag is raised we run make upload
which uploads the binary via serial connection. We then store our new blink.ino
in /data
. This is important because resin.io treats /data
similar to Docker sub-volumes, which means that the contents survive container updates - this is important when comparing new code to old code.
diff /app/blink/blink.ino /data/blink.ino || PROGRAMMER=1
if [ "${PROGRAMMER:-}" == "1" ]; then
echo $PROGRAMMER
pushd /app/blink
make upload && cp blink.ino /data/
popd
fi
You can view the write progress from the resin logs:
** Note: I've stripped out a few extraneous details. **
12.01.16 13:04:58 [+0000] Connecting to programmer: .
12.01.16 13:04:58 [+0000] Programmer supports the following devices:
12.01.16 13:04:58 [+0000] Device code: 0x44
12.01.16 13:04:59 [+0000] avrdude: AVR device initialized and ready to accept instructions
12.01.16 13:04:59 [+0000] Reading | | 0% 0.00s Reading | ################################################## | 100% 0.01s
12.01.16 13:04:59 [+0000] avrdude: Device signature = 0x1e9587
12.01.16 13:04:59 [+0000] avrdude: reading input file "blink.hex"
12.01.16 13:04:59 [+0000] avrdude: writing flash (4756 bytes):
12.01.16 13:04:59 [+0000] Writing || ################################################## | 100% 0.59s
12.01.16 13:04:59 [+0000] avrdude: 4756 bytes of flash written
12.01.16 13:04:59 [+0000] avrdude done. Thank you.
And there you have it! Updating an Arduino using resin.io.
You can find all the code here.
There are a ton of interesting use cases for this tutorial, such as using the Arduino as an ADC like
Emonpi has done.
Let us know where you take this. Programming the Arduino via Bluetooth would be a great fork ;)
If you have any questions, the team will be hanging out in our gitter room.
Note
If you want to pin the programmer to specific port e.g /dev/ttyACM0
then you'd add another environment variable, like so: ENV SERIALDEV /dev/ttyACM0
.