Chumby Hackerboard i2c Highspeed

[robtwn]

This is perhaps a question for Sean Cross who wrote the i2c twiddler-tool.

I saw a post on another forum (of which I now can't find the reference), saying that the kernel driver for i2c won't handle 400 Kbps stream without kernel modification. I care about this because I'm about to embark on trying to use the Chumby Hackerboard to integrate the output of four (4) AVR-CAN boards, each listening to automobile CAN buses clocked at 500 Kbps, with 2 buses processing a CAN message every millisecond. My questions are two: (a) should I continue down this path of try to use i2c at 400 Kbps, or should I look elsewhere to link all these guys, and (b) is the SD card fast enough to store the aggregate stream? Any advice much appreciated, including kernel changes if they are required.

very best/robert

[Xobs]

When we were frist bringing up the board, I remember briefly trying to run it at 400 kHz, but it became unstable, and as this was just a few days before shipping I decided to run it at the original speed. Since 100 kHz was enough for our purposes, I left it at that.

You can try modifying the kernel at https://github.com/xobs/linux-2.6.28.mx ... i2c.c#L361 to increase the timing. Those numbers were pulled straight out of the reference manual. I seem to recall that code is called only once at boot, so you could probably use regutil to bang in the faster timing values mentioned in that file (e.g. 'regutil -w I2C_TIMING0=0x000F0007 -w I2C_TIMING1=0x001F000F -w I2C_TIMING2=0x0015000D') and seeing if it works.

The SD card ought to be able to keep up with that. Writes will get aggregated by the disk cache and will be flushed out in chunks of several kilobytes. I'm not sure of your exact use case, but provided you're below several megabytes per second, you should be okay.

[robtwn]

Thanks Xobs. I'll give your suggestion (using regutil to change the kernel values) and see what happens. Will advise further.

very best regards/robert