[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Possible timing problems


The for-loop is not removed by the comiler. The compiler generates
the following assembler code for the for loop:

cmpq -1,r9
bne a
subq 1,r9 ; Delay slot

This means that each iteration is 3 clock cycles so the loop
actually delays usec * 1.5 microseconds.

The I2C driver has only been tested with EEPROMs so there might
be bugs that causes communication with other peripherals to fail.

Best regards

-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com]On">mailto:owner-dev-etrax@xxxxxxx.com]On
Behalf Of Jonas Aaberg
Sent: Friday, February 16, 2001 4:08 PM
To: dev-etrax
Subject: Possible timing problems


I just wonder, is it measured(or check that the asm code) that
this following code from /drivers/char/i2c.c takes one microsecond
per given "usec" to execute?

i2c_delay(int usec)
  int i;  
  if (usec > 0)
    for(i = 50 * (usec); i--;) /* nothing */ ; 

Maybe it is optimized away with the C-compiler, because it thinks it's

It is only that I've connected a I2C chip to the I2C channel, and
is correct, except read. I just get junk then. (Or more exact 0x01FF or
Also, SMBus units doesn't even respond to simple set address command(or
specific SMBus quick command.) For example, I've made an autoscan
program, and
it finds I2C units, but not SMBus units. That really looks like I'm on
the edge
of what is allowed in timing when it comes to the I2C specification(or
chip can handle things outside the specification, except when it comes
to read.)
and when I use a SMBus chip, then the timing is too wrong for it to even
on a Quick command.(Quick command = Only address and read/write + start
and stop.
I2C always have to have one byte more.)

Best regards,