Hello, I need to address six devices on a single spi bus, and I’m hoping to avoid writing a device driver 
We will be updating from 3.8.13-bone68 as soon as there is a stable release of a newer kernel. So far, my research hasn’t turned up any indication that spidev can support the use of additional gpis’s for this purpose.
Will this be true with the new kernel? Has anyone addressed this?
Thanks for your help,
Tim
SPIDev will never be able to do this with any kernel. The BBB has two SPI ports and each are theoretically capable of a maximum of 4 CS lines each. However only two CS lines on each port are made available to the pinmux and of those two I am pretty sure second CS line on SPI0 has not been brought out to the P8 or P9 headers by the designers of the BBB.
The upshot is that using the internal CS lines, which is what SPIDev does, you can have a max of one device on SPI0 and two on SPI1. Also note that SPI1 conflicts with the HDMI device and so to enable it you need to disable the HDMI display. None of this is SPIDev’s doing - it is just supporting the hardware state it is given.
So if you want more CS lines you need to ignore the internal CS lines and simulate them with GPIO’s. The BBBCSIO library has transparent support for this but it is intended for mono/C# and needs the BBB to be running an armhf kernel. You may find there are Python libraries which can do this too.
BBBCSIO (in case you need the link): http://ofitselfso.com/BBBCSIO/BBBCSIO.php
Nic Cyn, thanks for the response. This summarizes what I had seen, but I wasn’t sure that my interpretation was correct. It looks like we will go with wrapping the transfer with our own GPIO toggles.
Unfortunately, we won’t be using c# but I was looking at your code and noticed:
/// Also NOTE that if you use the GPIO based slave select lines you cannot
/// also connect anything to the SPI devices internal CS0 or CS1 slave select
/// lines. These will always be activated on every write irregardless
/// of the GPIO based slave select also asserted. This is just the way the
/// SPIDev driver works.
I see “SPI_NO_CS” defined in spidev.h, but I don’t see any reference to it in spi-omap2-mcspi.c - is that the reason for your comment?
Thanks again,
Tim
Hi Tim
That comment in the source code is based on the fact that, with SPIDev you don’t open the SPI port and then tell it later what CS line you wish to use. SPIDev associates both the port and the CS line with the device file and you open one of those for each CS device. For example /dev/spidev1.0 and /dev/spidev1.1 both send and receive through the SPI0 port but one activates the CS0 line and the other the CS1 line during transmission.
All the code comments are saying is that if you are using GPIOs as CS lines you can either open /dev/spidev1.0 or /dev/spidev1.1 (for example) so you can write to the port but you should not electrically connect anything to the pin where the corresponding CS line is located. Every transmission through the port will always toggle the devices associated CS line - there does not seem to be any way to tell it not to do that. If you have a device connected to that built in CS line it will get activated along with whatever device you are also activating with the GPIO. This would cause two slave devices to try to write to the SPI bus at the same time - not good.
I can’t recommend this book highly enough. There is a section in Chapter 8 which shows how to get more CS controls using the GPIOs and simple external logic.
This chapter alone will make the price of the book worth it.
Regards,
Greg