What limits the speed of SPItoMyself.ino?

[frohro]

Hi All,
I need to use SPI to read data in and then do some DSP and then write it back out (to a different SPI). I would like the most time I can have to do the DSP, and my data is coming in and going back out at about 100 kHz at 16 bits via SPI. I read that the Pico can do 62.5 MBit/s or close to it, but the fastest I can get SPItoMyself.ino to run is 7 MBit/s by adjusting the spisettings. I tried to make the wires short. I took another board I had with a Raspberry Pi Pico W and since it was closer and the pins were not used by the PCB it was soldered to tested it. Here is a photo of my hardware setup. The waveforms look fine on the scope, so I suspect it is due to the things the software is doing. I'd like to understand why I can't go faster.

Here is my code:

// Shows how to use SPISlave on a single device.
// Core0 runs as an SPI master and initiates a transmission to the slave
// Core1 runs the SPI Slave mode and provides a unique reply to messages from the master
//
// Released to the public domain 2023 by Earle F. Philhower, III <[email protected]>

#include <SPI.h>
#include <SPISlave.h>
#include <Arduino.h>

// Wiring for Earl's setup:
// Master RX  GP0 <-> GP11  Slave TX
// Master CS  GP1 <-> GP9   Slave CS
// Master CK  GP2 <-> GP10  Slave CK
// Master TX  GP3 <-> GP8   Slave RX

// Wiring for Rob's setup:
// Master RX  GP16 <-> GP12  Slave TX
// Master CS  GP17 <-> GP13  Slave CS
// Master CK  GP18 <-> GP14  Slave CK
// Master TX  GP19 <-> GP45  Slave RX

SPISettings spisettings(8000000, MSBFIRST, SPI_MODE0);

// Core 0 will be SPI master
void setup() {
  SPI.setRX(16);
  SPI.setCS(17);
  SPI.setSCK(18);
  SPI.setTX(19);
  SPI.begin(true);

  delay(5000);
}

int transmits = 0;
void loop() {
  char msg[42];
  memset(msg, 0, sizeof(msg));
  sprintf(msg, "What's up? This is transmission %d", transmits);
  Serial.printf("\n\nM-SEND: '%s'\n", msg);
  SPI.beginTransaction(spisettings);
  SPI.transfer(msg, sizeof(msg));
  SPI.endTransaction();
  Serial.printf("M-RECV: '%s'\n", msg);
  transmits++;
  delay(5000);
}

// Core 1 will be SPI slave

volatile bool recvBuffReady = false;
char recvBuff[42] = "";
int recvIdx = 0;
void recvCallback(uint8_t *data, size_t len) {
  memcpy(recvBuff + recvIdx, data, len);
  recvIdx += len;
  if (recvIdx == sizeof(recvBuff)) {
    recvBuffReady = true;
    recvIdx = 0;
  }
}

int sendcbs = 0;
// Note that the buffer needs to be long lived, the SPISlave doesn't copy it.  So no local stack variables, only globals or heap(malloc/new) allocations.
char sendBuff[42];
void sentCallback() {
  memset(sendBuff, 0, sizeof(sendBuff)); // Clear the buffer
  sprintf(sendBuff, "Slave to Master Xmission %d", sendcbs++);
  SPISlave1.setData((uint8_t*)sendBuff, sizeof(sendBuff));
}

// Note that we use SPISlave1 here **not** because we're running on
// Core 1, but because SPI0 is being used already.  You can use
// SPISlave or SPISlave1 on any core.
void setup1() {
  SPISlave1.setRX(12);
  SPISlave1.setCS(13);
  SPISlave1.setSCK(14);
  SPISlave1.setTX(15);
  // Ensure we start with something to send...
  sentCallback();
  // Hook our callbacks into the slave
  SPISlave1.onDataRecv(recvCallback);
  SPISlave1.onDataSent(sentCallback);
  SPISlave1.begin(spisettings);
  delay(3000);
  Serial.println("S-INFO: SPISlave started");
}

void loop1() {
  if (recvBuffReady) {
    Serial.printf("S-RECV: '%s'\n", recvBuff);
    recvBuffReady = false;
  }
}

Thanks!
Rob

[earlephilhower]

I'm not sure I understand what you're doing and how the SPISlave demo has any relevance. If I understand what your real app will be doing, it will do a SPI master transaction of 16b to read in a sample, do some math, then do a SPI master transaction of 16b to write it elsewhere. So, no slave mode at all. If that's the case then simply setting up SPI and using the proper CSs before each 16b transaction is all you need, no slave mode (w/its IRQs, etc.)

IF you do a large, (order of 16K, not 16b) SPI transfer using DMA (see the async methods in the SPI object) I would bet you can do full speed. But there is some setup/teardown on every individual transaction which introduces overhead.

The example here even does tons of other things between SPI transactions, including string manipulations and even USB writes (which can block on USB polling) between transactions (I assume when testing speeds you commented out the delay(5000)s, of course). It's not meant as a speed test in any manner.

[frohro]

Thank you @earlephilhower ! Your note is encouraging and helpful. I think it will all work okay now.
Rob