Funny you should mention the SRAM. When I first saw your thread I thought "aha! - it works with 64 bytes but not more, that rings a bell.".
So I looked at length through the Atmel documentation for the magic number "64" because I was sure I had seen it as an I2C limit. But no. Then I looked at the Microchip documentation for their SRAM/EEPROM and indeed for those chips there is a limit of 64 in the I2C buffer.
So then I did a test bed to prove that it does work (I wasn't sure in advance what it would prove), but for my test program it did. So there is no hardware limit.
But of course your point of the multiple buffers is valid. For a chip that has maybe 1Kb SRAM (and you didn't mention your model of chip) then having multiple 194 byte buffers may be a problem for you. It certainly seems to have two buffers in Wire.cpp and another three buffers in twi.c. So it looks like 5 buffers is right. So 5 * 194 is 970 bytes, which on an Atmega138 is going to be almost all available RAM.
That's probably why they stuck to 32-byte buffers rather than 64-bye ones.
You know, even a small programming change reduces the need for big buffers? Change:
Wire.beginTransmission (ADDRESS);
for (int x = 0; x < 194; x++)
Wire.send (x);
Wire.endTransmission ();
to:
for (int x = 0; x < 194; x++)
{
Wire.beginTransmission (ADDRESS);
Wire.send (x);
Wire.endTransmission ();
}
It runs slightly slower because it sends the address in front of every byte, but perhaps in your case that doesn't matter too much.
In fact, as I had the test still set up, I changed the code to what I have above and re-timed it. It went from 18.6 ms to 45.0 ms. Over twice as long, as I would expect, since it sends the device address every time, but still, 45 ms isn't too bad.
If you leave it as how you describe (3 batches rather than 1) then the extra overhead would be neglible.