What's the point of the CS pin?

[johnnyfp]

Can someone enlighten me please as to the point of a dedicated labeled CS pin, as in that the CS pins is labeled as such, but it seems that the SPI library or possibly even the SPI Hardware module, doesn't actually use it. And you can use any IO pin for CS.

A lot of the SPI based code that uses the SPI library always seems to set the CS pin in a digitalWrite prior to a transfer, Point taken from the barmetric IDE supplied example

void digitalPotWrite(int address, int value) {
  // take the SS pin low to select the chip:
  digitalWrite(slaveSelectPin,LOW);
  //  send in the address and value via SPI:
  SPI.transfer(address);
  SPI.transfer(value);
  // take the SS pin high to de-select the chip:
  digitalWrite(slaveSelectPin,HIGH); 
}

Also looking at the SPITransaction code, it also doesn't seem to use it.

Am I missing something here?

 

[MichaelMeissner]

http://en.wikipedia.org/wiki/Chip_select

 

[johnnyfp]

Yes, that is correct if it was actually used as such. However on the teensy the CS pin is not controlled by the SPI module, but the driving code. Which as such means that any pin can be used as a CS pin.
So again, what is the point of labelling an arbitary pin as CS, where any pin could be CS?

 

[defragster]

I supposed the Teensy Card labeling a select few pins as "CS" capable had the meaning that they had necessary hardware to support full and proper use as a CS pin. Not all pins have FULL CS capability when it comes to ideal usage. Recent posts I've scanned suggested that the v3.1 FIFO can hold commands to alter CS between byte transmissions - and that specialized behavior I suspect only works on these indicated pins.

 

[Cosford]

I guess it comes down to the fact that whilst the hardware SPI modules are set up to be able to manipulate it internally; there's very little lost in just opening up the functionality to other pins using the nearly just as fast digitalWriteFast methodology, which lets us have a lot more control over exactly what we're doing with the CS pin.
There's also the arduino compatibility factor; with this methodology, emulation of the AVR libraries is a lot quicker and easier.

So in short; it's easier, simpler and more compatible.

 

[johnnyfp]

Ok. That's fine then. Was just pulling my hair out this morning because for the life of me I couldn't understand why my CS pin was not polling as it should. Then realized that I actually had to assert said pin, made me wonder why the labelling.

I think it would be good, specially in the SPITransaction library to add that functionality into the SPISetting class so that way you would not have to worry about setting up the CS pin. And thus you could have multiple Transactions to different SPI devices and encompass the CS to that transaction class.

 

[defragster]

I just found this window open: https://github.com/sumotoy/RA8875

it has this note - I infer from this that Arduino SPI libs might work as written, but to get use of full 'highly optimized' hardware support you have to use special pins . . .

Teensy notes:
I love Teensy 3 MCU's, so every library has special features for this micro. This one works with highly optimized SPI that can works with Audio Board and SD card without interfere and at max speed possible. I'm currently adding support for Teensy LC that seems perfect for use with RA8875 so stay tuned for changes.Please note that Teensy3 and 3.1 cannot use any pin for CS as Arduino!!! You need to read my notes about wiring first. Some examples works only for Teensy 3.

 

[johnnyfp]

Ok delving in deeper into the SPI library, I was actually looking at the AVR section and not the mk20 section, how embarrassing .

So it looks like you can set the CS pin and it sets up the correct MUX for it. Going to try that out now and see if CS actually behaves itself.

 

[PaulStoffregen]

I guess the SPI library page should (eventually) get a section explaining hardware vs software controlled chip select.

 

[defragster]

Paul: as far as updates - looking at linked (msg#9) page I saw this 'example' line as maybe a bit out of tune with today's most common R/W displays?:

Thus, some chips need only 3 or even 2 of these signals; a display, for example, will use MOSI but not MISO, as it is an output only device.

 

[defragster]

This blog by Paul gives some more feel for how Teensy SPI is improved by its better hardware - there is more there on SPI too: http://www.dorkbotpdx.org/blog/paul/display_spi_optimization