Andrew B. Wright, Ph. D., SM ’88
I was going to use the analog inputs to connect the yaw rate sensor to the beaglebone. However, there are so many really cool i2c sensors around. So, I’m going to try out an adafruit 9-dof sensor for the navigation (adafruit 1714). If the only sensor needed is yaw rate, so be it. But, the extra functionality of all those extra inputs could be useful for expansion. It doesn’t hurt that all the extras cost less than one yaw rate sensor.
The mounting hole pattern uses 4 holes (0.06″[?] diameter) on a 0.7″ x 1.3″ grid), and the board fits inside 1.9″ x 0.9″ rectangle. The addresses for the 3 different sensor packages are 0x19 (accelerometer?), 0x1e (magnetometer?), and 0x6b (gyroscope).
i2c from the command line
The adafruit 1714 shifts the voltage level up to 5v on the output pin if you apply 5v to Vin. Beaglebone wants 3.3v, so connect 3.3v to either Vin or 3.3Vo, and SDA/SCL will be referenced to 3.3V.
There are four signals: ground, power (3.3 v on the beaglebone), SCL, SDA. I don’t know whether I’ll need to provide signal conditioning between beaglebone and accelerometer, but I think it’s handled at the accelerometer.
The i2c bus allows daisy-chaining of sensors. In that case, SCL is connected to SCL and SCA is connected to SDA. There is no cross-over. I’m not sure how many sensors can be connected in series. I’m not sure if a terminator is required (ala SCSI). I think this is an electrical engineering thing, and your mileage may vary.
The i2c signals on the beaglebone’s expansion header occupy the following pins (3.3 v through pull-up resistor):
i2c-1: P9-18 (sda)/P9-26 (sda) and P9-17 (scl)/P9-24 (scl)
i2c-2 P9-20 (sda) and P9-19 (scl)
In addition: P9.21, P9.22 are i2c pins.
Of these pins, only P9-17 (sda) and P9-18 (scl) appear to be totally free (NOTE: now, I’m experiencing difficulty this morning. Could it be because I had the i2c connected at boot? Nope. Looks like some random weirdness.). So, that’s the i2c to start with. (NOTE: lets of the internet examples use a different pin configuration [P9-19, P9-20]. I found that config-pin would not let me set those pins [although, this morning, they’re preconfigured to sda, scl]. This uses i2c2.) [NOTE: this may be because I ran i2cdetect before running the config-pin commands. Remember to config-pin P9.17 i2c config-pin P9.18 i2c
Actually, i2c1 is not available at all. I seem to remember this is something discussed on the internet.
i2cdetect -r <0,1,2>
allows you to poll for addresses on /dev/i2c-<0,1,2>.
Vin (pin 1 on the 1714 header) to pin P9.3 (3.3v)
Gnd (pin 3 on the 1714 header) to pin P9.1 (gnd)
SCL (pin 4 on the 1714 header) to pin
P9.17 (i2c1 scl) P9.19 (i2c2 scl)
SDA (pin 5 on the 1714 header) to pin
P9.18 (i2c1 sda) P9.20 (i2c2 sda)
SCL and SDA are bi-directional. So, you can connect this backwards (SDA-SCL, SCL-SDA), and it won’t work. However, Beaglebone will talk on both pins. So, a ‘scope test on the pins will give data on both lines.
When I ran
i2cdetect -y 1
I received 0x19, 0x1e, and 0x6b, which are the addresses of the sensor.
i2cget -y 2 0x19
gives the response 0x00.
i2cget -y 2 0x1e
gives the response 0x10.
i2cget -y 2 0x6b
gives the response 0x0a (register 0x0).
To get a specific register, run the command
i2cget -y 2 0x6b 0xf b
which will show you one byte (b) of register, 0xf, on i2c2 (-y 2) for device 0x6b.
i2cdump -y 2 0x19 b
i2cdump -y 2 0x1e b
i2cdump -y 2 0x6b b
allows you to dump the registers on the device. This dumps byte-by-byte (b) rather than word-by-word (w).
In order to make sense of the data, you need to look at the data sheet for your device to determine what all those bytes mean.
On the c-coding.
The first steps of opening and closing the device are easy. Figuring out how to read and write and what you’re reading and writing is another story.
Luckily, I found some good examples and looked through the header files (linux/i2c-dev.h, linux/i2c.h). Here is a hacked up program that let’s you read something from the i2c. This example reads from device 0x6b register 0xf (WHO_AM_I). Return value is 0xd7, which matches the spec.
The main features of this are the data definitions and their interactions with the ioctl function.
Put this code in a file called i2c.c and compile it using
gcc -o i2c i2c.c
Run it from the command line using
A more extensive example that reads words from the z axis of the sensor, polls to determine when data is ready, and converts the data to degrees per second (dps) is here:
For this example, the defaults are taken for the sample rate (100 Hz) and the sensitivity (245 dps). These values are determined from the CTRL registers.
Low Output Data Rate (ODR) is set by register 0x39. The default is as 0 for “low speed ODR disabled.”
Table 21 of the data sheet indicates that CTRL1 sets the default ODR with “low speed ODR disabled” to 100 Hz with a low pass filter cut-off of 12.5 Hz.
The sensitivity is set by CTRL4 as 245 degrees per second for full scale. (Other values are 500 dps and 2000 dps.) Data is 16-bit, 2’s complement. So, full scale is 0x7fff. The high bit 0x8000, determines the sign.
CTRL4 also sets the endianness. Picking the right endianness allows your program to correctly process ‘word’ reads instead of ‘byte’ reads and doing the byte shifting.
This example polls the status bit for the z-axis to determine when data is ready before making a read.
Doing it from the PRU:
In order to have this work from the PRU, the open, close, and ioctl functions must be replaced or replicated by the PRU.
I presume at this point, this only requires setting up of the i2c registers (see Chapter 21 of the TRM). By default, i2c0 and i2c2 are enabled for the ARM. It might be best, in using the PRU, to use i2c1 (assuming it’s unoccupied).
For my application, the yaw rate sensor is not the highest priority sensor to read from the PRU, so I’m likely to deprioritize this for the near term so as to complete other work. (7/6/2017)
The ioctl call with I2C_FUNCS allows you to see what functions are implemented on your device. It is probably wonderful for a generic driver. For a specific device, you can call it in the testing phase to see if smbus is enabled. If not, the coding will be harder. The two sensors I picked returned the following function value, 0xefe000d. This indicates that smbus is implemented.
The header file, <linux/i2c.h>, defines the structure for transport, i2c_smbus_data. The other header file, <linux/i2c-dev.h>, defines the ioctl structure, i2c_smbus_ioctl_data. Put the right bits into these structures and call ioctl(<pointer to device from open>,I2C_SMBUS,<pointer to i2c_smbus_ioctl_data structure>), and … presto-magico … you can write to registers and read from registers (including the sensor data).
Add a 4-pin header to the cape. Pull in ground and power from the rail. Add a level adjuster chip if necessary.
Beaglebone i2c is multi-master with slow data xfer (100k bits/s) and fast (400k bits/s).
i2cset tbd tbd
allows you to set a register.
adafruit flora (1356): TCS34725 with code library [put this in the next blog]