The pin SPI1_SSEL on the Cerb40II. Is that the SPI Chip Select?
@ Mr. John Smith - Yip, it is the chip select pin or slave select which is where what the abbreviation stands for.
1 Like
yip. But you can stipulate what CS you use in netmf so it probably isn’t that necessary 
@ Brett - Exactly; so is this like a default one? Why label that pin SPI1_SSEL? Is it some sort of hardware accelerated version or something?
Why? I honestly don’t know. I’ve not opened the uC datasheet to see if there’s a reason that this might be a simpler approach (for example the SPI hardware is optimised if you use this pin) and that netmf may not leverage.
Can anyone from GHI comment on why this was listed on the schematic?
I can try offer a little insight here.
First a disclaimer, I am just a hobbyist so my exposure to the various implementations of SPI peripherals is somewhat limited those that are more experienced/career embedded programmers should please step in where I have missed any nuances.
With that out of the way, I have seen the following variations which I believe can be attributed to the lack of real standardization around the SPI protocol.
[ul]SPI in Master mode - The SSEL pin can be configured to fulfill the SSEL function and the peripheral will drive the SSEL pin automatically. This is sometimes an issue because in this mode the pin is driven per byte transmitted, where as if you manually manage the pin you can drive the pin for the duration of a data stream. This is common on some of the LPC chips I have played with. Some of the documents actually mention that you will need alternate pin to enable the slave you are targeting, not something that is part of the standard but I am almost sure the LPC11u24 user manual says this. I will double check when I get a moment.
SPI in Master mode - The SSEL pin configured to fulfill the SSEL function but has no effect, the pin still acts like a normal GPIO pin. In this case, the SSEL mode is really only relevant if the peripheral is configured in Slave mode (see later)
SPI in Master mode - (I have only read about this, never seen it personally) the SSEL pin configured to fulfill the SSEL function and the peripheral will drive the SSEL pin automatically, if you maintain the data rate the SSEL is drive to select the device but if there is any delay the SSEL pin is released. This can have the advantage that data streams are efficient but any unexpected delays in the stream can cause the SSEL to flip-flop potentially causing issues on the slave (My assumption based on the strange ways I have seen slaves react to SPI)
SPI in Slave mode - Another one I have not actually implemented myself (yet?) so this is where I believe SSEL would be more useful, when you are implementing a slave and the peripheral can raise interrupts to notify you that the SPI Master has selected your device. This is however how I prefer to think about this pin, it is the slave select pin which indicates to the slave that it has been selected and should now start interacting with the master.[/ul]
So in Master mode it is common to rather just use a standard GPIO to drive the SSEL pin with the advantage that you have 100% control over the duration the slave remains selected and communicating with multiple slaves on the bus is easy as driving the appropriate SSEL pin.
The peripherals native SSEL function is appropriate when implementing an SPI slave module in code.
I hope that helps more than it muddies the water.
1 Like
Generally speaking, this pin is only needed in slave mode. It has limited and rather complex uses in master mode but I do not see how any of the scenarios would be needed with netmf.
@ Gus - Oh so then this is SPI_SlaveSelect; only used in the rare case that the device is in SPI slave mode (which doesn’t happen on NETMF).
Got it.