ECE497 SPI Project - Revision history

Yoder: /* User Instructions */ Typo

2012-12-23T21:10:30Z

‎User Instructions: Typo

Yoder: /* Installation Instructions */ fixed a typo: driver -> drivers

2012-12-23T20:58:34Z

‎Installation Instructions: fixed a typo: driver -> drivers

Larmorgs: /* Installation Instructions */

2012-12-02T07:58:10Z

‎Installation Instructions

Yoder: /* Grading Template */

2012-11-14T21:34:56Z

‎Grading Template

Larmorgs: /* Highlights */

2012-11-14T11:40:22Z

‎Highlights

Larmorgs: /* Highlights */

2012-11-14T11:39:36Z

‎Highlights

Larmorgs: /* User Instructions */

2012-11-14T11:08:17Z

‎User Instructions

Larmorgs: /* Work Breakdown */

2012-11-14T11:05:38Z

‎Work Breakdown

Larmorgs at 10:58, 14 November 2012

2012-11-14T10:58:45Z

Larmorgs at 10:35, 14 November 2012

2012-11-14T10:35:54Z

@@ Line 89: / Line 89: @@
 You may need to modify your muxes (if they have been changed from the default). If so, do the following:
   beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''
-  beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_sclk'''
+  beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_scl'''
 Now that the strand is hooked up, we can run the following:

@@ Line 70: / Line 70: @@
   bone$ '''mv modules.dep.bin modules.dep.bin.orig'''
-Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/driver/char/lpd8806.ko:</code>
+Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/drivers/char/lpd8806.ko:</code>
 Upon successful completion, you should be able to run the following:

@@ Line 48: / Line 48: @@
 All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code>
-Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:
+Start by cloning the [https://github.com/larmoreg/FinalProject github] repository on both the bone and the host machine by running the following:
-  both$ '''git clone git@github.com:larmorgs/FinalProject'''
+  both$ '''git clone git@github.com:larmoreg/FinalProject'''
 On the host machine, run the following:

@@ Line 7: / Line 7: @@
 <pre style="color:red">
-Executive Summary (Good start)
+Executive Summary
-Installation Instructions
+Installation Instructions (Too detailed to fully test at this time.)
-User Instructions (Missing)
+User Instructions
-Highlights (Missing)
+Highlights
-Theory of Operation (Missing)
+Theory of Operation (Nice details)
 Work Breakdown
 Future Work
 Conclusions
 Demo
-Late
+On time
 Comments: I'm looking forward to seeing this.
-Score:  07/100
+Score:  95/100
 </pre>

@@ Line 112: / Line 112: @@
 {{#ev:youtube|8d9n5QUyH38}}
-The file shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).
+The program shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).
 The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues. A good place for future work would be to figure out how the buffering problem can be alleviated.

@@ Line 109: / Line 109: @@
   bone$ '''make'''
   bone$ '''./test'''
 The file shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).

@@ Line 100: / Line 100: @@
   bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''
-The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code>. Buffering problems can cause the kernel to seg fault or crash completely</b>.
+The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code></b>. Buffering problems can cause the kernel to seg fault or crash completely (see Future Work).
 == Highlights ==

@@ Line 138: / Line 138: @@
 == Work Breakdown ==
-The work was broken down into two main tracks. On one side was the SPI interface and getting the light strand to work. The other track was getting a base driver working to integrate the SPI interface into.
+=== Sean Richardson ===
 == Future Work ==

@@ Line 112: / Line 112: @@
 The file shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).
-The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues (see Future Work).
+The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues. A good place for future work would be to figure out how the buffering problem can be alleviated.
 == Theory of Operation ==
@@ Line 124: / Line 124: @@
 So, as you write color values out on the SPI, the first chip receives them. If the chip hasn't written a color to one of its to LEDs, it does so and thus ends the transmission. However, if it has already assigned a color to each LED then it passes the SPI along on a separate bus to the next chip. This is how the strand is able to be 5m and still run at 10 MHz.
-It is still unknown how exactly the 3 latch bits are used (because the chip manufacturer has kept the interface a secret). However, if you write 6 bytes of "latch" the strand restarts at the beginning. Perhaps less bytes of "latch" can be sent and get the same effect, but due to time limitations we were unable to debug this completely.
+It is still unknown how exactly the 3 latch bits are used (because the chip manufacturer has kept the interface a secret). However, if you write 6 bytes of "latch" the strand restarts at the beginning. Perhaps less bytes of "latch" can be sent and get the same effect, but due to time limitations we were unable to debug this completely. This is a simple place to start for future work.
 === SPI Bus ===
@@ Line 137: / Line 137: @@
 == Work Breakdown ==
 == Future Work ==
 == Conclusions ==

@@ Line 25: / Line 25: @@
 For this project we wanted to further improve documentation available for sysfs kernel drivers with the Beagle Bone. To do this we have interfaced an [http://adafruit.com/products/306 LED light strand] by Adafruit with a sysfs kernel driver utilizing SPI. In doing so we have created an easy to use interface to the light strand while also maximizing data throughput.
 == Installation Instructions ==
-The kernel driver for SPI is installed in the A6A version of the beagle bone.
+All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code>
-We have integrated some code to work with a SPI radio device <span style="color:red">(What radio device?)</span>. The code is located at [https://github.com/larmorgs/ece497/tree/master/Project github].
+Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:
-To get started hook up pins 30 (D12) and 31 (A13) to SPI Data (sometimes referred to as Master) and SPI clock.
+ both$ '''git clone git@github.com:larmorgs/FinalProject'''
 [[File:Bone_P9_pinout.jpg]]
-Then echo 0 into both:
+You may need to modify your muxes (if they have been changed from the default). If so, do the following:
   beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''
   beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_sclk'''
-to select the pin mux for SPI.
+Now that the strand is hooked up, we can run the following:
-== Work Breakdown ==
+ bone$ '''cd /sys/firmware/lpd8806/device/'''
-So far we have done research on how Linux interfaces with SPI and we have integrated the SPI interface with current code that we have for an SPI radio. We also have explored methods of interfacing the SPI LED strip with a user to create a pleasant experience, such as creating a website to change the colors, or adding a possible twitter reader that would change the lights based on tweets.
+You should see the first LED (closest to the bone) light up bright white. You can also do something like the following:
-== Future Work ==
+ bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''
-We want to develop a driver that will interface with SPI and potentially create a sysfs userspace utility for the LED strip.
+The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code>. Buffering problems can cause the kernel to seg fault or crash completely</b>.
-== Conclusions ==
+== Highlights ==
-The SPI interface is not well developed in Linux and can use some work progressing it. We have taken on the task of getting these two devices to work in an easier manner.
+We have created a simple C example that uses this sysfs driver. You can run it by doing the following: