pinMode for CS pin in SPI extended mode

If the extended SPI library is used with the Due for hardware CS, it appears that the state of the CS pin must be INPUT. This is opposite then other Arduino boards where pin 10 had to be OUTPUT. See the following examples. This should be documented, or ideally the extended SPI.begin() function should set the mode of the CS pin to INPUT. If hardware CS is not used, the program would set the pin used for CS to OUTPUT, so having SPI.begin() set the mode would ensure it's set properly and avoid a common problem when switching from software CS to hardware CS.

If the pin mode for the CS pin is never set by the program, the hardware CS signal works.

SPI.transfer(10, 0);

If the pin mode for the CS pin is set as OUTPUT, the hardware CS signal fails (logic trace shows it floating).

  pinMode(10, OUTPUT);
  SPI.transfer(10, 0);

If the pin mode for the CS pin is set as INPUT, the hardware CS signal works.

  pinMode(10, INPUT);
  SPI.transfer(10, 0);

I don't understand why you bothering with this.

For the record, I am using two thermocouple boards from Adafruit to take measurements from two thermocouples, I am using SPI, everything works fine. To setup SPI I followed this:

and this:

pinMode, no pinMode, who cares?

For simple SPI access there's no need to worry about the pinMode. For more advanced applications where you need to disable the SPI module and control the pins directly, the pinMode setting matters when you return to normal SPI mode.

I had posted something similar here: bug on CS line using SPI library - Arduino Due - Arduino Forum and was asked to open a thread on github, but I think after I did that no one actually looked at it ^^ maybe you can redo it

I think this bug might be more serious than it first appears. Looking at the pinout diagram, Arduino pin 10 is connected to two different pins on the SAM3X, port pin C29 and A28. pinMode(10,OUTPUT) sets C29 as output and sets it high. But SPI.begin(10) would cause the SPI hardware to use A28, and drive it low when needed.

So I'd conject that pin 10 is not actually floating, but when the CS is selected it is being driven both high and low at the same time :astonished:

Adding pinMode(_pin,INPUT); to the beginning of the SPIClass::begin(uint8_t _pin) method ought to solve the problem.

has it been corrected?

With pinMode(CS, OUTPUT); You move CS pin control to PIO controller

With spi.begin(CS); You move CS pin control from PIO controller to SPI0 Peripheral

I cannot make it work. Now I would say the hw SPI CS control doesn't work. All the programs I found use software-based CS control. It's an aftermarket due board. I've tried it with all pins, 4, 10, 52