Trying to use SPI with a 595 shift register - no luck

I’m having a heck of a hard time trying to get a 595 working with the Spider. While I could simply be grasping here, I think the root of the problem is that CS never goes low.

In the attached screen shot, you can see the result of sending 0xFF to SPI. Ignore the clock edges, I was playing around with active high/low there.

However, no matter what I do, I can’t get enable to go low when done. Instead, strangely, MOSI goes low when done and stays there for some chunk of time - almost 6ms. With the clock off, MOSI shouldn’t matter, but I really want CS/Enable to follow the config setting.

public LedArray(int socketNumber)
    _socket = Socket.GetSocket(socketNumber, true, this, null);

    SPI.Configuration config = new SPI.Configuration(

    Debug.Print("ChipSelectActiveState: " + config.ChipSelectActiveState);
    _spi = new SPI(_socket, config, SPI.Sharing.Exclusive, this);


public void SetPattern(byte ledPattern)
    _spi.Write(new byte[] { ledPattern });

I tried setting up SPI as shared as well, in case that was it. Nope.

This was going to be for my demo tonight, but I’m not so sure now :slight_smile:


Hi Pete !

Eventualy have a look at my driver for an SPI 8xLED display here:

It is no more than 8x 74HC595 cascaded… Could not find the schematics, though !
Look at the parameters I passed to the SPI constructor.

Have fun :wink:

Thanks. I wanted to use just Gadgeteer code, but I could fall back to that if I needed to.

So, I hacked pin 3 into a CS pin and now it’s working.

While I can’t rule out something I did, it appears the SPI code for the Spider/Gadgeteer isn’t properly setting the CS pin.



There are two constructors for Gadgeteer.Interfaces.SPI:

public SPI(Socket socket, Configuration spiConfiguration, Sharing sharingMode, Module module)
public SPI(Socket socket, Configuration spiConfiguration, Sharing sharingMode, Socket chipSelectSocket, Socket.Pin chipSelectPin, Module module)

Please try the one that specifies the chip select :slight_smile:


@ james

Why would I need to do that? The SPI socket specification says the pins should be used this way:

Socket Type S
[ulist]Pin 6: CS
Pin 7 MOSI
Pin 8 MISO
Pin 9 SCK[/ulist]

It looks like the second constructor would have avoided my manual CS hack, but it shouldn’t really be needed.