I2C: i2cRxData size limitation inquiry

[rwaldron]

I'm implementing an I2C "backpack" for use with CD74HC4067, which is a 16 channel analog mux/demux chip. I knew I would be pushing the limit for i2cRxData, because any program that wants to use all 16 pins will need to request 32 bytes (16 x [lsb, msb]). This currently won't work because the first two bytes of i2cRxData are used for the address and register. Of course, changing it to 34 makes it work, but this made me wonder if there was more to know about i2c data length limitations?

[soundanalogous]

I'm pretty sure that is left over from when the Serial buffer was only 32 bytes. I don't see any reason why it can't be increased to 64 bytes.

[ajfisher]

I use 64 bytes on node-pixel firmata as well to deal with this issue.

I reckon we should be bumping this up more generally though

On Tue, Mar 8, 2016 at 9:39 AM Jeff Hoefs notifications@github.com wrote:

I'm pretty sure that is left over from when the Serial buffer was only 32
bytes. I don't see any reason why it can't be increased to 64 bytes.

—
Reply to this email directly or view it on GitHub
#276 (comment).

[fivdi]

Although it has nothing to do with Firmata, the i2c-bus readI2cBlock and writeI2cBlock methods are limited to 32 data bytes as the Linux SMBus functions they call internally are limited to 32 data bytes (i2c_smbus_read_block_data and i2c_smbus_write_block_data.) See https://www.kernel.org/doc/Documentation/i2c/smbus-protocol.

[soundanalogous]

Firmata 64 bytes ~ 32 actual bytes because each byte is split prior to transmission. Therefore with the current 32 byte limitation, you can only really TX about 16 bytes of data.

[soundanalogous]

@ajfisher If you have had no issues with the 64 byte buffer I think you or @rwaldron should submit a PR to make this change

[ajfisher]

Yes - was writing that on the hop but that was exactly the issue I was
seeing @soundanalogous because of the 7-bit byte thing, throughput on
nodepixel was really challenging because a 3 byte value becomes 6 due to
splitting, then you have the header stuff so you're pretty much max getting
2 pixel values through per transmission.

Can't tell you how much I'd love to move to 8-bit bytes (I know...)

I can put together a PR for you if you want.

On Tue, Mar 8, 2016 at 9:57 AM Jeff Hoefs notifications@github.com wrote:

@ajfisher https://github.com/ajfisher If you have had no issues I think
you or @rwaldron https://github.com/rwaldron should submit a PR to make
this change

—
Reply to this email directly or view it on GitHub
#276 (comment).

[ajfisher]

We're not supporting ATMEGA168 any more with standard firmata right?

On Tue, Mar 8, 2016 at 10:09 AM Andrew Fisher ajfisher.td@gmail.com wrote:

Yes - was writing that on the hop but that was exactly the issue I was
seeing @soundanalogous because of the 7-bit byte thing, throughput on
nodepixel was really challenging because a 3 byte value becomes 6 due to
splitting, then you have the header stuff so you're pretty much max getting
2 pixel values through per transmission.

Can't tell you how much I'd love to move to 8-bit bytes (I know...)

I can put together a PR for you if you want.

On Tue, Mar 8, 2016 at 9:57 AM Jeff Hoefs notifications@github.com
wrote:

@ajfisher https://github.com/ajfisher If you have had no issues I
think you or @rwaldron https://github.com/rwaldron should submit a PR
to make this change

—
Reply to this email directly or view it on GitHub
#276 (comment).

[soundanalogous]

I've been refactoring so that Serial feature (done) and I2C (to do) can be included or excluded in StandardFirmata (and variants) through a single define at the top of the file. Excluding those features should provide enough room to run StandardFirmata on an ATMega168 - but I suppose you want I2C - in that case it should work with ConfigurableFirmata.

[soundanalogous]

Can't tell you how much I'd love to move to 8-bit bytes (I know...)

That would be a different protocol :)

[rwaldron]

Awesome, thanks everyone!