Boron I2C slow / have to wait 10 whole milliseconds between 32-byte I2C packets

Firmware
1

I am wondering if the following experience is normal within Boron Device OS 3.1.0 or attributable to some error I am making. The Boron seems concerningly slow and latent at receiving data over I2C, which is necessary for my application because it only has one available UART which I am already using.

To send 4096 bytes, I run the following on a Teensy 3.5 connected to Boron I2C:

for(int j=0; j<2048*sizeof(uint16_t); j+= 32) {
  Wire2.beginTransmission(0x59);        
  Wire2.write((uint8_t*)(startAddress+j), 32); 
  Wire2.endTransmission();
  delay(10); //Painfully necessary wait or else Boron misses bytes
}

On Boron setup(), I start I2C as such:

Wire.setSpeed(CLOCK_SPEED_100KHZ);
Wire.begin(0x59);
Wire.onReceive(receiveEvent);

I buffer incoming data as such:

uint8_t BUFFER[4096];
volatile int received = 0;
void receiveEvent(int dCount) {
  while(Wire.available()>0) {
    BUFFER[received] = Wire.read(); 
    received++;
  }
}

In other words I follow Particle onReceive() - Wire (I2C) to the letter.

I should NOT have to put in a 10-whole-extremely-long-milliseconds delay after each 32 byte transmission on the master.

If I put 8ms, I will wind up getting maybe ~4060 of 4096 bytes.
If I go under 5ms, I will get upper 3000s.

Why is Boron missing bytes?

We aren’t talking microseconds. We are talking huge periods of milliseconds equating to thousands of clock cycles.

Is the Particle Device OS so heavy and introducing so much latency that it is truly impossible to stream data into the Boron over I2C at a rate greater than 3,200 bytes per second? That is a tenth of what the UART can do. I don’t understand what limitation I am facing.

In theory, 100khz clock speed should, if I am correctly understanding that 9 bits are sent to encode one byte, allow for 100000/9 = 11.111Kilobytes/second transmission rate, which is 347% of the fastest speed it seems I can safely use here without missing data.

Any help is appreciated. Thanks.

ADDENDUM: Yes, I need 100khz instead of 400khz, and I confirm that the same issue exists at 400khz. Actually, I believe the timings I mentioned above are no different at 100khz than 400khz, further illuminating something else is at play.

2

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