Which leaves us with Windows, the operating system most readers are probably using:

While setting up a development environment for Windows is definitely feasible, this story is not about developing under Windows, but developing under Linux under Windows, i.e. running Linux in a virtual machine and handling compilation & uploading from there.

The main reason is that Linux is highly geared towards automation – of the development process itself that is. Which is not so surprising, when you consider the fact that it was built by and for software developers. With Linux, you can augment your own developer skills.

Soapbox time

With a little setup, hitting a few keys in your editing environment is all you need to save your changes, perform a cross-compilation, build the firmware image, report some statistics, and upload the result to the LPC810, or any other µC for that matter (including ATmega’s). This is not a gimmick – each of those little conventions, time savings, and habits you collect add up to becoming a major productivity boost over time.

Note that this is not about “everyone must learn editor X”. You can in fact continue to write and edit your source code in whatever tool you like: it’s quite simple to have a VM share an area on the disk and pick up changes so the same files are also visible within the Linux VM.

This is, however, a gentle way to nudge you into using the command line, “make” (a terrific workhorse for automation), and command-line based compilers, linkers, debuggers, uploaders, and terminal emulators. The Arduino IDE is very nice, but it’s single purpose. No matter how good it might be at editing and compiling and uploading, it won’t let you streamline your own workflow in ways which were not envisioned by the Arduino team.

There is much more to embedded software development than editing and compiling and uploading firmware: for example, you might wish to implement or integrate some “host-side” software, such as a central home automation server driving a network of remote Wireless Sensor Nodes. With a Unix / Linux mindset, the whole setup can become a single (but evolving) environment. How about securely downloading new code, compiling it, and uploading it to remote nodes via that same central server? Can do – it’s just a matter of designing the right workflow and automating it. Linux is good at long-term automation.

This does mean you’ll need to become familiar – and even proficient – at working “on” the command line, typing in commands at the “shell”, and setting up little routines for testing, comparing results, repeating some process, or launching debugging sessions. Even brief tasks such as diving in deep to chase a bug, can benefit from setting up some quick-and-dirty helpers, to avoid you from pressing the same buttons over and over again while going through an “edit-run-debug” cycle.

Mice are great. IDE’s are great. But in repetitive cycles with some variability, such as long-term development, or intense testing or debugging sessions, every step saved helps. Your muscles will thank you. So will your co-developers. Even your brain will thank you, as all the routines and repetitions end up in shell scripts, makefiles, and muscle memory.

Getting sources from GitHub, creating snapshots, comparing changes, installing software… once every action can be performed through the command line, it can all be automated. Anything done more than a few times, and anything you might have to do again sometime in the future is worth casting into a few lines of a “shell script”, or as part of a “makefile”.

Imagine being able to type “make help” in any project you’ve ever worked on, to get a list of actions you can perform in that project. Regardless of tools used, platforms used, or even the problem domain. All you need is one simple text file in each project directory.

Even an elaborate programmer’s environment such as the Eclipse IDE can’t quite cover the breadth of such an approach, and it’s considerably more complex to manage Eclipse than to verify that you have the “make” command installed on your (virtual) machine.

The fact is that “large” environments such as IDE’s are almost always constructed on top of command-line tools anyway. But we can look under the hood, and ignore the shiny veneer layer added on top. Sure, veneer is great and beautiful, but real power lies underneath.

Linux in a VM

So the task ahead is to create a virtual machine running Linux under Windows, and then to integrate things in such a way that they can both be used conveniently together.

We’ll use VirtualBox for this, the same product which is also available for Mac OS X (and Solaris, and Linux). Getting started is easy:

• download and install the latest version from their download page
• you also need to install the “VirtualBox Oracle VM VirtualBox Extension Pack”, to add support for USB ports within the VM (this step requires registration)

VirtualBox is open source software (originally from Sun, now Oracle), but the extension pack isn’t, even though both are free for personal use.

You now have the ability to create virtual machines. The next step is to obtain a server version of Linux. Ubuntu is solid, popular, and well-supported, so we’ll use that, as before:

• download a copy of the server edition image, preferably a 64-version – listed here

Using the server edition means that the system installs without GUI or desktop (which can be added later on, if needed). We’re going after the command-line, remember?

A server install is a fraction of the size of a full install (under 1 GB versus ≈ 3 GB disk use).

VirtualBox setup

Click on the “New” button in VirtualBox and enter a name (“minnie” in this example) and adjust the other settings to match what is shown below:

Click on “Create”, which leads you to the main window again:

(in this example, a second VM is also listed, please ignore it)

You need to “attach” the downloaded Ubuntu disk image to this VM. Click on “Settings”:

Select “Storage”, then click on the “empty” IDE controller, and then click on the CD icon next to the text marked “IDE Secondary Ma(ster)”. Select the *.iso file you downloaded.

That’s it. Your new VM is ready to launch. At this point it is still empty, but it will boot from the virtual CDROM drive, and then go through the standard procedure of setting up Linux. Be sure to select “Install to hard disk” (which is virtual, but Ubuntu doesn’t know that).

The whole installation process of Linux itself will consist of about a dozen questions and should take less than half an hour. It’s a once-only process.

At this point, you have a working Linux environment running inside Windows, although neither of them knows much (if anything) about the other.

Bridging two worlds

To complete the process, you need one more tool: an SSH terminal emulator called Putty. Please download and install it according to the instructions on its homepage.

Just to regain our perspective for a moment: the goal of this whole exercise is to run Linux under Windows, and then hook it up to the network and USB. Once configured (in VBox), the Linux part is essentially ready. We can then start / suspend / resume Linux at will.

Hang in there… there is still quite a bit of nasty (one-time) configuration left!

The second part of the equation is Putty: it can be used as a (secure) terminal window into any SSH server on the network, including the Linux VM on this machine itself. It needs to be configured to connect to the VM (which must be running).

The details of this VBox + Putty configuration are a bit too complex to include here – they are described in a separate article, see Setting up the Virtual Machine.

For now, here’s what the result of all this fiddling will look like, i.e. connecting Putty to the VM, entering a Linux login password, and typing a few standard Linux commands:

This is an application on Windows (Putty) logging into another application (VBox) running on the same Windows machine. Inside Putty, you’re in Linux – outside, you’re in Windows!

But there is one more trick which really helps keep these apart (as if the difference in appearance weren’t enough) – press ALT+ENTER and the Putty window goes fullscreen. You now have two operating systems running side by side on the same hardware.

Uploads

Even though this setup goes much further, and took quite some effort, the original goal was to upload a firmware image to the LPC810. The good news is that once the USB ports have been set up properly in Vbox, this is now the same as on a Linux or Mac OSX machine:

• plug in the (modified) FTDI board, with the breadboard setup described earlier
• type: lpc21isp -control -bin firmware.bin /dev/ttyUSB* 115200 0

Everything is back in sync, whether you’re a Windows, a Mac, or a Linux person.

Some will see a crude text-only window and regard it as the lowest common denominator, but that’s not really so: you now have the foundation on which to build any embedded software, with a world of software and automation tools within reach of a few keys.

Yes, “keys”: mice and trackpads can still be used (really!), but they play a considerably smaller role in this command-line environment.

[Back to article index]