SPI connection: handling SS pin state

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
User avatar
kmiyazaki
 
Posts: 3
Joined: Tue Sep 02, 2014 12:33 am

SPI connection: handling SS pin state

Post by kmiyazaki »

I'm trying to develop a SPI connection program with BeagleBoneBlack Rev.C and Adafruit python library.
MOSI and CLK pins are able to be handled easily.
But, I cannot handle SS pin state (HIGH/LOW).
Both of changing cshigh value and output as GPIO does not influence to the state of SS pin.
How do I write the source code to change SS pin state ?

Refer to the attached image file.
Image
Image
BBB_SPI_SS_PIN.jpg (188.82 KiB) Viewed 445 times

User avatar
tdicola
 
Posts: 1074
Joined: Thu Oct 17, 2013 9:11 pm

Re: SPI connection: handling SS pin state

Post by tdicola »

When you're using SPI you won't be able to control the P9_17 pin from GPIO because the SPI device tree overlay will take over that pin and control it exclusively.

For the first bit of code you show, is your expectation that by setting SPI device cshigh = True/False that the pin will go high/low at that point? The cshigh attribute actually just controls if the CS pin is asserted with a high level (True) or low level (False). During the SPI read/write the Linux kernel spidev module will actually control setting the CS pin automatically at the start and end of the transaction. If you're curious the BBIO SPI code is based on the py-spidev module which has some documentation here so you can see more information on each member like cshigh.

If you're looking for a pin to explicitly control a chip select you probably want to grab one of the digital IOs on the board and use it instead of the CS pin P9_17. Try using a pin like P9_12 or P9_14.

Alternatively you might be able to just let the kernel control the CS pin and use P9_17 but don't try to explicitly change the cshigh parmeter, just set it to the appropriate True/False value if the chip should have CS asserted with a high/low signal respectively.

Let me know if that helps clarify the usage or you run into problems.

User avatar
kmiyazaki
 
Posts: 3
Joined: Tue Sep 02, 2014 12:33 am

Re: SPI connection: handling SS pin state

Post by kmiyazaki »

>> During the SPI read/write the Linux kernel spidev module
>> will actually control setting the CS pin automatically at the start and end of the transaction

Does "automatically" mean CS pin value vary at the transaction when cshigh attribute is set?

To be honest with you,
I'm going to port and develop from arduino program to BBB python program.

This figure show arduio signal pattern which I need.
SPI library of arduino defines SS pin as 10pin,
and this pin is able to be controlled as GPIO too.
So, I set CS value at the start and end of the transaction when output from MOSI with digitalWrite command.

I thought cshigh attribute at optimum timing, and output cs value in BBB programming.
But, my code does not work.
In this case, how do I write a code?
Or, should I use another pin as GPIO?
Attachments
140904arduino.png
140904arduino.png (337.6 KiB) Viewed 395 times

User avatar
tomis4cd
 
Posts: 68
Joined: Wed Mar 14, 2012 1:02 pm

Re: SPI connection: handling SS pin state

Post by tomis4cd »

kmiyazaki
I was inspired by your initial post and learned from it so I will share my learning test
First you do not need to try and wiggle chip select pin yourself it is done by the GPIO.SPI Lib.
Here is my test python program, note I comment out and back in to do various data transfers

Code: Select all

from Adafruit_BBIO.SPI import SPI
import Adafruit_BBIO.GPIO as GPIO
import time

print "GPIO Version is " + GPIO.VERSION

spi00 = SPI(0,0)

spi00.cshigh = False

spi00.msh = 500000


try:
  while( True):
#      spi00.writebytes([0xAA,0x55,0x80])
#       spi00.writebytes([0x01,0x90,0x00])
#       time.sleep(0.250)
      spi00.xfer2([1,(8+1) << 4,0])
      time.sleep(0.250)
except KeyboardInterrupt:
      GPIO.cleanup()
#finally:
GPIO.cleanup()
NOTE: I was not able to get SPI(0,1) to do any more than have chip select go low and stay low on program execute

Here is a pic's of using writebytes([0xAA,0x55,0x80]) and what looks like a bug in xfer2(...) of an extra chip select that has no other signals wiggling and is not any where near where the the next cycle of sending would be.
writebytes() does not do this.

Also note in the data out line an extra sliver just before the 0x00 value is sent it is much wider using xfer2() but is still there but barely using writebytes.

Tom
Attachments
xfer2(...) sending data with extra chip select
xfer2(...) sending data with extra chip select
smscope_222.png (64.28 KiB) Viewed 386 times
writebytes([0xAA,0x55,0x80])
writebytes([0xAA,0x55,0x80])
smscope_219.png (40.72 KiB) Viewed 386 times

User avatar
tdicola
 
Posts: 1074
Joined: Thu Oct 17, 2013 9:11 pm

Re: SPI connection: handling SS pin state

Post by tdicola »

kmiyazaki wrote:>> During the SPI read/write the Linux kernel spidev module
>> will actually control setting the CS pin automatically at the start and end of the transaction

Does "automatically" mean CS pin value vary at the transaction when cshigh attribute is set?

To be honest with you,
I'm going to port and develop from arduino program to BBB python program.

This figure show arduio signal pattern which I need.
SPI library of arduino defines SS pin as 10pin,
and this pin is able to be controlled as GPIO too.
So, I set CS value at the start and end of the transaction when output from MOSI with digitalWrite command.

I thought cshigh attribute at optimum timing, and output cs value in BBB programming.
But, my code does not work.
In this case, how do I write a code?
Or, should I use another pin as GPIO?
If you're porting Arduino code that manually sets CS high/low it might be easiest to use a different digital GPIO that isn't controlled by the SPI hardware on the beaglebone black. That way you can be sure the code you're porting has total control over the IO pin in case its used in unexpected ways.
tomis4cd wrote:kmiyazaki
I was inspired by your initial post and learned from it so I will share my learning test
First you do not need to try and wiggle chip select pin yourself it is done by the GPIO.SPI Lib.
Here is my test python program, note I comment out and back in to do various data transfers

Code: Select all

from Adafruit_BBIO.SPI import SPI
import Adafruit_BBIO.GPIO as GPIO
import time

print "GPIO Version is " + GPIO.VERSION

spi00 = SPI(0,0)

spi00.cshigh = False

spi00.msh = 500000


try:
  while( True):
#      spi00.writebytes([0xAA,0x55,0x80])
#       spi00.writebytes([0x01,0x90,0x00])
#       time.sleep(0.250)
      spi00.xfer2([1,(8+1) << 4,0])
      time.sleep(0.250)
except KeyboardInterrupt:
      GPIO.cleanup()
#finally:
GPIO.cleanup()
NOTE: I was not able to get SPI(0,1) to do any more than have chip select go low and stay low on program execute

Here is a pic's of using writebytes([0xAA,0x55,0x80]) and what looks like a bug in xfer2(...) of an extra chip select that has no other signals wiggling and is not any where near where the the next cycle of sending would be.
writebytes() does not do this.

Also note in the data out line an extra sliver just before the 0x00 value is sent it is much wider using xfer2() but is still there but barely using writebytes.

Tom
Yeah you might see some transients in the signal depending on the SPI mode since hardware only reads the data line state on specific clock transitions like rising/falling edge. As long as the data line as at the right spot during the transition then it can have unexpected pulses in between clocks. The CS dip is a little odd, but I wonder did you hit Ctrl-C and stop the program at that point? If so your code would hit the cleanup function which might close the SPI device and cause odd behavior.

In general the BBIO library is just a light wrapper around the Linux kernel's SPI support. If you're curious you can check out more details about the kernel's SPI support here: https://www.kernel.org/doc/Documentation/spi/spidev The BBIO commands under the covers are just reading and writing bytes to the /dev/spidev nodes in the file system.

User avatar
tomis4cd
 
Posts: 68
Joined: Wed Mar 14, 2012 1:02 pm

Re: SPI connection: handling SS pin state

Post by tomis4cd »

tdicola
No I was not hitting Ctrl-C for any of the pictures. The extra chip select is a steady signal when I
use xfer2() to send the bytes, not there using write bytes()'
A thought I have on the other glitch during the transmission of the three bytes just before the third byte
is that since I am just driving my scope it could just be letting go of the bus and the pin is just floating up
a bit. For the case of write bytes() I think that could be it but for xfer2() the glitch is a bit to wide.
If the last byte is 0x80 causing the pin to be high for the first bit of the third byte I do not see a glitch going
down.

Tom

User avatar
kmiyazaki
 
Posts: 3
Joined: Tue Sep 02, 2014 12:33 am

Re: SPI connection: handling SS pin state

Post by kmiyazaki »

Thank you for your comments! I got it!

Locked
Please be positive and constructive with your questions and comments.

Return to “Beagle Bone & Adafruit Beagle Bone products”