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 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
