From: DJ D. <dj...@de...> - 2007-02-19 15:16:29
|
I finally got my r8c's to listen to the gumstix's i2c, then noticed I was only getting about one transaction per second. After some debugging, I ended up doing the following: * disable the kernel debug messages * disable i2c slave mode * boost i2c speed to 400KHz It was slave mode that was causing the 1s delay, it turns out there's a 1s timeout in the return-to-slave-mode code. Any comments on this? I don't think I need slave mode, but there must be a better way to use it than to suffer a 1s delay. Anyway, I've benchmarked 6,250 4-byte i2c transactions per second now, plenty fast enough for my needs. |
From: Dave H. <dhy...@gm...> - 2007-02-19 15:24:07
|
Hi DJ, > I finally got my r8c's to listen to the gumstix's i2c, then noticed I > was only getting about one transaction per second. After some debugging, > I ended up doing the following: > > * disable the kernel debug messages > * disable i2c slave mode > * boost i2c speed to 400KHz > > It was slave mode that was causing the 1s delay, it turns out there's > a 1s timeout in the return-to-slave-mode code. Any comments on this? > I don't think I need slave mode, but there must be a better way to use > it than to suffer a 1s delay. That does seem excessive, and may have just been a debugging thing leftover from the original author. The whole slave mode thing isn't really supported well anyways, it was setup to make the gumstix look like a 256 byte EEPROM or something. > Anyway, I've benchmarked 6,250 4-byte i2c transactions per second now, > plenty fast enough for my needs. If you meant 4 bytes total, including the address, then that's 4 x 6250 = 25,000 bytes/sec = 225,000 bits/sec (there are 8 data bits and 1 ack bit per byte), which seems pretty respectible for a synchrnous API. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: DJ D. <dj...@de...> - 2007-02-19 15:51:59
|
"Dave Hylands" <dhy...@gm...> writes: > If you meant 4 bytes total, including the address, then that's 4 x > 6250 = 25,000 bytes/sec = 225,000 bits/sec (there are 8 data bits and > 1 ack bit per byte), which seems pretty respectible for a synchrnous > API. Nope, 4 bytes payload. 5 total. There's about a 1 bit gap between bytes, and 3-4 bits between packets. Say, 55 bits with start and stop. The logic analyzer says the i2c clock is only 340KHz (about 6250 * 55). The 100KHz clock is only 95.6KHz. |
From: DJ D. <dj...@de...> - 2007-02-19 16:05:51
|
DJ Delorie <dj...@de...> writes: > The logic analyzer says the i2c clock is only 340KHz (about 6250 * > 55). > > The 100KHz clock is only 95.6KHz. Hmmm... the PXA specs say the i2c module is clocked at 31.949 kHz (instead of ~33 kHz), giving 95.847 kHz and 383.388 kHz. |
From: Dave H. <dhy...@gm...> - 2007-02-19 17:58:47
|
Hi DJ, On 19 Feb 2007 10:51:38 -0500, DJ Delorie <dj...@de...> wrote: > > "Dave Hylands" <dhy...@gm...> writes: > > If you meant 4 bytes total, including the address, then that's 4 x > > 6250 = 25,000 bytes/sec = 225,000 bits/sec (there are 8 data bits and > > 1 ack bit per byte), which seems pretty respectible for a synchrnous > > API. > > Nope, 4 bytes payload. 5 total. There's about a 1 bit gap between > bytes, and 3-4 bits between packets. Say, 55 bits with start and > stop. The logic analyzer says the i2c clock is only 340KHz (about > 6250 * 55). So the slave device is allowed to stretch the clock, so what could be happening is that the master will only start a clock on one of its clock cycle boundaries, and if the slave stetches the clock by a small amount, then the master may wait until the next clock cycle boundary before starting the next bit. > The 100KHz clock is only 95.6KHz. That's good to know. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: DJ D. <dj...@de...> - 2007-02-19 18:17:47
|
"Dave Hylands" <dhy...@gm...> writes: > So the slave device is allowed to stretch the clock, so what could be > happening is that the master will only start a clock on one of its > clock cycle boundaries, and if the slave stetches the clock by a small > amount, then the master may wait until the next clock cycle boundary > before starting the next bit. I tightened up the RX code in the r8c, so that it's done processing before the rising edge of the next clock. Plus, the r8c has an RX buffer so that it doesn't need to stretch the clock (it does if you don't read the *previous* byte though, but that's 9 clocks ago). The PXA still skips a clock between bytes. Don't know why. I switched to 100kHz mode via pxaregs and it doesn't skip clocks. I'm filing this under "huh" and not worrying about it any more. |