Wire library BUFFER_LENGTH. I need a way to change it.

[DeweyOxberger]

The I2C buffer length in all versions of the wire library is hard-coded to 32 bytes. I must be the only guy in the world who needs it larger (up to 1.1k at times, but typically more like 53, 350, or 530 bytes).

If I cook up a way to make it settable what are the odds I can get that code included in the Teensy's wire library? I really want to ship code to people and have it compile with no hassle. (We ship Teensy3.2 based demo systems - see Cirque.com. People have to edit the buffer length in the library to get the code to work).

I'm leaning toward factoring the code to use a pointer to the buffer and a buffer length variable (it will create a 32 byte version by default). I could then write an overload to Wire.begin() or add a new Wire.assignBuffer() that lets me redirect the buffer and length. It's more of a ram footprint. This only needs to work with Teensy3.2, 3.5, 3.6, and 4.0.

The real goal is I need an easy way to redefine the buffer length for a project with zero hassle for a customer but something that makes it obvious that we are setting the buffer length (so people can clearly see what length they'll need).

How should I proceed?

 

[MorganS]

You're doing something wrong. The standard buffer works for everyone else. Just send your data in 32-byte chunks. When receiving, your onReceive() handler will be given the first 32 bytes when they are available. When more arrive, the handler gets called again.

 

[PaulStoffregen]

I must be the only guy in the world who needs it larger (up to 1.1k at times, but typically more like 53, 350, or 530 bytes).

This request does come up occasionally. You're not the only one, but it is rare.

The Wire library code which exists today has a fixed buffer. So editing the library code is the only solution, for the Wire lib.

The i2c_t3 library which might meet your needs. It's meant as a drop-in replacement for Wire, but offers more features. Its default buffer is 258 bytes. If you absolutely can't edit any library code, that will at least get you 258 bytes, but not the 1100 you wanted "at times".

 

[DeweyOxberger]

So we'll cook up a version (I prefer i2c_t3 so we'll likely use that) and then focus on the core issue: getting those changes rolled into the release version.

MorganS - I hear you. It sounds like we are doing something crazy but many I2C devices require a complete report read or they won't advance their state correctly. A few of those devices require large reads (many I2C HID devices for example).