Interrupt and SPI transfer

Will I be able to use and interrupt with SPI.transfer or will I need to find a new approach? I am fine with the data being interrupted mid-byte!
Here is the bare bones code:

#include <SPI.h>

const int data[] = {0,1,1,2,3,5,8,13,21,34,55,89,144,233}; //data to be transfered
volatile int timer = 1000; //time between bytes of transfered data.
volatile int i = 0; //While loop counter

void setup() {
  pinMode(2,INPUT); //the interrupt pin that is connected to a photosensor 
  attachInterrupt(0, ISR, FALLING);
}

void loop() {
  SPI.begin();
  SPI.setBitOrder(MSBFIRST);
  SPI.setClockDivider(SPI_CLOCK_DIV128);
  while(i < sizeof(data)){
    SPI.transfer(data[i]);
    delayMicroseconds(timer);
    i++;
  }
  SPI.end();
  timer=timer+5;
  i=0;
}

void ISR() {
  timer=timer-5;
  i=0;
}

I am trying to write a code that transfers data over a period of time that is set by a photo-sensor being blocked. The photo-sensor will generally be blocked at close to evenly spaced intervals, however, the interval can increase and decrease as well. I would like the code to send the bytes in "data" over SPI.transfer evenly spaced out over the time interval ( the time interval being the time from blocked photosensor to blocked photosensor) and if the data isn't spaced evenly then I would like the data to become closer to evenly spaced on the next iteration.

As your interrupt does not drive a different spi device it won't be blocked and the approach should work

You should check that your timer does not become negative if you keep that approach but linear adjustments are pretty slow to converge

If you think the dark periods are usually stable, then why don't you measure the duration of the dark period and instead of adding 5 for the next run (if you got to send all the bytes), then calculate the timer to actually fit that duration. You will converge must faster. ( If you take that approach, you might want to take into account the time it takes to actually send the bytes when you calculate the timer)

It's a bit unusual to call SPI.begin and SPI.end repeatedly. Why do that?

I did that so I could test the code by adding a serial print line in to debug and make sure it was running like I wanted and I found that the code was not going to the interrupt as frequently as I thought it should. I will move the SPI setup back up to the setup(). Thanks for the advice