We have a range of sensors that use our Sensor Expansion Interface (SExI) footprint. All these sensor are supported within CoreBASIC so using them with a SolderCore is a very very easy. The sensors can also be used with a range of other development platforms, including Arduino (care required with the voltage levels), Raspberry Pi, Fez etc etc. In this post, we'll look at using the sensors with the BeagleBone.
The BeagleBone is a bit of beast, with a powerful ARM Cortex-A8 micro-processor, it's the smaller brother to the BeagleBoard and is focused more towards hardware I/O. It is shipped as standard with the Angstrom Linux distribution.
Linux
Linux, well, if your not in that camp, it is a little daunting, there is a lot to it, hence there is a steep learning curve. However, once you get behind the ethos of it, it provides a decent platform to do some really quite impressive stuff. This post isn't intended as a tutorial to the BeagleBone or Linux. It is more of a guide to demonstrate how it's possible to write programs on the BeagleBone that can use the SolderCore range of sensor boards.
All our sensor breakout boards have the same footprint. This footprint consists of the power pins 5V, 3V3 and GND, the communication pins I2C, SPI and UART and the other pins DIO and analog as shown below. 
The advantage of having the standard footprint is it allows compliant devices to be readily swapped with no change or very little change to the hardware.
In this post, I will demonstrate how to program the BeagleBone to read data from a CoreLight device over the I2C bus. Once working, I'll swap the CoreLight module with another I2C SExI device, the only change to the setup is the software. You may have noticed that more that 50% of our sensors breakout PCBs only have 8 pins rather than 16 as shown. Most of our sensors are either exclusively I2C or SPI so a full footprint is not required, the upper 4 rows are used for SPI devices and the bottom 4 rows for I2C devices.
Disclaimer
Before I begin, here is my disclaimer. I am a electronic hardware engineer, I am not a software engineer and before this post I did my best to avoid using Linux. So with that in mind, lets begin.
I ordered a BeagleBone from our favorite distributor, Mouser, stockist of all the greatest embedded development boards ;o). It turned up a couple of days later and I did nothing with it for about 6 weeks. Last week I decided it would be nice to get it running a with some of the SolderCore hardware I have around me. Unfortunately, I knew very little about Linux, I did once go on a embedded Linux course for a few days, but that was a long time ago and since then I haven't done anything with it.
So first things first, I needed to get familiar with the BeagleBone and Linux. My PC hard drive was partitioned and the latest version of Ubunto was installed.
After reading the BeagleBone ReadMe file I connected my devices USB port to my PC. A virtual com port was enumerated through the on board USB hub @ COM9 (using Windows at this point). I configured PuTTy to the correct settings and logged in. My device seemed to be working as I was presented with the Angstrom login prompt. I had a brief look around the file system using my limited repertoire of Linux bash commands, cd and ls. It did indeed, look very much like a Linux system. I then took it upon myself to update the uSD image to latest version. The latest Angstrom image can be found here, along with beginner instructions on how to write the image to the uSD card. The instructions consist of typing out the following:
$ sudo -s
(type in your password)
# zcat Angstrom-Cloud9-IDE-eglibc-ipk-v2011.10-core-beaglebone-r0.img.gz > /dev/sdX
# exit
Disastorama...
The important bit here is to make sure that you replace the X with the correct value for the microSD card. You can find out what it should be using the dmesg | tail command in the shell, just after you place the uSD card into the PC. If you get X wrong, the results can be fairly catastrophic to the health of your PC. I learnt this the hard way and uncompressed the Angstrom image all over my hard disk. This was a little disappointing... Many days later after re-installing Windows, my applications and waiting for my data to come back from the cloud I was ready to go again.
The future is Virtual!
Rather than creating a real Linux partition I wimped out and installed a virtual Ubuntu using VMWare Player. I also decided to create the Angstrom image using the Windows method semi described here. The aim of this mini project was to write a program to communicate with our range of sensors. At the start I wasn't even sure which language I was going to write the program(s) in, I had the choice of C/C++, Python and BoneScript. I couldn't get my head around BoneScript, it's just a bit too out there for me, so Python or C/C++ it was. After trawling the web for information I came across a superb video series from Derreck Molley about programming the BeagleBone: he used C/C++ so mind was made. The video series guides you through the basics of setting up a C/C++ cross compiler using Eclipse as the IDE, it's fairly straightforward to do and I had my first cross-compiled program written within a couple of hours. With the cross-compiler up and running it was time to read up on I2C development on the Bone. There are lots of web pages that discuss how to do this.
Laying it out
The hardware was setup as shown below, with a CoreLight plugged into a mini protoboard. The I2C lines were connected to pins 19 and 20 of connector P9 of the BeagleBone.
The are a set of user space tools that can be executed from the BeagleBone shell that allow you to quickly check that your hardware is working correctly. The first program I used was i2cdetect. Typing i2cdetect -l, into the shell, lists the I2C ports available. Two ports were returned:
i2c-1 i2c OMAP I2C adapter i2c-3 i2c OMAP I2C adapter
I tried an address scan on both ports by typing irdetect -r 1 and irdetect -r 3. The i2c-3 bus returned a hit a address 0x44:
Break out the crayons
Time to get coding. The first programs aim was simply print the ambient lux level to the shell as sensed by the CoreLight module. I had written a simple Stellaris C driver for this device already so it was a matter of porting it to the BeagleBone. The original Stellaris driver provided the following functionality:
- Set up the ISL29023 command1 register. Write 0xc0 to register 0x00. (Sets mode of operation)
- Setup the command 2 register. Write 0x03 to register 0x03.(Sets measurement parameters)
- Read from the MSB and LSB registers containing of the ADC value and scale accordingly
To read and write to I2C devices within a C program on the BeagleBone (and Linux in general) you must open the relevant device driver file. Using this file you can check that the device you wish to communicate with can be addressed and finally read or write your data. The main blocks of code to do this are shown below:
// Open the relevant file
if ((file = open(filename, O_RDWR)) < 0 ) {
perror("Failed to open bus");
return -1;
}
// Check we can address the device
if ((ioctl(file,I2C_SLAVE, address)) < 0 ){
perror("Failed to address device");
return -1;
}
// Write some data
i2cdata[0] = DATAMSB;
if ((write(file, i2cdata, 1)) != 1) {
perror("Failed to write to MSB register of ISL29023");
return -1;
}
// Read some data
if ((read(file, i2cdata, 1)) != 1) {
perror("Failed to read from MSB register of ISL29023");
return -1;
}
// Close file
close(file);
My ISl29023 driver adaption was complete and a top level main function was written to read the CoreLight device 10 times and print the result to the shell. With the code completed and successfully compiled, the executable was copied to the BeagleBone using the Eclipse RSE plug-in. Before the program could be run its executable permission bit needed to be set using the chmod command. I initiated the GDB debugger service on the BeagleBone to allow me to step through the program and look at what was going on. A few alterations here and there and the code was working!
Sensor switcheroo
At last...the the bit I wanted to get to; showing off how simple it is to change one SExI sensor for another. So it's time to swap out the CoreLight and replace it with the CorePressure or perhaps the CoreMAG or even the CoreMPU... it doesn't matter as the development proto-typing platform remains the same, just a few tweaks to the software. Sweet!
I modified the program to accept a command line switch which selects one of the I2C sensors that we support and modified all (some!) of the drivers to support the Linux environment. The code can be downloaded at the bottom of this blog.
If this looks a little bit too much like hard work, I would like to add that getting one of our sensor devices working with SolderCore is considerably easier. The code for installing and using a sensor generally looks like this:
INSTALL "CoreLight" AS L
FOR I = 0 TO 9 PRINT "The ambient light level is "; L.LIGHT; " Lux" NEXT I
That's it, as long as your sensor is correctly wired, it will just work.
The demo code was written within the Eclipse (Indigo) IDE with the CDT plug-in. I used gcc-4.4-arm-linux-gnueabi to create an executable that could be run on the rev A5 BeagleBone.
You can download the source code below:
The files consist of the CoreLight, CorePressure, CoreGyro and CoreTilt Linux driver code and a top level example (sensor.c) which will read the sensor selected when the program is executed.
The program requires a single argument to be passed in to select the sensor to be tested:
./SensorDemo n
n
1 = CoreLight
2 = CorePressure
3 = CoreMag...Coming soon.
4 = CoreTilt;
5 = CoreGyro
6 = CoreWii...Coming soon.
7 = CoreMPU...Coming soon.