After digging into I²C protocol some more I felt armed to hack the MultiSerial library to do multi-byte reads and writes. I added 2 user level functions – writeMulti() and readBuf(). I had to add 2 more internal functions – the ones that talk to the Wire lib. But as I tried to write the internal msWriteRegisterMulti() and msReadRegisterBuf(), while Wire did seem to support multi-byte operations, the bits I needed weren’t exposed as public.
OK – if I have to I’ll make a private Wire.h with more things exposed. But that wasn’t enough: the code used by Wire isn’t in wire.cpp – it’s in the underlying twi.cpp! I really didn’t want to make a private version of that, too!
Google and I could find little or nothing about heavy use of Wire (and twi) for making other libs like the one I needed. But I finally figured out how it actually works – and by working with the system, everything I needed was there. I put crude versions of all the routines in. No sanity checking, no error returns. Use it perfectly and it works. Else – no promises.
Wrapping my application level routines – writeMsg() and rxpoll() in millis() timers, I got some numbers. All are for sending/receiving a 27 byte message.
byte-at-a-time send: 330 ms multi-byte send: 4 ms
byte-at-a-time read: 800 ms multi-byte read: 7 ms
So how fast will it go end to end? I got up to about 1300 B/sec, but if I went faster the receive routine locked up. I suppose I should start handling some error conditions more gracefully 🙂
That’s plenty fast for the target applications, but not so much for bulk downloading of applications/problem sets/whatever via IR.
I sent a little update note to the original author of the lib and learned she was having performance problems with a VGA shield she was making and using I²C to talk to. So my multi-byte efforts may be the starting point for a performance boost for Strich Labs as well!