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.
SPI connection: handling SS pin state
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- tdicola
- Posts: 1074
- Joined: Thu Oct 17, 2013 9:11 pm
Re: SPI connection: handling SS pin state
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.
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.
- kmiyazaki
- Posts: 3
- Joined: Tue Sep 02, 2014 12:33 am
Re: SPI connection: handling SS pin state
>> 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?
>> 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 (337.6 KiB) Viewed 395 times
- tomis4cd
- Posts: 68
- Joined: Wed Mar 14, 2012 1:02 pm
Re: SPI connection: handling SS pin state
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
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
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()
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
- smscope_222.png (64.28 KiB) Viewed 386 times
-
- writebytes([0xAA,0x55,0x80])
- smscope_219.png (40.72 KiB) Viewed 386 times
- tdicola
- Posts: 1074
- Joined: Thu Oct 17, 2013 9:11 pm
Re: SPI connection: handling SS pin state
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.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?
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.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 transfersNOTE: I was not able to get SPI(0,1) to do any more than have chip select go low and stay low on program executeCode: 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()
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
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.
- tomis4cd
- Posts: 68
- Joined: Wed Mar 14, 2012 1:02 pm
Re: SPI connection: handling SS pin state
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
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
- kmiyazaki
- Posts: 3
- Joined: Tue Sep 02, 2014 12:33 am
Re: SPI connection: handling SS pin state
Thank you for your comments! I got it!
Please be positive and constructive with your questions and comments.