Hi everyone,
I've just been working on (1) a kernel driver, and (2) a userspace
driver for the DevanTech SRF02 i2c sonar device. The SRF02 operates at
5V logic levels, while most i2c-gpio implementations use 3.3 V (or
whatever the I/O of the main chip is), which necessitated a
level-shifting circuit.
Neither the kernel or userspace driver have worked up until now and I
suspected that it had something to do with my bi-directional
level-shifter, which was designed in the same vain as that in the
following two application notes from Philips / NXP.
http://www.standardics.nxp.com/support/documents/i2c/pdf/an97055.pdf
http://www.nxp.com/acrobat_download/applicationnotes/AN10441_1.pdf
The only real difference in my design vs. the AN is that I was using
irfd110 from Vishay as opposed to the BSS type more common in Europe.
After taking a look with my handy USB function generator and scope, I
did a frequency sweep and noticed that the amplitude response of my
level shifter was pretty horrible at 100 kHz, with a -6dB drop, and
even worse with higher frequencies. However, the specs of the irfd110
transistors are still well within the range specified in the NXP /
Philips application notes.
Checking out drivers/i2c/busses/i2c-gpio.c, I read that a udelay of 50
corresponds to 10 kHz, and a udelay of 5 corresponds to 100 kHz. After
checking out the patch for arch/arm/mach-ep93xx/core.c, I saw that
the udelay field was set to 2. This leads me to conclude that the
i2c-gpio on the TS boards, by default, have a bus frequency of 250
kHz. Is that correct ??
Taking a step back, all I really want or need in my I2C bus is 10 kHz,
and my tests have shown that my el-cheapo, 2-transistor level-shifter
has a unity amplitude response at 10 kHz. So I statically set my
udelay to be 50, recompiled my kernel, and my level shifting circuit
works perfectly now.
Just a thought for the i2c-gpio kernel module ... maybe its a good
idea for i2c-gpio module to accept a parameter, 'udelay=n', which
would force a specified i2c bus frequency; 50=10kHz, 5==100kHz,
2==250kHz. A quick check of the module parameter would be easy to
write up too.
Does anybody know if i2c-core actually attempts to drive the bus at
slower frequencies if a read or write op fails? A couple of times I've
seen dmesg say that a read was successful on the 3rd attempt. If not,
then accepting a timing parameter would certainly help.
Any thoughts?
Chris
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|