Swift and the BeagleBone Black

Now that I have completed my three books on Swift (MasteringSwift, Mastering Swift 2 and Protocol Oriented Programming with Swift), I told my daughters that I would take a break from writing books for the summer.  My oldest told me that she wanted to start working on robots again.  At the age of ten, She is already a second-degree black belt, and an instructor in Tae Kwon Do so when she says she wants to do do something I generally listen.  So after a little discussion about what she wanted to do, we decided that we would pull out all of the robot parts and start working with our BeagleBone Blacks again.

I had to start off by doing some reading to catch up with everything that has happened over the past year and a half that spent writing.  In my reading I happened to stumble on the iacheived.it site that showed how to install Swift on the BeagleBone Black. I also found the SwiftyGPIO package (control the BeagleBone Black GPIO with Swift) that was featured on IBM’s Swiftpackage library.  So this got me thinking about being able to program our robots with Swift, now that sounds pretty exciting doesn’t it?

Note: This post and a most of the ones that show how to use Swift with the BeagleBone Black will be crossed posted between my Robotics Blog and my Swift programming blog.

The first part of this post will walk you through setting up your BeagleBone Black.  After we get the BeagleBone Black setup we will write some code that will let us control an LED with a button.  I know controlling a led with a button isn’t that exciting but we need to start somewhere and that really is like a “Hello World” application so lets get started.

Setting up our BeagleBone Black

The following list will walk you through setting up the BeagleBone Black.  Rather than writing out detail instructions I will provide links to the pages that I followed when I set up my boards.  Since I use a Macbook Pro, the instructions are for the Mac.  Sorry, but I do not have a Windows machine to mirror the steps on however the only Mac specific areas in these steps in where we copy the image over to the SD card and the Beagle Board site has a getting started page that may help anyone that uses Windows with these steps.  If you use the Beagle Board site, once you get the image on the SD card, you can skip to step 4 below.

1.  Get the latest Debian 8.3 image from Beagle Board’s site.  You can find the image here.

2.  We need to unzip the images.  We can do this using TheUnarchiver for Mac.

3.  Now we need to copy the image over to the SD card.  I would recommend using at least a 8 gig SD card.  Everything needed will take up 3.3 gig which will fit on a 4 gig card but you are not leaving yourself much extra space.  I use Pi Filler to copy the image onto the SD card.  Once installed, run the Pi Filler app and follow the on screen prompts.

4.  Once you have the image on the SD Card, go ahead and plug it into your BeagleBone Black and power it up. 

5.  If you are using a SD card greater than 4 gig, you will need to manually expand the file system since the image only uses 4 gig.  To do this you can following these instructions. 

6.  Now we are set to install Swift.  The instructions to do this are on the iachieved.it site.

7.  The last thing we need to do before we start to code is to get the SwiftyGPIO repository.  You can find the repository here.  Under the Sources directory you will find the file SwiftGPIO.swift file.  This is the file we will need to use with our code.

Now that our BeagleBone black setup, lets get ready to do some coding.  We will start by writing some code that will cause our LED to blink on and off.  We will then write a separate application to read the state of a button.  Finally we will combine the code to create an application that will turn the LED on and off with the button.  So lets get started.

Turning an LED On and Off

The first thing we need to do is to wire everything up.  When you do this wiring you will want to have the BeagleBone Black powered off.  The following diagram shows how we would wire a LED to our BeagleBone Black.  It is recommended that whenever we connect anything to the BeagleBone Black we should always disconnect the power.

  

We run a solder-less jumper from pin 1 of the P9 expansion header to the ground rail marked with the blue line on the breadboard and then take another solder-less jumper from pin 2 of the P9 expansion header to the power rail marked with the red line.  We will use these rails to provide power and ground for our LED and Button.

Now lets add the LED to our breadboard.  Connect the cathode end of the LED (shorter wire) to the ground rail of our breadboard and then connect the anode end of the LED (longer wire) to one of the other rows on our breadboard.

Now take a 100 OHM resistor and connect one end to the row on the breadboard that the LED is connected to and the other end of the resistor to another row on the breadboard.  Finally run a solder-less jumper from pin 12 of the P9 expansion header to the row that the 100 OHM resistor is connected too.  We are now set to power up the BeagleBone Black.

You will want to create a separate directory for each Swift project so lets begin by creating a directory named blinkyled and then change to that directory.  You will want to copy the SwiftyGPIO.swift file from the SwiftyGPIO package to this directory.

Copy the following code into a file named main.swift also in the blinkyled directory (the file needs to be named main.swift).

import Glibc

let gpios = SwiftyGPIO.getGPIOsForBoard(.BeagleBoneBlack)

var led = GPIO(name:"GPIO_60", id: 60)

led.direction = .OUT

while(true){

      print(“Changing”)

     led.value = (led.value == 0) ? 1 : 0

     usleep(150000)

}

In this file we start off by importing the GLibc module.  In the next line we retrieve the list of GPIOs available for the BeagleBone Black.  Next we get a reference to GPIO_60 (pin 12 of the P9 expansion header).  You can see the GPIO ports listed here.

The next line configures the port direction for the GPIO port.  We can use GPIODirection.IN or GPIODirection.OUT here.  Now we create a while loop.  Within the while loop the first line prints a message to the console letting us know that we are changing the LED.  The next line checks the value of the LED and changes it causing the LED to blink.  A value of 1 turns the LED on and a value of 0 turns it off.  We then use the usleep function to pause before we loop back.

To compile this application we use the following command:

swiftc –o blinkyled SwiftyGPIO.swift main.swift

This command uses the swift compiler to compile SwiftyGPIO.swift and main.swift and writes the output to the file named blinkyled.  We are now able to run our application.  If you attempt to run this without super user privileges the LED will not blink.  To access the GPIO ports you will need to run the application with sudo like this:

sudo ./blinkled

If everything is connected correctly, the LED should blink on and off pretty quickly.  Now lets look at how we would check the state of a button.

Reading the state of a button

Now that we have the LED working lets look at how we would read the state of a button.  To begin with lets connect a button to our Beaglebone Black as shown in the following diagram.  Keep in mind that whenever we connect anything to the BeagleBone Black we should always disconnect the power.

   

In this diagram we add the push button to the breadboard.  You will want the button to straddle the middle section as show in the previous image.  Using a solder-less jumper, connect the power rail of your breadboard to one end of the button.  Next connect the same end of the button to the ground rail of your breadboard using the 10K pulldown resistor.  Finally connect the other end of the button to pin 23 of the P9 expansion header. 

Now lets power up the BeagleBone Black and write our code to read the state of the button.  Create a directory named button and copy the SwiftyGPIO.swift file to this directory.  Next create a file named main.swift in the button directory and add the following code to it.

import Glibc

let gpios = SwiftyGPIO.getGPIOsForBoard(.BeagleBoneBlack)

var button = GPIO(name: "GPIO_49",id: 49)

button.direction = .IN

while(true){

      if button.value == 1 {

           print("Pressed")

      }

      usleep(10000)

}

In this file we start off by importing the GLibc module.  In the next line we retrieve the list of GPIOs available for the BeagleBone Black.  We then get a reference to GPIO_49 (pin 23 of the P9 expansion header). 

The next line configures the port direction for the GPIO port.  We can use GPIODirection.IN or GPIODirection.OUT here.  Notice in the LED example we used GPIODirection.OUT however in this example we used GPIODirection.IN.  Next we create a while loop.  Within the while loop we check the state of the port and if it is high (value of 1) we print the message “Pressed” to the console letting us know the button is pressed.  We then use the usleep function to pause before we loop back.

To compile this application we use the following command:

swiftc –o button SwiftyGPIO.swift main.swift

This command uses the swift compiler to compile SwiftyGPIO.swift and main.swift and writes the output to the file named button.  We are now able to run our application.  The following command will run our application.

sudo ./button

If everything is connected correctly, when you press the button you should get a message printed to the console.  Now lets put our LED and Button examples together to turn the LED on whenever the button is pressed.

Putting it together

The following diagram shows how we would wire the LED and Button to our BeagleBone Black (notice no changes from the previous two diagrams just combined them).

The following code will go in our main.swift file:

import Glibc

let gpios = SwiftyGPIO.getGPIOsForBoard(.BeagleBoneBlack)

var button = GPIO(name: "GPIO_49",id: 49)

var led = GPIO(name:"GPIO_60", id: 60)

button.direction = .IN

led.direction = .OUT

while(true){

      if button.value == 1 {

            print("Pressed")

           led.value = 1

      } else {

           led.value = 0

      }

      usleep(10*1000)

}

When you compile this, don’t forget to include the SwiftyGPIO.swift file.  When you run the application, the LED should turn on when you press the button and turn off when you release it.  The following image shows how my wiring looks in real life

Notice the sporty new BB8 case I made for my BeagleBone Black, pretty cool huh?  Not to mention that BB8 and BBB kind of go together.  Just printed it on my new 3D printer.  I will be talking about the printer in a post very soon and will include links to some of the stuff I have printed and designed including the BB8 case.  I am thinking about making a R2D2 case for my other BeagleBone Black.

If you are new to Swift, I will be discussing some of the basics while I am showing how to use Swift with the BeagleBone black however my assumption is you will have at least a basic understanding of Swift.  I will also be writing more blog posts that are specific to Swift on Linux on my Swift programming blog however if you are really interested in the language I would recommend my Mastering Swift 2 and Protocol Oriented Programming with Swift books.  Please keep in mind that those books talk about using Swift on the Mac however most of the language concepts themselves are the same whether you are using Swift on a Mac or with Linux.

Now that my books are done, you should start seeing a lot more posts on both my robotic and swift blogs.  I do have a question for anyone that might be able to answer: Does anyone know when/if we will see an update for the BeagleBone Black?  I am not talking about the X15 that looks like it is going to be pretty expensive.  I am looking more for an update to the BeagleBone black that will have roughly the same price point.

Generic Programming and POP with Swift – The Law of Useful Return

In my first post on Generic Programming I talked about the iterative approach to improving algorithms.  In this post I would like to discuss another concept from the From Mathematics to Generic Programming book that I am currently reading. This concept is called The Law of Useful Return.

The Law of Useful Return says:

If you have already done the work to get some useful result, don’t throw it away.  Return it to the caller because they may be able to use it.

What do we mean by this law.  Well the easy way to explain it is to look at an example.  In the From Mathematics to Generic Programming book, they explain this law based on a mathematical equation however, most developers that I know do not get that excited about complex mathematical equations therefore I am going to take a non-mathematical approach to explaining this.

Lets say that we were creating a pump that is connected to the Internet for real time monitoring (think IoT).  This pump could be used to pump different types of liquids and would be able to return the temperature of the liquid as it is being pumped.  In our application, that monitors the pump, we could then retrieve the temperature and send out an alert if it is outside of the acceptable range for the particular liquid that is being pumped.  Our function to monitor the temperature may look something like this:

func isTemperatureWithinRange() -> Bool {

    //Get liquid temperature

    var temp = getLiquidTemp()

   

    //Check if temp is within acceptable range

    if temp < MIN_TEMP || tem > MAX_TEMP {

        return false

    }

    return true

}

This function would work well and if the temperature was outside the acceptable range it would return false triggering an alert.  The problem that could arise from this is eventually we will want to display the actual temperature of the liquid being pumped, therefore someone may add another function that would simply retrieve the temperature of the liquid and return it.  This function may look something like this:

func getTemperature() -> Double {

    //Get liquid temperature

    return getLiquidTemp()

     }

Now in order to retrieve the temperature of the liquid and to also check if it is within the acceptable range we would need to call the getLiquidTemp() function twice.  Since this function retrieves the temperature from a remote device, making two separate calls like this is definitely not optimal.  What we could have done to avoid this problem was to return the temperature with the Boolean value that indicates if the temperature was within the acceptable range.  It would be very easy to do since we are already retrieving the temperature as part of the check.  The function that returns both values could look something like this:

func getTemperature() -> (acceptable:Bool, temperature: Double) {

    //Get liquid temperature

    var temp = getLiquidTemp()

   

    //Check if temp is within acceptable range

    if temp < MIN_TEMP || tem > MAX_TEMP {

        return (acceptable:false, temperature: temp)

    }

    return (acceptable:true, temperature: temp)

}

Be careful not to follow this law to closely because we only want to return data that is useful within our application.  When we create functions like this we really need to ask ourselves not only what information do we currently need but also what information may be useful.  In our example above, returning the temperature, since we already retrieved it, could definitely prove useful even if it is not needed with our current requirements.  Writing our API correctly (generically) the first time will save us from having to change the interface for our APIs in the future.  This means a lot less refactoring of our code.

To me, one of the ideas behind the Law of Useful Return is to avoid making our APIs so granular that we end up performing the same functions multiple times.  To illustrate this idea another way lets look at a second example.  Lets say that we have a NSDate object and we need to retrieve the month from it.  We could very easily design our API like this:

func getMonth(date: NSDate) -> Int {

    let components = NSCalendar.currentCalendar().components(.Month, fromDate: date)

    return components.month

}

This works great for our present need however what happens if in the future we also need to retrieve the day of the month.  We could write a second function to retrieve the day of the month however we would then need to make two function calls if we needed both the day of the month and month itself.  A better way to design our API is to think ahead and realize that if we are retrieving the month from the NSDate object maybe the day of the month and year would be useful.  We would then create a function that returns the month, day and year like this:

func getDate(date: NSDate) -> (month: Int, day: Int, year: Int) {

    let components = NSCalendar.currentCalendar().components([NSCalendarUnit.Month, NSCalendarUnit.Day, NSCalendarUnit.Year], fromDate: date)

    return (month: components.month, day: components.day, year: components.year)

}

By designing our API to return the month, day and year rather than just the month our function becomes much more generic and useful not just for our present needs but also for our future needs.

When we create APIs that only meet our present requirements we end up having to do a lot of extra code refactoring in the future when we have to change those API to meet our future needs.  When we are designing our APIs we should always remember to think beyond our present needs and think about how we can make our APIs generic enough to also meet our future needs.

There are going to (hopefully) be a number of posts in the Generic Programming and POP with Swift series therefore I made a separate post that contains links to all of the articles in this series.  The post is located here:  http://masteringswift.blogspot.com/2016/03/generic-programming-and-protocol.html