Dev vs Prod

When developing systems that require longterm reliability (e.g. installation art) and must be used by non-technical users (e.g. potentially, museum staff), it is important that you separate concerns between developing a system and deploying the system. In traditional computer engineering spheres, this is referred to generally, as Dev (for development) and Prod (for production). For example, a website with a database, might have a Dev database, that allows programmers to try out new ideas without impacting users, and a Prod database, that isolates user data from unstable code.

Similarly, when working on creative embedded systems, you will want to always have a working version to fall back on for those surprise demo opportunities. When someone walks by and asks what you are working on, it is much more satisfying to be able to demo something rather than give a vague description and show them a bundle of wires that doesn’t do anything. For this, imagine Prod as checking-pointing your progress every time you are sure you have some minimal working system. Dev on the other hand is just a place to save changes as you go.

Version Control

Version control is a class of systems that give you the ability to track and manage changes to a code base over time. You will implement the concept of Dev vs Prod through version control. The tool git is the most popular tool at the moment, with Github being the most prominent server provider. Alternatives tools as such as svn, cvs, and mercurial, have their own benefits, but are mostly used to annoy your collaborators by forcing them to learn another version control system.

There are a number of good tutorials to using git online. The most important advice that any of tutorials will give is commit more often. If you do not regularly commit (and push) your work, you will eventually lose code. If you think this does not apply to you because you are careful with your hardware, you just haven’t been programming long enough. Committing your changes is especially important in the context of embedded systems development, as you will need to reach into some low-level parts of your system and may accidentally bring your system into a state where the best option is to reinstall the OS. Furthermore, more frequent commits, means you can write shorter commit messages that capture all the changes, which in turn means you will have an easier time remembering where you left off when you return to a project.

As a note, we will be using git to track and evaluate your work in this class. This will also allow the instructors to track contributions to group projects. More generally, your Github profile can be an easy way to build a portfolio of your coding projects.

Software Dev Environment

The development environment you choose is important part of working with embedded systems. Generally speaking, using a Linux system will provide the smoothest work flow. That being said, it is certainly possible to develop embedded systems using a Mac, Windows, or even ChromeOs. We will highlight some of the steps needed to step up a working development environment for each platform Later chapters will assume you are working on a Linux machine, but the general approach should be quite similar across platforms.

Linux

There are many different flavors of Linux operating systems. The stock Ubuntu LTS will usually be sufficient for the purposes of this class. If you are planning to work in any development focused job, a working familiarity with Linux is an absolute prerequisite. Linux has very few safe guards in place to protect you from yourself relative to other OSes (e.g. rm -r ~/*). If you enjoy mucking around in system configurations, there is also a good chance you will eventually want to wipe your system and reinstall the OS. This is another reason to commit your code more often to version control.

Mac

Mac is a UNIX based system, which means it shares many properties with development on a Linux machines. In particular, it provides a bash shell that will allow to experience development in a very similar style to Linux. You will likely need to disable a number of default security settings that disallow typical users of a Mac from wrecking too much havoc in their system.

Windows

Windows has traditionally lagged behind other OSes in terms of flexibility for developers. This is primarily because of the difficulty of using the terminal (cmd, PowerShell, and MingW are all attempts, largely failed, to overcome this).

The situation has changed significantly with Windows Subsystems Linux (WSL). WSL gives you access to a Linux system running as a sort of light-weight virtual machine (VM). WSL will be enough for most cases of what we cover in this class.

You might also install a virtual machine (for our purposes, a way to have an OS within an OS), but this will introduce a number of issues with connecting peripheral devices and may not be the best choice for the development of embedded systems at the level we cover in this course.

ChromeOs

ChromeOS is essentially a wrapper on top of a Linux system. ChromsOS has some native support for accessing the Linux system directly, but Crouton is better supported at the moment. Crouton allows you to access the Linux subsystem and run your favorite distribution of Linux, either via the terminal, or with the GUI.

You may run into some performance issues if your chromebook is lacking in computational power. On the other hand, this can sometimes be helpful as you will always be the first to experience and bottlenecks introduced in the code.

Cross platform support

Some system configurations will require multiplatform support. One example is a crowd sourced performance system, which allows the audience to interact with the performance via their device. In this case, as the artists, you may want the users to download an app on their phone, or access the interface via the web. Rather than manually building each frontend, a build system with cross platform support will allow you to automatically generate a frontend for all these systems. Cross platform support is a large topic, far beyond the scope of this text, however we provide here a few key tips when handling cross platform development and deployments.

If you are collaborating on a project with other developers who are using a different system then your own, you must ensure cross platform development support. That is to say, each developer must be able to run and edit the code on their own machine. One way to ensure that your changes to a project (which work on your local machine) still work on other architectures is to use Continuous Intergration (CI). CI is a development tool that allows you to set up a version controlled repository to rebuild and test your project on a variety of system architectures on every commit. One of the most popular tools for this TravisCI, which has free integration with public repositories on GitHub.

Cross compilation

In a similar vein to cross platform support, cross compilation allows you to compile code on one machine that targets another. For example, the Raspberry Pi runs on the ARM architecture, but most desktop machines at this point run x86. This means a binary compiled on your desktop cannot be ported directly to the Raspberry Pi. Generally, there are better solutions than cross compilation (e.g. copy the code to you Raspberry Pi and build on the device itself).

Hardware Dev Environment

In addition to having a dedicated setup for developing software, you may also want to have a dedicated space and workflow established for hardware development. Minimally, this means having a clean, flat surface to work.

This is especially important when this class is taught in a remote setting.