I recommend reading Part 1 to get a general understanding of what this project is trying to achieve and the first steps we took to get our system in place.
Now that we have all the tools needed to deploy firmware, we can start to build an Ansible playbook to automate deployment of new firmware to the MSP430s on the network.
Looking back at the incredibly detailed flowchart I presented in the first section:
We have compiled the tools to flash the MSP430F5529 firmware using the Raspberry Pi, now we will be setting up the Ansible playbook to automate the firmware deployment.
The hardware setup I'm using consists of two Raspberry Pis (one Raspberry Pi B and one Raspberry Pi 2), along with two MSP-EXP430F5529LP connected over USB to the Raspberry Pis. The setup:
If you want to skip ahead or run into issues along the way, check out the completed Ansible playbook on my GitHub page.
I highly recommend going through the Ansible docs to learn more about how Ansible works and best practices. The rest of the tutorial will just target our use case and explain the playbook I setup.
Installing Ansible
First off, we will need to install Ansible, the tool we will use to manage the Raspberry Pis on the network. The Ansible Docs are a great resource and should provide steps on how to install in your environment.
Hopefully this is pretty straight forward, I will be running on an Ubuntu machine but the rest of this post should be the same regardless of OS.
Setting Up Hosts File
First create a folder that will be holding our playbook. The first file we want to create is the hosts file that contains the machines we will use to deploy the firmware. So go ahead and create a file in your directory called hosts and add something like this to the file:
[pis]
192.168.0.47 ansible_ssh_user=pi
192.168.0.48 ansible_ssh_user=pi
You will need to swap out the IP addresses for the names of the machines you will be using. If you're only using one machine that's fine, Ansible will work the same way no matter how many machines we have in our system. Also note the ansible_ssh_user keyword next to each machine, this defines the user you use to ssh into the machine so change it if you're not using the default raspbian user. Ansible uses ssh to configure the machine.
After creating the file I recommend pinging the machines to ensure ssh is working and Ansible can communicate with the machines. Try running:
ansible -i hosts all -m ping
Let's break down this command. First we tell ansible to use our hosts file instead of looking in the Ansible installation with -i hosts. Next we tell ansible to run the commands on all hosts found in the hosts file. Finally we define the module to run with -m ping.
Setting Up Roles
Now that Ansible can communicate with the Raspberry Pis on the network we will now define a playbook to deploy the firmware. Our playbook will consist of two roles that machines can be assigned to. The first role is "common" which defines some useful packages and settings we want on all our machines. The second roles is the "mspdebug" role whid is designed to be a reusable role that installs all dependencies to get mspdebug working on a Raspberry Pi, including installing the mspdebug binary we build earlier.
The "Common" Role
For this simple example, all machines we are configuring are also deploying firmware. In a more complex setup, if you wanted to keep one machine as a "build" machine for building the firmware or mspdebug then it would need a separate set of packages installed and environment setup. This is where the "common" role comes into place. This role can define configuration that happens across all machines in the setup, not just ones dedicated to firmware development.
So start off by creating a directory for the common role and the tasks we will be creating.
mkdir -p roles/common/tasks
In this directory we will create a main.yml file that defines the tasks to complete. Here is my example:
---
# Generic things to get machines up to date and usable
- name: Install packages
apt:
pkg={{item}}
state=installed
sudo: yes
with_items:
- vim
- zsh
- git
- tmux
- htop
- name: Change default shell
user:
name=pi
shell=/usr/bin/zsh
sudo: yes
This configuration is pretty personal and is just some general packages I want installed if I need to work on the machine. The first task installs useful optional packages and the second task changes the shell to zsh. Feel free to configure these to your preference. The playbook uses the apt module and the user module to install packages and configure the user.
Ideally our firmware deployment system will be completely automated... but if issues start happening having a decent toolset already installed on all machines will help debugging, that's where the common role comes in handy.
The "MSPDebug" Role
The next role our Raspberry Pis will use is a mspdebug role. This role will use the mspdebug binary we built in the first tutorial to actually program our firmware to the MSP430 LaunchPads.
mkdir -p roles/mspdebug/tasks
In this directory we will have three separate files. A playbook to install our mspdebug application and a playbook to download the firmware. This separation is necessary so that you can update the firmware without having to reinstall mspdebug. At the same time you can also update mspdebug without updating the firmware of the connected LaunchPad.
We also need to create a directory to keep all the files we'll be copying over to the server in.
mkdir -p roles/mspdebug/tasks
Looking back at my example on GitHub, you can see I have checked in the binaries we built in the last post.
In the tasks directory for mspdebug we can create a install.yml file that installs mspdebug. Here is my example:
---
# Playbook to install msp debug
- name: Install libmsp430.so
copy:
src=libmsp430.so
dest=/usr/local/lib
sudo: yes
- name: Install mspdebug
copy:
src=mspdebug
dest=/usr/local/bin
mode=775
sudo: yes
- name: Add /usr/local/lib to LD_SEARCH_PATH
lineinfile:
dest=/etc/ld.so.conf
line=/usr/local/lib
state=present
sudo: yes
register: ld
- name: Rebuild LD cache
command: /sbin/ldconfig
sudo: yes
when: ld.changed
This playbook is broken into 4 steps.
- Copy the
libmsp430.solibrary to/usr/local/lib - Copy the mspdebug binary to
/usr/local/binand make it executable - Add
/usr/local/libto the library search path - Rebuild the library path if we needed to change the library search path
In this playbook I'm using the copy module which simply copies files to all remote servers as well as the lineinfile module for simple edits to a text file on remote systems and the command module to execute arbitrary commands. Once the installation playbook has run, all dependencies will be met and the Raspberry Pi will be ready to flash an MSP430.
Alongside the install.yml playbook I also created an update_firmware.yml playbook to actually run the commands to download to the MSP430. Here is my playbook implementation:
---
# Playbook to update firmware on connected devices
- name: Create a directory to store the firmware
file:
path=/var/ansible
state=directory
owner=pi
sudo: yes
- name: Copy the firmware to the hosts
copy:
src={{ firmware_name }}.out
dest=/var/ansible
- name: Download the firmware to the devices
shell: mspdebug tilib --allow-fw-update --force-reset "prog /var/ansible/{{ firmware_name }}.out"
sudo: yes
The new feature in this playbook is my use of ansible variables. Here I use the {{ firmware_name }} variable to substitute the filename of the firmware image. This way, when a new firmware image comes along I can just update the variable, and it will propagate through the playbook.
Finally we need a high level playbook to map the roles to our different hosts. In our example every host we connect to will be deploying firmware. My top level playbook site.yml consists of the following:
---
# This playbook deploys firmware to all hosts
- name: Configure and deploy firmware
hosts: all
remote_user: pi
roles:
- common
- mspdebug
This playbook simply tells ansible that all hosts will have the "common" and "mspdebug" role.
If you're following along I recommend comparing your own setup to my GitHub repository.
Running the Code
Now that we have all of our ansible configuration written and the tools we need compiled for the Rapsberry Pi we can start the automatic deployment of our firmware.
To recap, the playbook will do the following:
- Install some common tools on all the Pis (vim, tmux, etc...)
- Install an ARM compiled mspdebug on all the Pis, along with associated libraries
- Copy the firmware to the Raspberry Pis
- Invoke mspdebug with the firmware and flash the MSP430
To run the playbook we can invoke it using ansible-playbook:
ansible-playbok -i hosts site.yml
This tells ansible which hosts file to use and the playbook to run. When we are ready to change the firmware to a new version we can either
- Update the
group_vars/allfile to include the name of the new firmware image - Pass the name of the new firmware image from the command line when invoking anible-playbook.
To pass the firmware image name as a variable on the command line you can invoke:
ansible-playbook -i hosts site.yml --extra-vars "firmware_name=Blink_v2"
To see a quick demo of the setup in action I program two different firmware images, one that blinks a red LED and one blinking a green LED.
Next Steps
There are a ton of ways to improve this setup. Some next steps might be:
- Flash multiple MSP430s connected to a single Raspberry Pi
- Dedicate a Raspberry Pi on the network to building mspdebug and needed libraries. Once an update occurs, push that to all Pis in the system
- Keep a database of which MSP430s are connected to which Pis, deploy different firmware to different connected devices
- Integrate with a Continuous Integration tool like Jenkins, so that if all Jenkins tests pass, the firmware gets automatically deployed
- Flash a device over BSL using the GPIO pins from the Raspberry Pi rather than the on board debugger on the LaunchPad
- Use ansible tags to skip parts of the playbook that do not need to be run every time when deploying firmware