5

I have run raspi-config and enabled SPI and also verified that /boot/config.txt contains the line:

dtparam=spi=on

However, when I run lsmod | grep spi I get the following:

spidev                 16384  0
spi_bcm2835            16384  0

In /dev I can see: spidev0.0 and spidev0.1.

Is SPI enabled and functional? I have a feeling it's not working because my SunFounder LED screen, which relies on SPI, is not working.

glenneroo
  • 155
  • 1
  • 1
  • 8

2 Answers2

4

I have been using raspi-config always found it working. Sometimes my modules are not working. So I usually use two little test programs to check. One program is to repeatedly send out bytes and use a scope to make sure the waveform looks OK. The other test program is a loop back test. I connect MOSI to MISO, send a byte and read back.

You might like to try my test program. It is plug and play, no libraries are required.

I have tested my program with IDLE python. To run in terminal mode:

Don't forget to run with sudo - otherwise the loopback test recvByte returns 0x0. – @glenneroo Apr 24 at 20:49

# spi_test05 tlfong01 2019apr07hkt2043 ***

# Computer = Rpi3B+
# Linux    = $ hostnamectl = raspberrypi Raspbian GNU/Linux 9 (stretch) Linux 4.14.34-v7+ arm 
# Python   = >>> sys.version = 3.5.3 Jan 19 2017

# Test 1   - repeatSendByte() - SPI port repeatedly send out single bytes.  
# Function - Repeat many times sending a byte, pause after each byte.

# Test 2   - loopBackTest()   - SPI port send and receive one byte.
# Function - Send one byte to MSOI and read it back from MISO. 
# Setup    - Connet MOSI pin to MISO pin to form a loop.

from   time import sleep
import spidev

spiPort0 = spidev.SpiDev()
spiPort0.open(0,0)
spiPort0.max_speed_hz = 100000

def spiSendRecvOneByte(spiPort, sendByte):
    sendByteArray = [sendByte]
    recvByteArray = spiPort.xfer(sendByteArray)    
    return recvByteArray

def repeatSendOneByte(spiPort, sendByte, pauseTimeBetweenBytes, repeatCount):
    print('\nBegin repeatSendByte(),....')
    for i in range(repeatCount):
        spiSendRecvOneByte(spiPort, sendByte)
        sleep(pauseTimeBetweenBytes)
    print('End   repeatSendByte().')
    return

def loopBackOneByte(spiPort, sendByte):
    recvByteArray     = spiSendRecvOneByte(spiPort, sendByte)
    recvByte          = recvByteArray[0]

    print('\nBegin testLoopbackOneByte(),....')
    #print('')
    print('      sendByte  = ', hex(sendByte))
    print('      recvByte  = ', hex(recvByte))
    #print('')
    print('End   testLoopbackOneByte(),....')
    return

def testRepeatSendOneByte():
    repeatSendOneByte(spiPort0, 0x5b, 0.0001, 20000000)
    return

def testLoopbackOneByte():
    loopBackOneByte(spiPort0, 0x5b)
    return

testRepeatSendOneByte()
#testLoopbackOneByte()

''' Smple output tlfong 01 2019apr07hkt2047
Begin testLoopbackOneByte(),....
      sendByte  =  0x5b
      recvByte  =  0x5b
End   testLoopbackOneByte(),....
'''

# *** End ***

Appendices

Appendix A - SPI Pinouts

rpi spi pinout

tlfong01
  • 4,665
  • 3
  • 10
  • 24
  • Don't forget to run with sudo - otherwise the loopback test recvByte returns 0x0. – glenneroo Apr 24 '19 at 20:49
  • Ah, many thanks for pointing that. Actually I wrongly assume that the program is always run in IDLE which doesn't need sudo. I should remember to add the remark in the next version that don't to run with sudo if the program is run in text mode. – tlfong01 Apr 29 '19 at 14:59
3

SPI is working.

The needed modules are loaded (spidev, spi_bcm2835) and the needed devices are present (dev/spidev0.0 /dev/spidev0.1).

joan
  • 71,024
  • 5
  • 73
  • 106
  • "Working" as in recognized by the OS but not necessarily operational. Using @tlfong01's loopback script, receiving data on MISO doesn't work on this Pi but running the script on a different Pi (using the same SD card) works as expected. – glenneroo Apr 24 '19 at 17:43
  • @glenneroo Did you read the question "Is SPI enabled?". The answer is yes. – joan Apr 24 '19 at 18:02
  • Fair enough, I should have been more accurate framing my question, though my contention stems from the use of the word "working" which in my case is not the case. – glenneroo Apr 24 '19 at 18:32
  • 1
    @glenneroo I suggest you test the GPIO. pigpio's gpiotest or wiringPi's pintest. If that passes it sounds like a wiring problem. – joan Apr 24 '19 at 18:58
  • Indeed both test programs return OK for all GPIO pins on both Pi devices. For the loopback test I triple-checked that the cable connects only MOSI to MISO - identical for both devices. – glenneroo Apr 24 '19 at 19:39
  • 2
    @glenneroo Okay, Connect GPIO 10/9 (pins 19/21). Then enter the following commands. sudo pigpiod then pigs spio 0 50000 0 then pigs spix 0 23 45 67 89 12 13. If the response is 6 23 45 67 89 12 13 then SPI is okay. – joan Apr 24 '19 at 20:24
  • That outputs correctly. Interestingly, tlfong01's python script also runs fine now as well -- edit: my mistake, I was running without sudo, with sudo it works fine. – glenneroo Apr 24 '19 at 20:47
  • @glenneroo That shows the SPI hardware is fine. That leaves the software you are using or the wiring as the problem. – joan Apr 24 '19 at 21:15
  • you should consider adding the 'pigpiod' test information to your answer as it might help others and should IMHO not be relegated to deep in the comments. – glenneroo Feb 26 '21 at 19:16
  • this SPI test script is super helpful, as are the pigs and pigpiod comments. SPI needs something like i2cdetect to test basic functionality – Marc Compere Aug 17 '23 at 14:53