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

Re: Possible timing problems

Mikael Starvik wrote:
> The for-loop is not removed by the comiler. The compiler generates
> the following assembler code for the for loop:
> a:
> 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.
Yes, I saw that this morning. I did connect a logical analyzer to it
and saw that it took about 12-13 us per i2c_delay(8)

> The I2C driver has only been tested with EEPROMs so there might
> be bugs that causes communication with other peripherals to fail.
Yes, there are a couple of bugs in the i2c driver that makes it fail
with other peripherals(I'm testing with an National LM77 evaluation
For example, the timing in i2c_start and i2c_stop. 

I've rewritten most part of the I2C driver, added some functionallty and 
now it is an object file that I link with. (I want it to be as an
because later we will have a daemon that will be checking some I2C and S
MBus units and it will be easier to upgrade it, it it is not a real
in the kernel.)
The I2C support works now fully.(atleast with LM77 :)

I will add SMBus support, and then I will send my code to Axis so you
can test it with your EEPROM and maybe made a device driver of it.

Best regards,