Category Archives: Uncategorized

Updating MRAA and/or UPM on Intel Edison.

This comes up for me quite often so I decided to add a post about it.

Here are some quick and easy to follow step for installing/updating MRAA and UPM on an Intel Edison. The Edison generally  has the prerequisites installed already so you should just have to compile. If you need more comprehensive instructions you can take a look at MRAA/UPM section of my Getting Started with Minnow Board Max post.

These instructions assume you have git installed. If not install git first following the instructions found here.

Install MRAA:

First we need to clone the MRAA repo from git hub:

git clone https://github.com/intel-iot-devkit/mraa.git

This will download whatever the default branch and tag is currently set at (usually the latest). If you wanted to switch to another tag (like version 7.3 for example) now is the time to do so

Now we are ready to build. We will used the same out of tree build as described in the MRAA documentation.

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr -DBUILDSWIGJAVA=ON
make
sudo make install

Install UPM:

UPM can be cloned with the following:

git clone https://github.com/intel-iot-devkit/upm.git

Switch to the desired version (or just use the default). Ensure the version you select is supported by the version of MRAA that is installed.

Now is also the time to add any libraries that you need that are not currently in the release. Just add the directory of the driver to the /src directory with the required support files.

We will again be using the out of tree build as described in the documentation. Enter these commands to build and install:

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr
make 
sudo make install

Building UPM on an Edison can take a while, so be patient.

That should do it. If there are no error messages you should be ready to utilize the new libraries.

Nodejs, Socket.io and Intel Edison

One of the things I really like about the Intel Edison (and the Galileo) is that they can be run as little Linux computers. We can use a lot of tools that are available for Linux machines. One of those tools in particular is nodejs.

Nodejs is a very powerful server side platform. It comes preinstalled on the Edison and Galileo Yocto images so it is very easy to get started with. We can implement code on the Edison and Galileo with the Intel XDK IoT Edition. With this combination of tools it is very easy to create applications that can monitor and control a remote Edison via a web based interface.

To get started I have created a repo on Git Hub that contains a project for the XDK. This project utilizes several technologies — node js, express , socket.io and  mraa library  on the server side. Jquery and an open source library to implement a gauge are used on the client side. I will be using the MCP9808 setup that I blogged about previously but any sensor (or group of sensors) could be utilized.

Before we jump into the code lets make sure we our Edison in up to date. I am using version 146 of the stock Yocto image. To check the version of your Edison execute the following:

configure_edison --version

If you need to update your Edison you can use the following:

configure_edison --upgrade

If you upgrade your Edison you will have to set up the wifi again.

To install the code on your Edison use the Intel XDK to open the project downloaded from Git hub. If you are using the Edison Arduino board open app.js and change line 23 to use i2c bus 6. Upload the project and use the build action to install all the Node dependencies. If you had an app running on the Edison previously you will need to stop it and start this one with the start and stop buttons.

The server code is located in the root of the project in the app.js file.  Here are lines 6 thru 10:

6  var express = require('express');
7  var app = express();
8  app.use(express.static(__dirname));
9  var server = app.listen(8085);
10 var io = require('socket.io').listen(server);

The first  four lines set up Express. Express is a full featured web framework for Node, but here I am just going to use it to serve up my static files from the file system.  The static server is set up on line 8. Line 9 instructs our server to listen on port 8085. Socket.io is initialized on line 10 and instructed to listen for connections on line 10.

Express may seem like overkill for this application, but I like to use if because it is easy to configure and is well supported. There are other, lighter foot print modules that can be used. You can find these other http servers by looking in the NPM Registry .

The real work in the server is done on lines 28 thru 44 :

28 io.sockets.on('connection', function (socket) {
 
30  setInterval(function () { 
31 socket.emit( 'temp' , JSON.stringify(getTemp())); //send temp every interval
32 }, 2000);

35 socket.on('toggle_led', function(data){
36   if(data === 'on'){
37     myOnboardLed.write(0);
38   } else {
39     myOnboardLed.write(1); 
40   }
41 });
 

44 });

Line 28 sets up socket.io to listen for connections. Each client connecting to this device will start the callback that sends the current temperature every 2 seconds (lines 30 – 32 ) and listen for the ‘toggle_led’ event (lines 35 – 41) to allow an led to be turned on and off.

The client side code is just as simple. The index.html page contains divs that hold the guage and a button.  The javascript code that does the work is in /js/app.js . This is all pretty standard stuff, but the first time I worked with socket.io I was stumped for awhile trying to find the source file for the socket.io client (Line 11 in index.html). This file is served automatically from our node server when we run it and is included in the server side socket.io code. All we need to do is add the line to load it in index.html.

If we look at the client side javascript in /js/app.js :

1  var socket = io.connect();
2
3  socket.on('temp', function (data) {
4    var status = JSON.parse(data);
5    Gauge.Collection.get('temp').setValue(status.farenheit); 
6   });
7
8  function toggle_led(state){
9  
10   socket.emit('toggle_led' , state ); 
11   var button = $('#led_button'); 
12   if(state === 'on'){
13      button.attr("onclick", "toggle_led('off')"); 
14      button.html('Turn off led'); 
15    } else {
16      button.attr("onclick", "toggle_led('on')"); 
17     button.html("Turn on led");1
19    }
20 }

We see that the code is fairly simple as well. The socket.io client is initialized on line 1 with a connection to the server we loaded our script from. We then setup a listener for the “temp” event on line 3. If we get a “temp” event the callback function will parse the json string from the server and update the guage in our page to the current value of our MCP9808. (Check the guage git hub page for comprehensive details on its use.)

To toggle the onboard led we have implemented the function at line 10 to emit the “toggle_led” event to the server. We also swap out the events on the button so we can just use one button to toggle the led.

The thing to remember is that the socket.emit sends an event with the name that we provide (in this case “toggle_led”). We need to ensure that the listener for this event uses the exact string. I’ve messed this up a couple of times.

It should look something like this when we have it running:

When the page is running it will look something like this.

When the page is running it will look something like this.

So there you have it. We have implemented a simple web page on the Edison so that we can get the temperature from out MCP9808 and display it. We have implemented the ability to toggle an led on the Edison from the web page. These examples are pretty basic, but the demonstrate a good starting point for more enhanced functionality that could be implemented. Feel free to use the template as a starting point in your projects.

I2C Interfacing on Intel Edison

In a previous post I discussed how to read the temperature from a MCP9808 temperature sensor. In this post I want to back up a bit to demonstrate some techniques for figuring out how to interface with an i2c chip and some basic verification techniques. I will be using the Intel Edison on the mini-breakout board, but these techniques will apply to most Linux based embedded systems.

The MCP9808 is an i2c bus device. I2C is short for Inter-Integrated Circuit, a two wire bus used for connecting components to each other on electronic devices. I2C is just one option used for interconnecting devices. Other options  include. SPI, 1-wire, and Serial. When using devices for an embedded project we generally find SPI or I2C on devices. I tend to go for I2C devices when I can because they allow me to get away with using less wires to hook up.

When we do integrate a device it is handy to ensure the device is recognized by the system before we try to write code for it. There are tools that are already installed on the Edison called I2C tools. A part of the LM-Sensors project, I2C tools allow low level access to I2C busses and the devices connected to them.

Before we get started lets make sure our Edison is up to date. We can do this by logging in via ssh (or use the terminal) and executing the command:

configure-edison --upgrade

You need to have your Edison attached to a network.

Let’s get started. There are four commands we are interested in that are summarized in the table here:

Bus scanning i2cdetect
Device register dumping i2cdump
Device register reading i2cget
Device register setting i2cset

Bus scanning:  

We use the i2cdetect command to both find the busses available as well as the devices on the bus. If we execute

i2cdetect -l

we can get a list of the currently installed I2C busses. The output is as as follows:

The result of i2cdetect -l on Intel Edison.

The result of i2cdetect -l on Intel Edison.

We can see we have 8 I2C buses on the Edison. But according to the docs we are only able to use bus 1 and 6 on the mini-break out board. I have only used bus 1 in my projects so far. If we wanted to see the devices on bus 1, we would enter:

i2cdetect -r 1

and get something like the following output:

The result of i2cdetect -r 1. This gives us a dump listing the devices on i2c bus 1.

The result of i2cdetect -r 1. This gives us a dump listing the devices on i2c bus 1.

When executing this command we get the standard warning that executing this command may jack up our device. It’s true, we can cause errors if we run this command on some of the other busses, but it has always cleared up for me with a power cycle of the Edison. Usually the device just hangs.

Looking at the output we can see we have four devices on bus 1. At 0x18 we have a MCP9808 temperature sensor, 0x3C is a SSD1306 display, 0x48 is an ADS1819 ADC , and 0x77 is a BMP085 barometric pressure and temperature sensor.

Device register dumping:

Now that we know what devices are on the board (or more accurately all the devices we wired to the Edison are recognized by our system) we can start working with the devices. Each device has internal registers that control the device and provide output from the device. We use the i2cdump command to take a look at these registers. Let’s take a look at the MCP9808

i2cdump 1 0x18 w

The form of the command is 12cdump (bus | device address | option). The ‘w’ option give us word output which makes it easier (for me at least) to read the registers. Executing the command gives us output that looks like this:

i2cdump of our MCP9808 on i2c bus 1 in word format. There is a lot of register space for devices, but we see we only have 13 registers in our device.

i2cdump of our MCP9808 on i2c bus 1 in word format. There is a lot of register space for devices, but we see we only have 13 registers in our device.

To understand what we are seeing in the dump we need to study the data sheet for our MCP9808.

If we study the data sheet for the MCP9808 we can decipher the registers we dumped.

If we study the data sheet for the MCP9808 we can decipher the registers we dumped.

Keeping in mind that the MCP9808 is a little endian device, we see the 16 bit data registers storing their values with the least significant  byte (LSB) first and most significant byte (MSB) second. We just need to do a quick byte swap to look at register 0 to see the value is 0x001d. According to the spec sheet the MSB should always be 0x00 as well as the LSB bits 7-4. Bits 3-0 in the LSB are the pointer used to select which register we read and write to when communicating to the device. The MCP9808 is a surprisingly complex device, so we won’t look at all the registers. But a thorough explanation of the registers and their function begins on page 16 of the data sheet.

Read a specific register:

We could certainly read the registers from the output of  i2cdump but there is a specific command for reading a single register. If we wanted to read the the current temperature the data sheet tells us the register containing this value is 0x05. To read this register we would issue this command:

i2cget 1 0x18 0x05 w

The command is in the form i2cget (bus | device address | register | option) . This gives is the following output:

Use i2cget to read the current temperature from our MCP9808.

Use i2cget to read the current temperature from our MCP9808.

We get the requisite warning and then the little endian contents of the register. Swapping the bytes to 0xC152 and referencing page 25 of the data sheet we can get the current temperature in Celsius. Briefly —   Bits 15-13 are flags that are used when we set the device to monitor a high and low set point. They can tell us if a threshold was passed, and which one. We don’t have those set so the values are not significant to us in this case. Bit 12 of the word is the sign of the two’s compliment value, since it is 0 our value is positive. Stripping those four bits out we are left with 0x0152 which is the temperature value. The rest is a base conversion and a little math — the MSB is 1 decimal, the LSB is 82. So using the data sheet formula  –> 1 * 16 + 82 / 16  = 21 degrees Celsius. Thats a cool 69.8 F in the office today.

Set a register:

If we want to manually control the MCP9808 we can set its registers with the i2cset command. Before we use the command a little back ground.

The MCP9808 has two modes of operation — continuous conversion and shutdown mode. Shutdown mode puts the device into a low power state and , as you might have guessed, stops updating the temperature measurement. If we read the temperature register while the device is in shutdown we will retrieve the last measurement made. In a battery powered device it might be a good idea to shutdown the device and only power it up when we need to update the temperature. This is controlled by bit 8 of the config register located at 0x01.

We can use the following command to enter into shutdown mode:

 i2cset 1 0x18 0x01 0x0001 w

Remember that we need to swap the bytes in the word due to endianness. This can be tested by reading the temperature while heating up the sensor (I just put my finger on it). You can use i2cget or i2cdump to read register 0x05 of the device. To set the sensor to continuous conversion mode use this command:

i2cset 1 0x18 0x01 0x0000 w

This post covered the basics of verifying a device is detected on an I2C bus and determining if the device is functioning properly. We used the four I2C tools commands to detect the busses and devices installed, dump a device registers, read a specific register, and to write a register. With these four commands we can certainly see if our devices are working correctly as we implement an embedded system.

The i2c tools do have other modes of operation that I did not touch on here. These modes can be read about on the I2C tools docs page. Armed with these tools and the data sheet for a device we are ready to get coding.