Request I2C maximum bytes increase to 35

[DonStauffer]

@dc42 I'm going to go out on a limb:

From how I interpret the code, it seems like after sending the last byte, it may be necessary to wait for a status of TWI_SR_TXRDY before setting the TWI_CR member to TWI_CR_STOP. Possibly if that gets done no increase would be necessary.

If that doesn't make any sense, disregard. I may be misunderstanding.

[dc42]

@DonStauffer there is nothing different about how RRF ends a 34-byte transaction compared to a 33-byte transaction. So I can't see how the problem you are having with 34-byte transactions can be the fault of RRF.

Does Adafruit publish the firmware that runs on the NeoDriver?

[DonStauffer]

@dc42 I'll check.

[DonStauffer]

@dc42 https://learn.adafruit.com/adafruit-seesaw-atsamd09-breakout/using-the-seesaw-platform

[dc42]

@DonStauffer if you are writing data to the BUF register (register 0x04) then according to https://learn.adafruit.com/adafruit-seesaw-atsamd09-breakout/neopixel the maximum length you can write is is 32 bytes, of which the first 2 bytes are the start address.

[DonStauffer]

@dc42 AdaFruit's seesaw NeoDriver page says "Data should be written in blocks of maximum size 30 bytes at a time." So the 30 byte limit refers to the actual color data - 3 bytes per LED x 10 LEDs.

The overhead is: a byte for module base register address (0x0E); a byte for the function register (0x04), and 2 bytes for the offset into the NeoDriver buffer. The module base register address is necessary for the seesaw chip to know what feature of the seesaw chip to use (there are many more besides NeoPixels), and the function register is needed so the chip knows you are sending data to write to the buffer.

That makes a total of 34 bytes in the I2C transaction (not including the I2C address (0x60)) to send a 30-byte block. 32 bytes are passed to the seesaw's NeoPixel BUF function (essentially a "write" function), and provide the information it needs to write the data to the buffer. There is no way to send 30 data bytes to the NeoDriver BUF function with a smaller I2C transaction than 34 bytes. This is borne out by the fact that I can successfully send 27 data bytes only by using an I2C transaction of 31 bytes, using the overhead I described.

(There is an error in AdaFruit's published information: They say 30 data bytes, but the specified offsets for the data is "2-32", which would be 31 bytes. My interpretation is they meant to say "2-31" for the data, which would be 30 bytes. I did ask them if the 31st byte was a trailer, like a null or something, but I didn't get a response)

[dc42]

@DonStauffer theI2C device address (which you have called the base address) doesn't count in the 34-byte limit in RRF because it is passed separately to the I2C driver. So RRF currently allows you to send the register address followed by up to 33 data bytes. IOW the B parameter of the M260 command accepts up to 34 values.

[DonStauffer]

@dc42 The "module base register address" for the NeoPixel module (0x0E) is different from the I2C address (0x60). It is the first byte of what I2C would consider the data.

The second byte is the "Function Register", which in the case of a write operation is 0x04. The 3rd and 4th data bytes of the I2C transaction payload provide the offset into the NeoDriver buffer, meaning if you give it 0x0003 the data will set colors starting with the 4th LED in the strip.

After those initial 4 bytes, the data is in 3-byte groups, which are the 3 colors for each LED. So there are 4 bytes up front (not including the I2C address, naturally) before the colors begin.

As a result, sending 30 bytes of colors, the maximum AdaFruit recommends, requires a 34 byte I2C transaction payload.

[dc42]

@DonStauffer so is it still the case that you only need to use a 34-byte payload in the B parameter?

[DonStauffer]

@dc42 The Adafruit documentation is ambiguous because it's internally contradictory by one byte. So I don't know.