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:
Can SPI read 13 bits?
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 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?
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.
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.
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.