An old posting from 2014 tells me that for an Arduino Due only one SPI port is supported.
Is this still valid or is there a second or even third SPI port available?
The core only supports one SPI; see C:\Users\yourUsername\AppData\Local\Arduino15\packages\arduino\hardware\sam\1.6.12\libraries\SPI\src\SPI.h.
If the microcontroller hardware supports multiple SPI buses you will have to find or write the code for it.
Hi @SupArdu
The Arduino Due's SAM3X8E microcontroller only has one SPI port, however its possible to configure its additional Universal Synchronous Asynchronous Receiver Transmitter (USARTx) modules in SPI mode.
Here's another old Arduino forum post from 2014:
It's worth asking: why do you believe you need more than one SPI port? Did you know it's possible, and quite usual, to connect multiple SPI devices to the same SPI port?
If I want to keep 2 SPI devices active in the same time I do.
AFAIK when SD is deselected and reselected it's not overhead-free.
If I was copying files from one card to another, a bus each might transfer by double-buffering burst reads and burst writes.
AVR UARTs can be used as master mode SPI ports, DUE might too.
Needless to say, external power?
No you don't. You can have any number of SPI devices on the same bus all active at the same time.
I wrote a small library a long time ago to add a secondary SPI port to the Due using the UART, here is the link:
Won't the data lines get crowded?
Strictly speaking, only two devices are active on the bus at any instant. The master and one slave, if I can use those terms without upsetting anyone. But which of the slaves is active can swap around so fast, under program control, that it would seem like many are active at once.
@GoForSmoke are you saying that if the slave select line to an SD card goes high, the SD card goes into some sleep state that takes some long-ish time to wake from?
I would imagine that with 2 or more SPI ports, the CPU would quickly become the bottleneck, unless DMA channels are used.
I recall that some SD cards don't play nicely on the SPI. They don't tri-state MISO even when their SS is deactivated.
It would be one way to use a SD module that fails to put its MISO output into a high-impedance (tri-state) mode when its CS pin goes high with other SPI modules on the same bus.
@gfvalvo beat me.
It's not the SD card itself. It's the signal voltage level shifter circuit on some/many poorly designed 3.3V/5V modules that doesn't do the tri-stating and so causes problems. A 3.3V-only adapter (which is purely passive) would not have the problem. A better designed 3.3V/5V level shifter module need not have the problem either.
A device can be active even if you are not communicating with it and for identical devices, you can indeed communicate with more than one at the same time
Not true, you can have many slaves if they are identical devices.
Not a good idea if they're all driving MISO at the same time.
Obviously.
From what I read over ten years ago, when you deselect one SD and then reselect it, whatever internal pointers it has to whatever sector it Was Working On have to be set back up and not pick up from where it was last time.
When reading SPI data there are X cycles between data bytes arriving that can be more or less depending on chose SCLK divider so there I do see time to read one and write the other especially given that SPI does have a clock line unlike Serial but that does mean no burst mode, maybe interleaving bursts would be faster, I dunno sinceburst mode is still processor-fed.
I was looking at possibilities as real or not then. Still.. mebbe.
So as long as whole sectors are read/written without deselecting the SD card, the performance should be pretty good. That might not be possible on an Uno because of memory constraints, but should not be a problem on Due. Good to know, thanks!
If I ran two SPI buses with shorter than 512B default buffers, I might get an Uno to pipeline between devices at some speed. The SPI clock is more like a latch from what I have understood. Data does not have to on-time rush through except for burst mode at least in practice.
So, back to my original point, @SupArdu may not need more than one SPI port. So long as data is transferred to/from an SD card in whole sectors, the performance penalty for using only one SPI port may not be significant.