How to set up the SPI for BBB

After reading a lot of threads, I am still a little confused about device tree mechanism. Could anyone give me a overview of how it works?

  • Update device tree on run time is called overlay. It need to create a .dst file and compile it. then put it into a directory.
  1. it will tell kernel turn on the SPI hardware

  2. Set the pin to correct model, so that the signal is available at headers

  • Then I need to install spidev, which is the driver of SPI in linux

This is my understanding, I would be surprised if it is correct, So please point out where ever I am wrong.

BTW, I have some silly question again:

  1. Some guy mentioned SPI1 is used by HDMI, however, after I went through the BBB_SRM. I merely found Table13. P8 LCD conflict Pin on Pg.87 shows the pin that hdmi uses. SPI1 is on P9, so where do you guys finger out that SPI1 is used by hdmi.
  2. where can I find source of BONESCRIPT, or how do you find where is the source of bonescript.
  3. On BBB_SRM.pdf page 96, the table shows AIN0-AIN3 is on P8, it is different from Table 11 on page 77. is it typo?

I second this request if there is a kind and patient person who’d be willing to spend the time to write a devicetree/pin muxing tutorial for newbies. I’ve spent a week sifting through posts here, reading through all the blog pages, and looking over technical type pages…and something just doesn’t click. I’m not sure I understand enough about what I don’t understand to ask properly directed questions so I’ve sort of come to a halt.

I suspect with the BBB being adopted by more and more people that there will be a lot of folks like me who have never used Linux but are familiar with something an Arduino or PIC board and want to hop right in and start developing their projects. It’s a bit daunting to say the least - the amount of stuff to learn in order to get SPI enabled for instance. I think more and more people are going to be asking the same questions, it’d be awesome to have a good intro tutorial to point to that folks could read - I know I’m ready to put my Arduino on the shelf if I could just start harnessing the BBB and probably lots more people behind me ready to do the same!

Tianlan - the one question I can answer is the bonescript source I’ve found at:

To disable HDMI:
Put this into uEnv.txt on the small FAT-Partition:

#optargs=quiet drm.debug=7
# Bin headless (ohne Monitor), deshalb HDMI abschalten, gibt P9.31 fuer SPI1-Bus frei.
optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI


IMHO SPI should be removed from the “feature” set for the Beaglebone, Beaglebone Black, and Pandaboard. Even if you manage to configure and build a kernel with SPI support you will find it suffers from random long latencies in the 4-15 mS range running a 1 mS servo loop. I’ve posted real time priority test code that shows the issue with SPIDEV and shows essentially perfect timing if a GPIO output is toggled instead of doing a SPIDEV write, proving the latency is in the SPI device system calls.

The Beagleboard has so far shown the best performance with this test code, but still is not good enough.

I’ve attached the test code here again for your convenience, although the SPIDEV and GPIO names will need to be changed to match your board and kernel, as this is for the Pandaboard.

If anyone can run this test code and get SPIDEV worse case latency below 1.5mS I’d love to know about it and which board and kernel you are using!


swave_spidev.c (13.9 KB)

I’m suffering from Google fatigue. Could you provide a link to or summary of Carl’s instructions? I’m SPI-less.

it’s here:

big thanks! not sure how that particular thread eluded me

Thank you for running the test program and reporting the results. I hope someone figures out the problem sometime soon.

Some more:

Using spidev.
Using realtime priority.
Interval Max(mS): 1.6 @N=721 Min: 0.4 @N=722 Total Samples: 300000
spidev time Max(uS): 1518.5 Min: 56.6
Intervals +50% over N: 1 0.0% -50% under N: 1 0.0%
drops, N intervals >= 2 mS: 0 0.0%

arau@beaglebone1:~$ uname -a
Linux beaglebone1 3.8.13-bone26 #1 SMP Sat Aug 17 00:43:59 UTC 2013 armv7l armv7l armv7l GNU/Linux

arau@beaglebone1:~$ more /etc/lsb-release

More results from an older kernel:

Using GPIO 32.

Using realtime priority.
Interval Max(mS): 2.6 @N=250399 Min: 0.1 @N=250401 Total Samples: 300000
gpio time Max(uS): 1232.5 Min: 7.8
Intervals +50% over N: 37 0.0% -50% under N: 38 0.0%
drops, N intervals >= 2 mS: 20 0.0%

cprov@bone-one:~/spi$ uname -a
Linux bone-one 3.8.8-bone14 #1 SMP Wed Apr 24 13:59:33 UTC 2013 armv7l armv7l armv7l GNU/Linux

cprov@bone-one:~/spi$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 13.04
Release: 13.04
Codename: raring

maybe someone can take a short look at my problem …!category-topic/beagleboard/spi/pVmvrNJdmLk

thank you !

Now this performance is almost there and would probably be OK for us. This is on Beaglebone Black, correct?

Thank you so much for running this test code. I’ll endeavor to install this 3.8.13-bone26 kernel and I’ve always preferred a Ubuntu root file system, hopefully I can get this project back on track in a couple of weeks after I return from a much needed vacation.


Its the using spidev results that are the issue, the GPIO bit option was just to “prove” the real-time code was correct enough to not be the problem, and it wasn’t userspace to kernel and back overhead that was causing the long latencies latencies.

To use spidev the test program needs to be edited for the proper /dev/spidevX.Y device name string and launched as: “swave_spidev spi” as root user for realtime priority. The nature of spidev means no actual hardware needs to be connected to the spi pins.

Seeing what kernel version the apparent fix happened might be helpful in also solving the issue on Beaglebone and Pandaboard as well.

As was discussed here a while ago: The BeagleBoard xM with v3.7.10-x10 up to now had been the closest to being real-time enough.


Utilizing spider, is there a simple way to control SPI timing parameters to match specifications of slave devices?

I’m interested in controlling various parameters such as setup/hold times, data valid times, etc.