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
On Friday, January 23, 2015 at 6:14:14 AM UTC-8, Nic Cyn wrote:
>
> 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
>
>
> On Thursday, 22 January 2015 19:18:05 UTC, codemonkey wrote:
>>
>> 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
>>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
