Summary of mysteries about SPI and extended SPI library with Due

I succeed to put on work an Arduino Due, an Ethernet shield, a SD card and a MP3 Shield from Sparkfun, using the following libraries:

  • Ethernet library from Arduino. Use extended SPI functions with pin 10 as chip select
  • SdFat library from Bill Greiman. Use former SPI functions. Chip select is 9
  • SFEMP3Shield from Bill Porter and Michael Flaga. I modified it and use extended SPI functions with pin 4 as chip select

All of them used intensively the SPI bus.
Of course, it did not work at first try. So I read (all ?) the posts about SPI and Due in this forum, and I make a lot of tries.
I will summarize all the information I read and discover about SPI and Due.

  • pins for Chip Select. It can be any digital pin of Arduino Due. But only pins 4, 10 and 52 gives advantages of extended SPI

  • particularity of pin 52. It is the "Board Spi default chip select". BOARD_SPI_DEFAULT_SS is defined in
    arduino-1.5.1r2\hardware\arduino\sam\variants\arduino_due_x\variant.h
    as BOARD_SPI_SS2 defined in the same file as pin 52
    That is to say that calling SPI.begin() is the same as calling SPI.begin( 52 ).
    So if you have a device using former SPI functions ( like SdFat ) , whatever it use a different pin for chip select, you cannot use pin 52 as chip select for an other device.

  • pinmode( CS, OUTPUT ) . Do not include this instruction in your sketch for pins 4 and 10.

  • advantages of extended SPI library? With other pins than 4, 10 and 52: none. When you have 2 or more devices using SPI, you have to reprogram attributes (speed, datamode, ...) and to set chip select to low before doing a transfer. If you read from a device to write to an other (ethernet to SD card, SD card to MP3, ...), this is a big constrain. With extended SPI using pins 4, 10 or 52, no need to do this. Only call SPI.transfer

  • use of additional parameter SPI_CONTINUE or SPI_LAST (the default) with SPI.transfer . I have no absolute answer.
    Sometime it works without specifying SPI_CONTINUE, sometime it works only if you specify it, sometime it don't work if you specify it.

I hope this would help.
Any body has more information?

Thansk a lot, has been really usefull for me!!!!!!!!!!!1

If you post some sample code it would be cool.

Thansk a lot, has been really usefull for me!!!!!!!!!!!1

Happy to help you!

If you post some sample code it would be cool.

I now replace the Ethernet shield with a faster WIZ820io (see that post on the forum)
I explain here how to put together the parts and how to load and modify the libraries.
In my fork of SFEMP3Shield there is an example (WebRadio.ino) that use that hardware to listen to streamed radios up to 320 kb/s

hi, I was wondering how you connected the hardware since I have due and I see that due doesn't have pin 11,12 and 13 as SPI bus signals. I researched for a while and this is the best post out there on MP3 Shield + Arduino Due using SPI bus. Please help, I'd very much appreciate it.

Hi, I need some help with a project. I currently have a due running a coldtears 7' TFT with sd shield and have been trying to hook up a Ladyada pt100 shield to read an rtd as well. I can hook up both individually and get them to run, however I cannot get the pt100 to read as well when the tft is set up. The tft shield uses pin 53 as cs pin. Can anyone show me some code for using the extended spi so I can figure out how to get the rtd to read?
Any help would be greatly appreciated.
Aidy

gallegojm:

  • pins for Chip Select. It can be any digital pin of Arduino Due. But only pins 4, 10 and 52 gives advantages of extended SPI

  • particularity of pin 52. It is the "Board Spi default chip select". BOARD_SPI_DEFAULT_SS is defined in
    arduino-1.5.1r2\hardware\arduino\sam\variants\arduino_due_x\variant.h
    as BOARD_SPI_SS2 defined in the same file as pin 52
    That is to say that calling SPI.begin() is the same as calling SPI.begin( 52 ).
    So if you have a device using former SPI functions ( like SdFat ) , whatever it use a different pin for chip select, you cannot use pin 52 as chip select for an other device.

  • pinmode( CS, OUTPUT ) . Do not include this instruction in your sketch for pins 4 and 10.

I am struggling with DUE and found these notes.
I displayed SS constants and I find the BOARD_SPI_DEFAULT_SS to be 78, which does not correspond.
Also, SS is 10 and not 52.
And more, I cannot find the variant.h file.
In my installation (Arduino IDE 1.8.5) there is no such path: \hardware\arduino\sam\variants\arduino_due_x\variant.h
Searching the hard disk yielded no results, and yet, I can use arduino DUE, so, undoubtedly its core and relates files and information must be somewhere.

Any ideas?

To find that constant definition, in an IDE window, select File>Preferences. Click in the URL at the bottom of the opened window: C:\Users...\AppData\Local\Arduino15\preferences.txt

Then follow this path:
packages/arduino/hardware/sam/1.6.x/variants/Arduino-due-x/variant (an .H file)

Extract from this file:

/*
* SPI Interfaces
*/
#define SPI_INTERFACES_COUNT 1

#define SPI_INTERFACE        SPI0
#define SPI_INTERFACE_ID     ID_SPI0
#define SPI_CHANNELS_NUM 4
#define PIN_SPI_SS0          (77u)
#define PIN_SPI_SS1          (87u)
#define PIN_SPI_SS2          (86u)
#define PIN_SPI_SS3          (78u)
#define PIN_SPI_MOSI         (75u)
#define PIN_SPI_MISO         (74u)
#define PIN_SPI_SCK          (76u)
#define BOARD_SPI_SS0        (10u)
#define BOARD_SPI_SS1        (4u)
#define BOARD_SPI_SS2        (52u)
#define BOARD_SPI_SS3        PIN_SPI_SS3
#define BOARD_SPI_DEFAULT_SS BOARD_SPI_SS3

You can try SPI library example sketches that you will find in : File>Example>SPI.

AFAIK, any digital output pin can do the job for a chip select CS with the SPI library because this library do not leverage the automatic handling of the CS pin by the SPI0 peripheral.

If you program SPI registers (as I do) without the library, you can use one of the following 3 SPI CS pins: PA28 (CS0 = pin 10), PA29 (CS1 = pin 4), PB21 (CS2 = pin 52) and SPI0 peripheral will handle automatically the CS pin state. You can find these pins page 679, SPI section of Sam3x datasheet.

ard_newbie:
To find that constant definition, in an IDE window, select File>Preferences. Click in the URL at the bottom of the opened window: C:\Users...\AppData\Local\Arduino15\preferences.txt

Then follow this path:
packages/arduino/hardware/sam/1.6.x/variants/Arduino-due-x/variant (an .H file)

Thank you.
I was missing this completely.

ard_newbie:
You can try SPI library example sketches that you will find in : File>Example>SPI.

AFAIK, any digital output pin can do the job for a chip select CS with the SPI library because this library do not leverage the automatic handling of the CS pin by the SPI0 peripheral.

I am using WiFiSPI library () - btw, neat piece of software - but for some reason their defaults are different from mine: it seems they have pin 52 as SS default, as I found in the first post of this thread.

ard_newbie:
If you program SPI registers (as I do) without the library, you can use one of the following 3 SPI CS pins: PA28 (CS0 = pin 10), PA29 (CS1 = pin 4), PB21 (CS2 = pin 52) and SPI0 peripheral will handle automatically the CS pin state. You can find these pins page 679, SPI section of Sam3x datasheet.

Again, WiFiSPI library does use the registers, so it is a good idea sticking to pins 10, 4 and 52.
Still it is a surprise that in <variant.h> there is a CS3 pin (78 - which i think is physical pin) and that board default is set to it.

Thanks for the precious info.

I edited my post, PA31 and PB23 are not broken out so you don't have 4 "automatic" CS pins, only 3 CS pins.

IMO CS3 = 78 is an error.

ard_newbie:
IMO CS3 = 78 is an error.

I share your opinion...

Still, it drove me mad for some time.....

As previously stated, pin 78 isn't connected, but it is the hardware SS3 (CS3). You can't easily use it on a standard Due, but if you have a custom board you might have access to the pin, so it's no bad thing they have defined it, and it does appear on the circuit diagram. It definitely isn't an error.

weird_dave:
As previously stated, pin 78 isn't connected, but it is the hardware SS3 (CS3). You can't easily use it on a standard Due, but if you have a custom board you might have access to the pin, so it's no bad thing they have defined it, and it does appear on the circuit diagram. It definitely isn't an error.

Seen in this light, it IS a good thing to define SS3. 8)

However, the assignment of SS3 to pin 78 does not appear to be correct. :-\

Page 679 (and on) of SAM3X data sheet defines CS3 to PB23 (physical pin 142) or PA31 (which is not present in 144-pin SAM3X8E).
Looking at variant.h, it would suggest that 78 is the physical pin, but it would correspond to PA16, which is not involved in SPI.
If, on the contrary, it is meant to be 'arduino pin', then it is not clear to which physical pin it corresponds.
Indeed it's not important, since the pin is not 'exposed' to actual use on the DUE board.

What I definitely do not understand is why define the "default SS" to SS3. :fearful:
We can argue if it is best defining default to SS0 (arduino pin 10), SS1 (arduino pin 4) or SS2 (arduino pin 52), but why SS3 if it cannot even be used? (in standard DUE). ???

78 isn't the physical pin, it is the arduino virtual pin assignment. To work out which pin it should be, you have to chase it through the code. Variant.cpp suggests PB23, which does correspond to physical pin 142 which also matches the circuit diagram.

Making this the default is reasonable, if you have multiple shields/devices attached and write some SPI code and forget to set the CS pin, you won't accidentally communicate with the wrong device, potentially resulting in some undesired result (deleting files on a SD card by accident for example, or sending the wrong control voltage to a PSU instead of a http request!). This makes you get your CS pin config correct.

Yep... mistakes tend to wait for you "behind the corner"... :smiling_imp: