SPI defaults to 16bits?

Projects Networking, Protocols, and Devices
1

Was having trouble with multiple SPI devices. So I wrote a simple SPI test routine below. It seems that the SPI.h functions hold the enable line for 16 bit periods even if only sending 8 bits? This has been proven with a scope.

Any way to set the SPI function to jump back after only 8 SPI clock cycles?

Note: It's not the delay function in my example, does the same thing without delay();

/* SPI_test.c   04-11-2025 */

// Include Files
#include <Arduino.h>
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <SPI.h>

// SPI enables
#define SPI_UNIT1     SS
#define SPI_UNIT2     A0

void send_spi(unsigned char prt, unsigned char dat)
{
    digitalWrite(prt, HIGH); // enable
    SPI.transfer(dat);
    digitalWrite(prt, LOW); // disable
}

void setup() {
    Serial.begin(115200,SERIAL_8N1);

    pinMode(SPI_UNIT1,OUTPUT);
   
    SPI.setBitOrder(MSBFIRST);
    SPI.begin ();
    SPI.setClockDivider(SPI_CLOCK_DIV8);  //divide the clock by 8   


}

void loop() {

  int n;
  
    while(1)  {
      for (n= 1; n<= 255; n++)  {
          send_spi(SPI_UNIT1,n); 
          delay(100);
      }
    }
}
2

You are sending an int value. On the Arduino an int type is two bytes or 16 bits long. If you only want to send 8 bits at a time, try using an 8-bit variable such as a char, byte or uint8_t instead.

3

No, look at the send_spi() function. Both the port and the data are re-defined to unsigned char so any incoming 16bit value is truncated to8 bits.

However I did change the int n in the main loop to an unsigned char and the problem still exists.

4

Care to share that with the forum?

What if you send 16 bits? How long does the enable line remain held then? 24 cycles? 32?

5

What MCU are we talking about?
I think it has nothing to do with 16bit or 8Bit transfers.
SPI.transfer always only transfers 8 bits and only creates 8 clock pulses.
And the delay to the SS-edge is independent of the clockspeed. Setting/clearing the SS pin with digitalWrite needs some µs time ( at least on AVR ). That's what you see.

6

When using the default SS-Pin on Nano/UNO ( Pin 10, PB2 ) you can try:

void send_spi(unsigned char prt, unsigned char dat)
{
    digitalWrite(prt, HIGH); // enable
    SPI.transfer(dat);
    //digitalWrite(prt, LOW); // disable
    PORTB &= ~0x04;
}
7

Normally for SPI the SS (slave select) is brought low to activate/enable the device for the transfer and returned to high after the transfer is complete. This may not matter if your test bed is only to show the elapsed time of an SPI.transfer statement on a scope, but could exlain the original problem that this was intended to analyse.

There is, incidentally, a 16bit variant of SPI.transfer: SPI.transfer() - Arduino Reference

8

TEK0000
TEK0000640×480 82.1 KB

Now keep in mind the enable line (green) cannot go low until the SPI.transfer() function is done. It's the SPI.transfer function that is causing the delay. Any you can see the extra time is exactly 8 more bit periods.

9

The trace clearly shows SPI is only transferring 8 bits - not 16 bits. The delay in the trace 4 changing is more likely to be due to the digitalWrite function IMHO.

Just an observation, but as I'm sure you already know, the SPI device CS signal is normally low during the transfer.

10

The polarity of the enable is dependent on the receiving device, in this case my FPGA design, I can throw an inverter into the FPGA if the absolute polarity is important to the Arduino.

Interesting though that the delay is exactly 8 but cells long. And note there is no delay with the enable going high. So I would expect the same thing going low.

I remember another discussion here about delays in these "digitalWrite" and "digitalRead" functions. Why? This is a very simply thing in .asm.

It looks like the default SPI.write() is a 16bit function and if you send only 8bits, it just leaves the other 8 bit periods blank but still holds the function to 16 bit tines long?

I'll try basic bit-banging on that port and pin.

P.S. The actual application works fine. I just don't like that delay eating into my loop daylight time.

11

That is a coincidence. You will see that if you change the SPI speed - the delay stays the same. Did you read and try what I supposed in #5 and #6?

There is, but you don't see it at your scope, because the delay created by digitalWrite() is before actually changing the output.

That's what I suggested in #6, direct port manipulation. Then you will see no delay. But digitalWrite does a lot checking and has to calculate the port and bit number from the pin number.

Believe it or believe it not - the delay you see is simply the delay created by digitalWrite.

12

Change your code like this and see what your scope shows as the timing of the extra pulse in the enable line:

void send_spi(unsigned char prt, unsigned char dat)
{
    digitalWrite(prt, HIGH); // enable
    SPI.transfer(dat);
    digitalWrite(prt, LOW); // disable
    digitalWrite(prt, HIGH); // enable
    digitalWrite(prt, LOW); // disable
}
1 Like
14

OK I get it now.

digitalWrite is doing this translation every time it's called. So it seem this function is a convenience where time is not critical or a tool for beginners. If you want speed or efficiency, use the old method of direct port manipulation.

As we know you have to preserve the state of the port byte if other functions are using other bits so it's a bit tricky for new comers.

15

Heres how I typically do this outside of the Arduino environment.

// Arduino

#define VBI_DATA_RDY   PD2

if (digitalRead(VBI_DATA_RDY))  {
// .......
}

// My way using the ICCavr compiler

#define VBI_DATA_RDY  (PORTD & 2)

if  VBI_DATA_READY   {
//  .........
}

Much more direct approach IMO.

16

Yes of course. But it is completely board specific.
The Arduino IDE supports a lot of boards, and the idea is to support all the boards with the standard functionality. If you use only standard functions, one sketch can be compiled for nearly all the supported boards wothout any change.

That's it.

But you are always free to dive deeper - The Arduino IDE does not prevent you from doing this. But maybe something special to your MCU - e.g. Atmel Studio - is a better choice then.

17

Try this to see/measure the overhead on your scope:

void send_spi(unsigned char prt, unsigned char dat)
{
    digitalWrite(prt, HIGH); // enable
    SPI.transfer(dat);
    digitalWrite(prt, LOW); // disable
    digitalWrite(prt, HIGH); // enable
    digitalWrite(prt, LOW); // disable
}

(Oops, I see that I didn't read the excellent advice in @PaulRB's #12)

18

This appears to be remarkably similar to the suggestion here: SPI defaults to 16bits? - #12 by PaulRB : Of course, the idea is good.

1 Like
19

There are some ways to get better performance without loosing portability between Arduino boards.

Also there are macros which will translate an Arduino pin number into the port and bitmask:

const int myPin = 12;
volatile int myPinPort =  portOutputRegister(digitalPinToPort(myPin));
const int myPinMask = digitalPinToBitMask(myPin);

*myPinPort |= myPinMask; //equivalent to digitalWrite(myPin, HIGH);

*myPinPort &= ~myPinMask; //equivalent to digitalWrite(myPin, LOW);

(Hope I got the above right)

20

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.