Beaglebone Black SPI and Microchip 25LC512

I wanted to learn how to use SPI on the Beaglebone Black (BBB) and I found a well done post that Ben Martin did to get me started. As a novice linux user, there were a number of hurdles I had to overcome to get everything working:

1. Understand enough about the Device Tree Compiler overlay process to enable SPI0 on the BBB.
2. Installing and using shared libraries (told you I am a linux novice)

One of the reasons I liked Ben’s article, is that it had an arduino example for the 25LC512 and I wanted to start in an environment that I knew well to test the devices to be certain they were working before moving on to the BBB and using C. I have used the Adafruit webide tools and python on the BBB before and I could have elected to use their python SPI libraries from their BBIO package, but I wanted to learn more about using C on the BBB.

After validating the 25LC512 on the arduino (wiring and code on Ben’s post), it was time to move onto the BBB.

First some basics – I did all this on the v2013.06 version of angstrom. I used this version as I am also learning about the PRU on the BBB and needed this version to install PyPRUSS from Elias Bakken from hipstercircuits.com. So for clarity, here is the output of lsb_release -a

Distributor ID: Angstrom
Description: Angstrom GNU/Linux v2013.06 (Core edition)
Release: v2013.06
Codename: Core edition

I’ll bet everything related to SPI only in this post would run just fine on the standard Angstrom images, but I did not test that. Next step is to enable the SPI0 device. There is much written on how to build a DTS file that gets compiled to a DTBO file that actually gets loaded to enable a device – here are the straight forward steps to enable:

root@beaglebone: export CATS=/sys/devices/bone_capemgr.*/slots
root@beaglebone: cd /lib/firmware
root@beaglebone/lib/firmware: echo BB-SPIDEV0 > $SLOTS
root@beaglebone/lib/firmware: cat $SLOTS
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPIDEV0

The BB-SPIDEV0-00A0.dts and the corresponding BB-SPIDEV0-00A0.dtbo file were included in my Angstrom distro. Note that in the echo command above, only BB-SPIDEV0 was specified, so the “-00A0″ is assumed.

On to the next step! The C example on Ben’s site was not a complete version of the code – he later sent me the complete file, but in the interim, I found a library that simplified the interface to the spidev driver called libsoc by Jack Mitchell. The spi_test.c example in that repo is for a Microchip 25LC640, which is not as recent a device as the 25LC512, but similar enough to allow me to enhace it swiftly for my purposes. Getting this library installed was somewhat of a challenge for this linux newbie, but Jack was quite patient in answering my questions. The following details my installation – might help some other newbie!

At first I attempted to clone the repo by:

root@beaglebone get clone git://github.com/jackmitch/libsoc

but I ran into ssl problems. Two solutions to this:

1)  git config –global http.sslVerify false     (quick and dirty, but not secure)

2) use wget versus git clone

There is a third solution which is to really fix the ssl key situation…little things like this is why debian on the Raspberry Pi seems so much easier.

Anyway, now that the library is downloaded:
cd libsoc
./autogen.sh
./configure
make install

At this point the library is installed in /usr/local/lib and the header files in /usr/local/include. I did not know that these shared library paths are not in the standard search paths (/usr/lib and /usr/include), so I eventually ended up with this for the compile command:
gcc -Wall -I /usr/local/include -L /usr/local/lib -lsoc gpio_test.c -o gpio

The GPIO-test program writes to and reading from a GPIO pin – a good test of whether libsoc was installed and working. But before I could run it, I had to do this export:

export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

I discovered a very useful utility that is not installed on the BBB (but is on the Pi) – ldd (print shared library dependencies). It is easy to install:
opkg update
opkg install LDD

So for instance, to check if all the libraries are defined for an executable:
ldd gpio
libsoc.so.2 => /usr/local/lib/libsoc.so.2 (0xb6f7d000)
libc.so.6 => /lib/libc.so.6 (0xb6e42000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb6e23000)
/lib/ld-linux-armhf.so.3 (0xb6f8b000)

With confidence that libsoc was installed and I know how to use the shared libraries, let’s move on to testing the 25LC512. The source for this can be found at https://github.com/Maddox-zephyr/BBB-25LC512-Test

In a directory of your choice, create/get a copy of spi_25lc512x.c from the git repo.

Hook up the BBB to the 25LC512:

 

Fritz 25lc512 BBB SPI_bb 702x720

To compile, run, and examine the output of this program, simply:

root@bealebone gcc -Wall -I /usr/local/include -L /usr/local/lib -lsoc spi_25lc512x.c -o spi_25lc512
root@bealebone ./spi_25lc512 > output.spi
root@beaglebone more output.spi

But what about performance? A Saleae logic analyzer trace file and jpg are in the git repo. If you load the trace file into the Saleae application, you can examine the timings yourself. (I love this little tool!).

Here is a jpg of a one byte read, just after the chip is erased:

Saleae Read 1 byte

There are more jpgs of the logic analyzer traces in the repo.

What did I learn (beside remedial linux stuff)? SPI through libsoc can issue commands every ~100 usec (observed between 77 and 125 usec). Random 1 byte reads can complete every ~100 usec as well. 128 bytes can be transferred from the BBB to/from the 25LC512 in ~200 usec. A long block of sequential reads run at about 640 KB/s. Not bad for a $45 computer with a $2 serial flash chip!

Posted in Uncategorized | Leave a comment

Bluetooth LE on BeagleBone Black with TI SensorTag

Picked up a SensorTag from TI recently and decided to see if I could get the BeagleBone Black (BBB) to SensorTag bbbinteract with it.  I started with this posting by Mike Saunby for the Raspberry Pi. Below are the steps I took to get my IOGEAR Bluetooth 4.0 USB Micro Adapter (GBU521) working on the latest Angstrom distribution for the BBB.

First step, edit

/var/lib/connman/settings

to enable bluetooth:

[global]
OfflineMode=false [Wired] Enable=true [WiFi] Enable=true [Bluetooth] Enable=false    <====== change to true

Shutdown the BBB, plug the IOGear adapter into the USB port, and boot the BBB.

# hcitool dev
Devices:
# hci config -a
hci0: Type: BR/EDR Bus: USB
         BD Address: 00:02:72:3E:7C:EB ACL MTU: 1021:8 SCO MTU: 64:1
         DOWN
          RX bytes:495 acl:0 sco:0 events:22 errors:0
          TX bytes:369 acl:0 sco:0 commands:22 errors:0
          Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0×87
           Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
           Link policy: RSWITCH SNIFF
           Link mode: SLAVE ACCEPT
# lsusb
Bus 001 Device 002: ID 0a5c:21e8 Broadcom Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
#hciconfig hci0 piscan                                      <—– See note blow labeled PISCAN
# hciconfig -a
hci0: Type: BR/EDR Bus: USB
         BD Address: 00:02:72:3E:7C:EB ACL MTU: 1021:8 SCO MTU: 64:1
         UP RUNNING PSCAN ISCAN
         RX bytes:996 acl:0 sco:0 events:45 errors:0
         TX bytes:742 acl:0 sco:0 commands:45 errors:0
         Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0×87
         Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
         Link policy: RSWITCH SNIFF
         Link mode: SLAVE ACCEPT
         Name: ‘BCM20702A’
         Class: 0×000000
         Service Classes: Unspecified
         Device Class: Miscellaneous,
         HCI Version: 4.0 (0×6) Revision: 0×1000
         LMP Version: 4.0 (0×6) Subversion: 0x220e
         Manufacturer: Broadcom Corporation (15)
# hcitool lescan
LE Scan …
90:59:AF:0A:A9:D8 (unknown)
90:59:AF:0A:A9:D8 SensorTag
(hit cntrl-C to exit)
# hcitool lecc 90:59:AF:0A:A9:D8
Connection handle 64

Now to tell the SensorTag to return some data:

# gatttool -b 90:59:AF:0A:A9:D8 –interactive
[ ][90:59:AF:0A:A9:D8][LE]> connect
[CON][90:59:AF:0A:A9:D8][LE]> char-read-hnd 0×25
[CON][90:59:AF:0A:A9:D8][LE]>
Characteristic value/descriptor: 00 00 00 00
[CON][90:59:AF:0A:A9:D8][LE]> char-write-cmd 0×29 01
[CON][90:59:AF:0A:A9:D8][LE]> char-read-hnd 0×25
[CON][90:59:AF:0A:A9:D8][LE]>
Characteristic value/descriptor: b7 ff a0 0c

 

At this point, everything is working!

I proceeded to use Mike’s code on github to test.  I started with sensorTag_test.py as it repeatedly gives the temperature – I had to download/install pexpect first:

 # wget http://pexpect.sourceforge.net/pexpect-2.3.tar.gz
 # tar xzf pexpect-2.3.tar.gz
 # cd pexpect-2.3
 # python ./setup.py install

Now I can run the test:

# python sensortag_test.py 90:59:AF:0A:A9:D8
Preparing to connect. You might need to press the side button…
27.49 C
30.26 C
29.07 C
28.05 C
27.76 C
27.89 C

Hurray – working!

You can continue with Mike’s python code that reads all the sensors.

Note:  there was no need to build a copy of gattool or to build bluez-5.2 unlike what Mike had to do for the Pi.

So it is a simple procedure with all the right info – but I was stumped on getting the BBB to recognize the bluetooth adapter until I came across this posting to edit /var/lib/connman/settings to enable bluetooth.

Here is the version of Angstrom all this worked on:

# uname -a
Linux 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l GNU/Linux

PISCAN note:

After a subsequent reboot of the BBB, I had to add a step:
# hcitool dev
DEVICES:
# hciconfig -a
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:3E:7C:EB ACL MTU: 1021:8 SCO MTU: 64:1
DOWN
RX bytes:495 acl:0 sco:0 events:22 errors:0
TX bytes:369 acl:0 sco:0 commands:22 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0×87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
On the third line of the response, you see the word DOWN, so I did the following:
# hciconfig hci0 up
# hciconfig dev
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:3E:7C:EB ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:990 acl:0 sco:0 events:44 errors:0
TX bytes:738 acl:0 sco:0 commands:44 errors:0
Now notice UP RUNNING on the third line!
Continuing on:
# hciconfig hci0 piscan
# hciconfig -a
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:3E:7C:EB ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING PSCAN ISCAN
RX bytes:996 acl:0 sco:0 events:45 errors:0
TX bytes:742 acl:0 sco:0 commands:45 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0×87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: ‘BCM20702A’
Class: 0×000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.0 (0×6) Revision: 0×1000
LMP Version: 4.0 (0×6) Subversion: 0x220e
Manufacturer: Broadcom Corporation (15)
# hcitool lescan
LE Scan …
90:59:AF:0A:A9:D8 (unknown)
90:59:AF:0A:A9:D8 SensorTag
cntrl+c
# hcitool lecc 90:59:AF:0A:A9:D8
Connection handle 64

Then I went back to the flow above…

Other posts leveraged:

http://ferryzhou.wordpress.com/2011/08/01/beagleboard-angstrom-usb-bluetooth-enable/

http://www.noah.org/wiki/pexpect#Download_and_Installation

http://yetiblog1337.wordpress.com/2013/06/02/raspberry-pi-bluetooth-dongle-does-not-work/

Posted in BeagleBone Black | 4 Comments

Stock Tank Filler

Overview: This is a project to increase the reliability of controlling the flow of water to a stock tank that keeps our horses well watered (there is a “lead a horse to water” joke in here somewhere) using a microcontroller to sense water level and turn the water on/off.  No AC power is available at these stock tanks, so using very low power techniques is required.  The project uses an MSP430 MCU and a DC latching solenoid with a high quality sprinkler valve driven by an H-bridge device.   Power is provided by a single 9v battery.

Problem:  Having horses on the ranch means keeping a steady supply of water for these animals that can swallow a quart per gulp.   Our stock tanks have water piped to them and we have used float valves to regulate the water level, but these float valves wear out often (twice a year), cost ~$30 to replace, and the failure mode results in lots of water in the pasture – good for the grass, but bad for the pocketbook (we don’t have well water).  And water is a precious resource in Texas these days.

Solution:  A few years ago we had irrigation plumbed to our greenhouse and the contractor used a regular sprinkler valve (Irritrol 205s) outfitted with a DC latching solenoid powered by a controller allowing you to set watering cycles as you would expect from a sprinkler controller, but powered from a single 9v battery.  After reliable daily watering on a single 9v battery, it occurred to us that leveraging a similar setup would improve the stock tank problem.

So it was time to design some electronics to do the job!  Last year we picked up some Launchpad boards from Texas Instruments for $4.30 (MSP430 – four three oh) and enjoyed how simple it was to program, test, and debug with the free Eclipse-based development environment (CCS) supplemented with other great inexpensive tools like the Saleae logic analyzer and a USB oscilloscope.  We hacked together a prototype using a Launchpad and an H-bridge DRV8333 evaluation board working out the basics. Lot’s wires everywhere as prototypes go!

Our end goal was to house this controller in the valve box below ground level, so it had to be waterproof.  We had never done a pcb before, but figured this would be the perfect time to learn how to design one, reflow it, and produce a neat, reliable device.  We started down the Eagle tools route, but the commands weren’t intuitive – looked like a big learning curve ahead, yet it seems everyone uses Eagle.   We searched to see if there was an alternative and landed on Diptrace.  Much more intuitive to us and the tools are free, like Eagle, for the hobbyist.  We are open sourcing this project, so hence the design files are Diptrace!

More on the design:

Hardware Choices:  We decided to use the same DC latching solenoid (DIG-S305-DC) and the same valve (Irritrol 205S) that our sprinkler guy used, since he said it was very reliable.  We started searching for an h-bridge and found the TI DRV8833 which has a power supply range of 2.7 V to 10.8 V.  The coil impedance of the DC solenoid is 5 ohms and with a 9v battery, we needed the h-bridge to handle 1.8 amps. The DRV-8833 has two h-bridges each capable of 1.5 RMS amps or 2 amps peak and you can use them in parallel for 3 amps RMS or 4 amps peak so we decided to use them in parallel – could have probably used one channel but we didn’t need the second channel  and two channels must be better than one!

We could have used a basic and less expensive MSP430F2012 for this project, but in case we wanted to add zigbee for remote monitoring/control, we decided to use the MSP430G2553 which has better UART  and I2C capability and 16K of flash and 512 bytes of ram. We had used this part on several other projects as well.  The MCU is programmed using headers that can be attached to the Launchpad – VDD must be driven by the Launchpad when programming so we provided a jumper on the board that must be in the appropriate position. Kerry Wong provides a nice writeup on using the Launchpad as a programmer here.

The solenoid specifies a 10 msec minimum pulse to engage/disengage .  During prototyping, we observed a considerable sag in the voltage to the solenoid when the h-brigde was on – the 9 volts would drop to 4 volts – presumably due to the internal resistance of the battery.  So we did a little math on the energy that needed to be dissipated in that 10 msec timeframe, and added a 4700 uF capacitor across the battery and that made things look better, although still sagging to a little over 5 volts.  But the solenoid was happy.

To provide VDD for the MSP430G2553, we used a TPS76333 – by now you you may be thinking that we are biased towards TI parts, but they provide free samples, fast delivery, and no shipping charges — the path of least resistance!

Software:  To conserve power and simplify the hardware, we used the Very-Low-Power Low-Frequency  Oscillator (VLO) for the watchdog timer which is nominally 12 KHz and the default 1MHz DCO when the processor is active.  The VLO can vary from 4 KHz to 20 KHz over the broad temperature range, but we intended for the controller to be in the valve box below ground so we wouldn’t see huge temperature swings and the sampling time of the float switch is by no means critical in this application.

Packaging

Weatherproof operation is required!  The controller will be located below ground level and will fill up with water in a heavy rain.  We selected a case from Polycase with a cable gland to seal where the wires to the solenoid and the float switch pass through.  Great thing about the Polycase box, is it comes with a dxf template of the dimensions of the circuit board it can accommodate.  We imported this to Diptrace and made some modifications so that it would fit in the 5 cm x 10 cm category for itead studio’s pcb service to reduce pcb costs.

PCB

As mentioned above, we settled on the Diptrace tools for our schematic capture and board layout.  The tools work well and itead studio’s service is great – for both times we ordered (yes, we missed a few things on the first prototypes), we got back boards in just under three weeks.  They advertise 8 pcs for the colored solder mask boards with 100% e-test and we got 12 boards back on the first run and 11 boards back on the second run. Very pleased with the quality and service.

Field Test

The installation required some plumbing  This meant some digging and pvc cementing the valve in place.  For the float switch, we fashioned a simple bracket from 1” aluminum stock from the local home improvement store.  After wiring the controller to the solenoid and float switch, the solenoid engaged after the expected delay and shut off when the float switch went open!  However, for the next few mornings, the tank was below the float trigger level meaning something wasn’t working as we thought.  After some pondering, we realized we had no hysteresis in the float switch sensing/triggering control software and theorized it could be that trying to trigger the solenoid on soon after triggering it off, could have put too much demand on the 9v battery and reservoir capacitor.  We added the logic in the software to prevent a retrigger within a period of time and this gave us reliability – no problems since then!

Next Steps

 We don’t know how long the battery will last and we’ll post that when we know as we don’t (yet!) have a multimeter than can measure in the microamps range (millamp range shows zero).  We also plan to test a tank with a flow meter plumbed inline to collect some statistics on water usage.  There are already Zigbee temperature sensors in use around the ranch, so adding this to the network with information about on/off cycles and usage would be interesting.

Do you have a use for this?

All the design files and software are here.

Kits are available for purchase if you prefer:

Board Options

Stock Tank Filler (STF) Kits

Creative Commons License
Stock Tank Filler by Zephyr-Labs is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.


Posted in Stock Tank Filler | 14 Comments