Just curious: what is the use-case? Such long transactions are very uncommon. In any case, we should get this fixed.
On Wed, Dec 17, 2014 at 5:04 AM, Mark Melvin <[email protected]> wrote: > > I do have a logic analyzer and the lines are both pulled up. I initially > thought it was my hardware, but I have another I2C master device I can send > bytes from and the transactions look identical. > > Back to the IOIO - I narrowed it down to the case where if I send more > than 78 (actually, it may be 79 - I need to double-check) bytes to the > writeRead() method, it just fails. If I send a large number (like 1024), > it seems to just block, and I am implementing the call to writeRead in a > runnable I can poll and cancel - so after a few seconds, I can timeout the > transaction. If I send a number somewhere between 80 and say 128, the IOIO > will actually forcibly disconnect pretty much immediately. > > I can try to debug this further and get back to the group. > > Mark. > > On Tue, Dec 16, 2014 at 11:48 PM, Ytai Ben-Tsvi <[email protected]> wrote: >> >> The protocol limits the write size to 256 and read size to 255. The >> hardware buffers are 256 for writing (4 byte overhead for each transaction) >> and 128 for reading (1 byte overhead for each transaction). I don't see a >> reason why 78 would be a cutoff point. What do you mean by "get a timeout"? >> Do you have a logic analyzer by any chance, to figure out what's >> happening on the wire? >> >> On Tue, Dec 16, 2014 at 1:36 PM, Mark Melvin <[email protected]> >> wrote: >> >>> Hi Guys, >>> >>> I've been experimenting with I2C, and found that if I try to send the >>> TWI master anything more than about 78 bytes of data, it doesn't work. >>> I'll either get a timeout, or the IOIO will forcibly disconnect. Lowering >>> my maximum transaction size to <=78 seems to make it behave reliably. >>> >>> Is there some internal buffer that is overflowing here? I can't find >>> anything obvious in the code. I see there are RX and TX buffers in the PIC >>> code, but they are 128 and 256 bytes, bigger than the limitation I am >>> seeing. And I would think this would be invisible to the user anyway, so >>> perhaps there is something at the protocol level in Java? >>> >>> Thanks, >>> Mark. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "ioio-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/ioio-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "ioio-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/ioio-users. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "ioio-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/ioio-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ioio-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/d/optout.
