Read errors with large size data

[mzwtjp]

Hello.
I am seeing read errors (121 EREMOTEIO) with i2c-tiny-usb + digispark.
Host is Linux, and I am doing something like read(fd, buf, 210) on
/dev/i2c-7 (where my i2c-tiny-usb appears).

I am reading from an I2C device, which can respond relatevely large
size data, say, upto 1,000 bytes.
But I am beginning to see 121 errors around 204 bytes.
(Smaller number of bytes are OK. read() call fails with larger than this.)

1. If I read one byte at a time like below, I do not get this 121 error.
   (But it is very very slow.)

i2c_smbus_read_byte_data(addr, reg)
i2c_smbus_read_byte(addr) x 210 times.

2. I debugged for a while, and I can see if I modify a line in
   main.c:usbFunctionRead() like this, I no longer see this error, even
   if I do read(fd, buf, 210).

*data = i2c_get_u08(expected == 0)
->
//*data = i2c_get_u08(expected == 0)
*data = 0;

i.e. if I do not call i2c_get_u08() in usbFunctinoRead(), I do not get
this 121 error.

I think if I take long time in usbFunctionRead(), it may cause
something wrong and the read request fails.
(Timeout somewhere related to USB polling loop?)

For 204 bytes, usbFunctionRead() is getting called 26 times
(i2c_get_u08 is called 204 times)

I wonder if there is a way to avoid this within i2c-tiny-usb layer.

[harbaum]

You are correct. The USB handling is done in software by the usbPoll routine which in turn triggers the i2c transfers. USB is not handled as long as the i2c transfers run and if they take too long either due to the number of bytes transferrred or due to clock stretching then the USB may time out.

Fixing this probably requires a major rewrite of several parts and e.g. the entire I2C handling should be moved into a seperate state machine running besides the usb handling and not instead of it.

[mzwtjp]

Thank you for your comment.

For now I think I am going to modify my app so that it reads safe amount of chunk bytes at a time, say 100 bytes.
By doing this, I confdirmed that the read speed is OK (compared to the one-byte-at-a-time approach).