raspberry pi

Accessing Raspberry Pi GPIO Pins (With Swift)

You can do quite a bit with GPIO (general purpose input/output) pins on devices like the Raspberry Pi and Beaglebone. Here I’ll show you how to set it up to perform a couple of simple tasks, like blink an LED and read the temperature from temperature sensor called the DS1820B. If you don’t know much about electronics, that’s OK – there’s nothing major here, just a few points to follow as you go along. I’ll explain them in further detail at the right time.

Setting Up

These examples will focus on the Raspberry Pi, because that’s what I have easiest access to, but with some minor modifications they could work with a Beaglebone black. At the time of this writing, Swift is available for the Raspberry Pi 2 & 3, including package manager. You can download the Swift 3.0 binaries from Joe Bell’s Jenkins build if you don’t wish to compile Swift yourself. I personally like to keep a couple versions of Swift builds and symlink to the “current” one, with ~/swift/current/ (a symlink) listed in my bash profile’s $PATH  list. That way I can change the symlink at will.

Side note: I work with both Raspbian and Xenial (Ubuntu/ARM). At the time of this writing, there appears to be some issue getting the 1wire interface to work on Xenial, though I am able to compile swift completely, which proves difficult on Raspbian. Basic functionality, like blinking LEDs, seems to work on Xenial, but I haven’t had an opportunity to try other interfaces. On the surface level they appear available and usable.

Sanity + Smoke Test

The ribbon cable between the Raspberry Pi and the breakout board can be inserted either way (right or wrong), so it’s important to do the check first. Hook up your jumper cables from the 3.3 or 5V pin on the breakout to the breadboard row containing your 220Ω resistor. Following this diagram below. Make sure your LED is inserted properly (long let at positive). Click for full-sized view.

Cobbler sanity check

Sanity check. If your ribbon cable and jumpers are inserted properly, the LED should light up. This configuration connects the 3.3V pin directly to the resistor/LED. It should light up if all is connected properly.

Next, connect the jumper from 3.3V to the row corresponding to GPIO Pin 17.

LED Hookup

It may be worthwhile to install WiringPi so you can test GPIO connections via the command line rather than compiling swift every time. In our example above with pin17 connected to the LED:

This should work for you, but I did run into some issues from time to time where it simply refused to work properly (I’m sure I did something wrong!).. You should see the LED turn on.


Check out SwiftyGPIO and see how the examples are configured. It’s quite straightforward. Using this, we’re going to build on them to read from a 1-wire digital temperature sensor (DS18B20). Let’s get started configuring the Pi to user the 1-wire interface.

First, a brief overview. You define the GPIO type by passing an enum value for your hardware. In this case the .RaspberryPi2 applies to both the Pi2 and Pi3. We’ll go with that. We’ll then keep a reference to the GPIO #17 pin, as in the above smoke test. Note that this is the actual GPIO number, not the number as it would apply to the pin number on the circuit board.

You set the direction (either IN for things like sensors, or OUT for things like LEDs)

and finally turn on the LED,

From the SwiftyGPIO examples, let’s look at what a continuously blinking LED program would look like, modified for our hardware example.

You can include the SwiftyGPIO.swift  file next to your main and compile the whole with swiftc *.swift && sudo ./main

The programming really isn’t very hard, so let’s move on to our temperature sensor.

Hardware Config

First you need to enable GPIO on the Pi, and to do that you need to write some configs to the boot config file. If you’re running Raspbian (and expect to use pre-build binaries), you’ll need to edit the /boot/config.txt  file; if you’re on Xenial/Ubuntu, it’s /boot/firmware/config.txt  .

add this line to the end, if it’s not already in there:

Reboot the machine.

You’ll then need to check that everything worked just fine

The output will look something along these lines,

That t= value is degrees C * 1000. We’ll end up parsing it in the readTemp program.

See this set of articles for further details.

Temperature Sensor

Here’s a little program (http://github.com/iamcam/swiftyArm/readTemp) with 1-wire temp sensor (DS18B20) and two status LEDs. Follow the wiring diagram below. I’ve included the Pin numbers on labels because sometimes the Fritzing pin numbering can be a bit blurry. The gist of this little project is to perform a temperature reading whilst making an LED blink on a separate thread



Assuming you have a functioning Swift build on your Pi, you should be able to download the repo, build the readTemp project with package manager, and run the output.

Then execute it:

Some lights will blink and partway through, the read status LED will illuminate and the temperature will print out to the command line,

27.562 °C / 81.6116°F

And that’s about it. Besides getting a stable Swift working, this project wasn’t very hard. Getting the wiring set up properly is probably the most difficult. Surely in a few months time we’ll have a stable Swift that’s less of a moving target.

Compile Swift 3.0 on Your ARM computers (Raspberry Pi, BeagleBone Black, etc)

I often write these blog posts in part to remind my future self how I did something as well as for the benefit others. Today I’m looking at what’s involved with compiling Swift for ARM devices, namely the popular Raspberry Pi. While these are meant for the RPi, they should also apply generally to devices like the BeagleBone Black. Before you get started, you should be reminded that Swift3 is very much an alpha-level project, especially on ARM devices. There are times when swift won’t even compile properly, or even if it does compile, there could be issues running it smoothly. armv7 devices (BeagleBone Black, Raspberry Pi2, and others) seem to be most reliable; armv8 (Raspberry Pi3) are in the weeds, so to speak, because there’s been little effort toward that architecture due to resources. It will probably work in the future, just not as well in June, 2016. Now that you’ve been adequately warned, let’s begin.

[NB: If you’re setting up a new system, start over on Part 1: Readying Your Pi for Swift]


  • Making a Swapfile
  • Installing required components
  • Getting and building the source
  • Cross compiling
  • Conclusion


Make a Big Ol’ Swapfile

  • You’ll need to have a lot of memory to compile swift, and while the Raspberry Pi has 1GB, it’s not enough. Let’s start with increasing the swapfile size by following the from over here. (Paraphrased below)

Edit the configuration file at /etc/dphys-swapfile


Find  CONF_SWAPSIZE and set the value to 2048 :

Reboot or stop/start the dphys-swapfile service

It may take several minutes, so be patient.

One point some have noted is that having a large swapfile as this lends to decreasing the lifespan of the memory card due to the large amount of writes you’d expect in a swapfile. It’s a risk you run, but 32GB memory cards are inexpensive. Keep backups if it concerns you

Required Components

Next, we need to install required components (CMAKE, ninja, & other dev tools) – from the Swift README


Once that is finished, clone Joe Bell’s package-swift repo on your Pi. This provides some handy shortcuts for building swift on ARM devices: https://github.com/iachievedit/package-swift.git


Start a new screen session so that we don’t have to remain logged in during the whole build (in other words, if you lose your connection, you can resume where you left off)

To resume the screen session, simply log back in and type


Get and Build the Source

Inside the Package Swift repo, run the get script to download the appropriate repos used for arm builds

or (it doesn’t really matter much)

Just one note – notice the tee command at the end. That takes the input and write it to a file. Since the Swift build process doesn’t output build logs, we pipe the build output to tee so we can save it, in case there was an error along the way. Sometimes these errors are minor and occur after the swift binaries successfully build. It’s important to know.

Now, it’s time to wait several hours for first build. You remember to enter a screen session, right?

When it’s all said and done, you should be able to run swiftc on a simple helloWorld.swift



Attempting to build Swift on these low-powered devices is a noble effort, but it takes a very long time. I personally don’t like having to wait several hours to find out the build failed. That’s where cross-compiling comes in. This process means you build binaries on one platform (for example, a Mac/Intel) that work on another (Linux/armv7). Usually takes less than an hour. The following instructions are meant to be executed on a Mac.

First, you need to install dpkg so the build system can create a proper debian package


Next, make sure you have Joe Bell’s Package Swift repo, mentioned above: https://github.com/iachievedit/package-swift.git

Download all the appropriate repos and branches using ./crosscompile_get.sh

Next, it’s time to build: ./crosscompile_build.sh -t linux-armv7

When the build is complete, copy it over to your Pi. If all went well, you should have functioning Swift binaries*.

*Of course, there may still be issues with Swift on ARM itself – it’s still alpha.


I hope this tutorial was helpful. At the time of this writing, there were still several considerable issues with Swift on ARM devices, but it is possible to compile it yourself. If you continue to run into issues, it may be worthwhile to check back at Joe’s Website for updates and downloadable binaries.

Currently, Swift on Raspberry Pi3

I’ve taken recent interest in working on the Raspberry Pi now that Swift is open source. Given the amount of products built specifically for the Pi, there’s a huge potential for new, fun projects. DIY electronics have been gaining momentum over the last few years and there’s a lot of information to help you get started. Depending on how things go in the coming months, I may be able to start pitching physical computing devices for client projects.

At the time of this writing (April 2016), there’s not much to be said about getting Swift working properly on devices like the Raspberry Pi. While a few individuals have made great headway into making swift compile for linux arm7, the work isn’t complete and a few critical pieces are missing. Even now, not a lot of progress has been made since January, when it all started to work.

To put it simply this is what does and does not work. Set your expectations accordingly.

  • A build of Swift 2.2 “works” – you can compile and link to Foundation + Glibc
  • That build is from February, 2016
  • The Swift REPL doesn’t work – crashes with a memory bug
  • Full set of Swift3 tools don’t compile (yet)

Getting Started

I’m using a Raspberry Pi3 running the latest Raspbian Jessie. Head over to Joe Bell’s instructions for the Raspberry Pi and follow them exactly. This will give you a workable Swift 2.2 install via apt-get. I’m sorry there aren’t more exciting instructions here, but that’s really the crux of our predicament – that seems to be the only reliable way to get swift running on the Pi for now.

Once you have Swift properly installed, give some examples a try (scroll down) – using Foundation and Glibc. It feels good to see Swift running on something other than an iPhone or Mac.

Next Steps

I’m currently working with (I use that word loosely – I don’t have the knowledge to be a productive contributor) with Joe Bell, Will Dillon, and Morris Cornell-Morgan to see if we can figure out what how we can get builds working for the Pi and other armv7 devices.

I had the most success attempting to compile Swift on the Pi in over a month last night – this happened to be within just a day or so of the main Swift repo switching over to swift-3.0 development. Most of the tools appeared to compile fine, but package manager failed, and there were some issues with linking (this could be a build config issue). I remain hopeful.

I’ll continue to post progress as it comes. In the meantime, I’m preparing a talk on this subject at the All Things Swift meetup in May.

EDIT April 27, 2016: Joe is putting together a concerted effort to get Swift3 on the Pi.He’s also provided a Jenkins build workflow to test integrations.