Expanding Data Length

Expanding Data Length

[Randy Grunwell]

Hi-

First, let me thank you for the I2C-tools! I have made a test controller board for my RPi that uses them, and it has been working flawlessly!

... until I tried to add a display. There seems to be a 32-Byte limit on sending, and for some reason, the New Haven display I am using does not like having so little transferred. I have contacted New Haven (and actually the actual driver IC company as well), but they apparently only communicate through the forums, and haven't seen to reply to me.  
(If you are interested, see http://www.newhavendisplay.com/NHD_forum/index.php? , then Graphics Displays, and the two messages from Tinkerer1359.)

So I'd like to ask you to consider expanding the length that can be transferred if possible. This particular display would like to see a tuple of at least 644 bytes at one time!

Thank you for considering this!

-Randy

Re: Expanding Data Length

[Jean Delvare]

Hi Randy,

On Wed, 6 May 2015 20:31:20 +0000, Randy Grunwell wrote:
> First, let me thank you for the I2C-tools! I have made a test controller board for my RPi that uses them, and it has been working flawlessly!

You're welcome :-)

> ... until I tried to add a display. There seems to be a 32-Byte limit on sending, and for some reason, the New Haven display I am using does not like having so little transferred. I have contacted New Haven (and actually the actual driver IC company as well), but they apparently only communicate through the forums, and haven't seen to reply to me.  
> (If you are interested, see http://www.newhavendisplay.com/NHD_forum/index.php? , then Graphics Displays, and the two messages from Tinkerer1359.)

Couldn't find the page, sorry. Why don't you provide a direct link to
the relevant posts?

> So I'd like to ask you to consider expanding the length that can be transferred if possible. This particular display would like to see a tuple of at least 644 bytes at one time!
> 
> Thank you for considering this!

The 32-byte limit isn't an arbitrary software limit on our side. It
comes from the SMBus specification. SMBus is a subset of I2C commonly
used in computers. i2cdump, i2cset etc. are essentially SMBus tools
rather than I2C tools, despite their name, for maximum compatibility.
If they used the i2c interface instead of the smbus interface then they
would be useless on SMBus-only systems.

That being said, you are not the first user frustrated by this limit.
Thankfully, Wolfram recently submitted a new tool to address this
issue. The timing could hardly be better. See:

http://marc.info/?l=linux-i2c&m=142505384332026&w=2

Wolfram's tool is a true I2C tool so it won't suffer from the 32-byte
limit. I believe it should do what you need. I didn't have the time to
review the code yet, but I invite you to test it and report.

A little note though: 644+ bytes are a long message by I2C standards.
Passing all the values as text on the command line to be parsed into a
buffer then passed to the kernel will be rather inefficient. Depending
on how frequently you need to do that, it might be preferable to write
a dedicated tool in C, or to extent Wolfram's i2ctransfer to be able to
read/write binary data from/to files directly, or to write a kernel
driver for your device.

-- 
Jean Delvare
SUSE L3 Support