Can you use SPI with fewer than 16bits?

I am trying to communicate with a device that uses SSI, very close to SPI. It reads clocked serial data 13 bits long.

2 questions:

  1. Can SPI read 13 bits?
  2. If I have to bitbang, Can I get an external interrupt to respond in less than 10usec? From what I've read external interrupts using attachInterrupt() has significant overhead.

SPI can read 16-bit in two 8-bit bus transactions.

Read 16 bits and ignore the 3 that you don't need.

2 Likes

SPI transfers data in multiples of 8 bits. You should consult the documentation for your SSI device to see if it wants exactly 13 bits or whether it will take 16 bits but only use the lower (or upper) 13 bits.

If you have to bit bang, then were you thinking of using an interrupt to trigger the shifting out of each bit?

Would it be outside the spec of the SSI device if you were to bit bang as fast as you can whilst hogging the processor until the 13 bits have been sent?

Why do you need an interrupt?

There are some Arduino SSI examples out there. Most people just use "bit-banged" I/O, clock and data.

13 bits is it. The Arduino is a "SSI slave" I have no control over the SSI data rate the master uses or when it wants the data. The device sends 13 clk ticks. The first falling clk edge signals a transfer start. The data out pin is already set with the first data bit. I have 4uS to start sending the rest of the bits . Hogging the processor during the transfer is fine.

This might help: SPI 101: A beginner’s guide

You've carefully neglected to post the part number of the SSI master so that anyone could read its data sheet and attempt an answer to your question.

2 Likes

It's a custom board that reads a rotary encoder. I want to intercept the encoder values to add an offset. I hope to do it with a nano. If the nano can't do it, I'll try an STM32 nucleo. It's much faster and can be 5V tolerant if I'm careful.

Does that mean that the nano/STM32 has to be both a master and a slave?

Yes,
It will read the encoder continuously while waiting for a request from the upstream controller. Upstream requests trigger an interrupt. The newest encoder value is offset and passed on. Really simple. The interrupt response time of the nano is a shade too long. It's working on one system. I am uncomfortable saying it will work on any system. I don't know how much variation there is controller to controller.

This is basically solved. I have to bit bang. It works and by using a faster device it'll work well.

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