Re: [Lcd4linux-devel] Working I2C was commited minutes ago

[paul k. <pau...@xs...>]

Hi Michael,

>Works here! (I'm *that* happy :-) At least it compiles, I don't have any
>I2C-display around...
>
>Thanks for the good work
>  
>
That is good news. Here is to some extend what Luis and I did:

- copied relevant information from the kernel i2c headers files to 
lcd4linux_i2c.h
- copied inline i2c functions from a kernel source to the same 
lcd4linux_i2c.h
- removed/changed the kernel i2c include detection from configure.in and 
drivers.m4
- use lcd4linux_i2c.h in drv_generic_i2c.c instead of the kernel includes

All that works fine. Only remaining problem was the speed concerns on 
Luis his system.
To improve this we first removed all delays related to the write cycle 
protocol. The
reason for this is simple. i2c clock is max 100 kHz and changing the 
pcf8574 output takes 2
byte writes (1 address + 1 byte) taking about 20 clock cycles. So 
nanosecond delays are
implicit in the i2c protocol.

In the next step we changed the I2C_nibble function. In this function 3 
seperate i2c writes are made.
Each of these writes is an ioctl call causing a switch over from 
userspace to kernelspace to perform the
actual i2c write. Now we set up an array with all the consequetive 
values to write and then call ioctl
once to write the entire block (3 bytes for a nibble). Additional 
improvement can be achieved by
changing i2c_byte in a similar way. For Luis this improvement was 
sufficient (for now) so we decided to
check in. Luis cleaned up and did the final check-in.

Luis and me are now discussing how we can support two pcf8574 device, so 
we can support displays
in 8-bit mode too.

>>p.s. the python errors are still present, i made NO attempt to fix it,
>>as have no use for that...
>>    
>>
>I'm going to introduce a '--with-python' switch, which is disabled by
>default, so it won't disturb. As soon as this is fixed, I want to
>release 0.10
>  
>
Good idea to add a switch like that. Please remember that I still do 
have this strange problem
with the AC_PYTHON_DEVEL macro in configure.in. If I leave this line in, 
I get that
AC_PYTHON_PATH not found messsage and my entire build related files get 
mixed up.
Making it impossible for me to do a build.
Somehow this AC_PYTHON_PATH macro in python.m4 is blowing up in my face.
I can live with it for now, I don't need python at the moment. But it 
could give a lot of problems
in a release version.

>There are some compiler warnings (about unused arguments) which should
>be easy to clean up.
>  
>
I just read Luis his response. Yes it is cosmetic, but also simple to 
solve.  :-( I rephrase that, not so
simple to solve. I tried the Visual Studio solution (comment out the 
unused parameter name) but that changes
the warning into an error. Nice!!

>Another question: The current i2c code uses a 'real' i2c bus (which I
>don't have in my notebook, at least I cannot connect anything to it).
>I've seen in serdisplib that it's possible to 'emulate' a i2c bus on the
>serial port; and I got a (very strange) display from Pollin yesterday,
>which is also driven by i2c, and their sample program use the parallel
>port for i2c emulation....
>
>Should we add support for it?
>  
>
I don't think we should. Most certainly not right now. I remember seeing 
a kernel module somewhere that
provided this i2c over parallel port emulation. That could be a nice 
solution for it.

Kind regards,

Paul

PS: Luis, thanks for the clean-up and the check-in