Menu
▾
▴
lcd4linux-devel
|
From: Luis C. <lfc...@lf...> - 2005-05-24 22:19:44
|
...but it is too slow to be useable My initial thoughts were correct, something (not really lcd4linux) is slowing lcd4linux down. It may be my board, it's I2C bus driver or my whole i2c implementation inside lcd4linux. Don't get me wrong, for pretty much static text it is ok, but not for something that moves (OS widget for an example). During the next days i'll try to profile it and see what is causing this but I guess it is the expected slow I2C bus. Paul will not agree with my assumptions, as his system runs OK :) Luis Correia |
|
From: Luis C. <lfc...@lf...> - 2005-05-24 22:31:42
|
Luis Correia wrote: > ...but it is too slow to be useable > > My initial thoughts were correct, something (not really lcd4linux) is > slowing lcd4linux down. It may be my board, it's I2C bus driver or my > whole i2c implementation inside lcd4linux. > Don't get me wrong, for pretty much static text it is ok, but not for > something that moves (OS widget for an example). > > During the next days i'll try to profile it and see what is causing > this but I guess it is the expected slow I2C bus. > Paul will not agree with my assumptions, as his system runs OK :) > > Luis Correia Oh, I forgot, to achieve this I had to change some lines inside drv_generic_i2c.c, but nothing major. I'll work with Paul to try and find a common sense in my changes. (this basicly means, 'if it works for Paul too' :) Luis Correia |
|
From: Luis C. <lfc...@lf...> - 2005-05-31 20:50:44
|
Hi! I hope i did not make any mess this time. Since me and Paul have been busy making this I2C sucker work for all of us (yes, that includes Michael). First approach was to remove the dependency from the I2C kernel includes, by having our own file (lcd4linux_i2c.h). Then the autoconf files were tweaked in order to always detect I2C (this is a matter that needs ot be addressed by someone with more auto* knowledge). Finally, the drv_generic_i2c and the drv_HD44780 files were cleaned up. Please test the current CVS code as some mistakes may have been introduced. p.s. the python errors are still present, i made NO attempt to fix it, as have no use for that... Luis Correia |
|
From: Luis C. <lfc...@lf...> - 2005-05-31 21:13:27
|
> p.s. the python errors are still present, i made NO attempt to fix it, > as have no use for that... > More python errors would have occoured as I accidently removed the detection code from configure.in Commited the fix just now :) Luis Correia |
|
From: Michael R. <re...@eu...> - 2005-06-01 04:50:38
|
Hi alltogether, > Since me and Paul have been busy making this I2C sucker work for all of > us (yes, that includes Michael). Works here! (I'm *that* happy :-) At least it compiles, I don't have any I2C-display around... Thanks for the good work! > 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 There are some compiler warnings (about unused arguments) which should be easy to clean up. 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? bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Luis C. <lfc...@lf...> - 2005-06-01 06:46:09
|
Michael Reinelt wrote:
>Hi alltogether,
>
>
>
>>Since me and Paul have been busy making this I2C sucker work for all of
>>us (yes, that includes Michael).
>>
>>
>Works here! (I'm *that* happy :-) At least it compiles, I don't have any
>I2C-display around...
>
>Thanks for the good work!
>
>
Finally!!!
>
>
>>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
>
>
>
Yes, that would be great.
>There are some compiler warnings (about unused arguments) which should
>be easy to clean up.
>
>
>
Well, we are using the HD44780 framework but we no longer use the
'delay' argument.
We may setup something that would take care of that. It is cosmetic only :)
>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?
>
>
>
Well, we do use a real i2c bus for the moment.
The paralell port can be used as an emulated i2c, but code would have to
be written, and our current framework is not ready for that.
It may become similar to the HD44780 with all the quirky modes (4bit,
8bit, ppdev, pure paralell...).
For my embedded board, i'm also thinking to add temperature reading, as
the sensor is also present in the other I2C bus. And no, i will not use
lm_sensors for that. The device is not supported and the whole
lm_sensors is kinda bloated for what I need. To give you an idea,
reading the temperature is a 6 liner .
---------------------
i2c_device = open("/dev/i2c-1",O_RDWR);
ioctl(i2c_device,I2C_SLAVE, (0x90>>1) );
temp = i2c_smbus_read_word_data(i2c_device, 0);
temp = ((((temp && 0x00FF)<< 9) + (temp >> 8)) >> 3) / 2;
printf("temperature: %i \n",temp);
close(i2c_device);
---------------------
>bye, Michael
>
>
>
We are also planning to make another mode for this I2C driver, which
would use two PCF8574 I2C I/O extenders, in order to provide an 8 bit
interface to the LCD display, plus a small keyboard. Thus, one of the
things we are curious about is how are you going to implement keyboard
support to LCD4Linux. Our keyboard will probably be very simple, 4 or 6
keys.
Luis Correia
|
|
From: Michael R. <re...@eu...> - 2005-06-01 11:59:23
|
Hi Luis,
> For my embedded board, i'm also thinking to add temperature reading, as
> the sensor is also present in the other I2C bus. And no, i will not use
> lm_sensors for that. The device is not supported and the whole
> lm_sensors is kinda bloated for what I need. To give you an idea,
> reading the temperature is a 6 liner .
> ---------------------
> i2c_device = open("/dev/i2c-1",O_RDWR);
> ioctl(i2c_device,I2C_SLAVE, (0x90>>1) );
> temp = i2c_smbus_read_word_data(i2c_device, 0);
> temp = ((((temp && 0x00FF)<< 9) + (temp >> 8)) >> 3) / 2;
> printf("temperature: %i \n",temp);
> close(i2c_device);
> ---------------------
Looks like a candiate for a plugin (but independent from the driver).
Maybe a as-generic-as-possible one, so you can read from any i2c device...
bye, Michael
--
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781
|
|
From: paul k. <pau...@xs...> - 2005-06-01 07:52:34
|
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 |
|
From: Martin H. <ma...@he...> - 2005-06-01 10:54:23
|
Hi Paul, >> 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!! adding __attribute__ ((unused)) in front of each unused parameter should make gcc shut up. I just tried it here, and it seems to work with my gcc. Martin |
|
From: paul k. <pau...@xs...> - 2005-06-01 11:19:30
|
Thanks Martin, That did the trick. If I didn't make a mistake, it should be in CVS now. Paul Martin Hejl wrote: > Hi Paul, > >>> 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!! > > adding > __attribute__ ((unused)) > in front of each unused parameter should make gcc shut up. I just > tried it here, and it seems to work with my gcc. > > Martin > > > |
|
From: Michael R. <re...@eu...> - 2005-06-01 12:01:38
|
Hi Paul, >> [i2c emulated by parallel or serial port] > 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. Sounds good. do you have an URL? I will need any i2c to test my new displays! bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-06-02 03:29:24
|
Hi all, Paul answered my question about i2c-over-parport, and pointed me here: > http://www.linuxhq.com/kernel/v2.6/12-rc3/Documentation/i2c/i2c-parport Looks like this i2c-parport is part of the standard kernel (at least my 2.6.11). Anyone out there could try this one with the current i2c code? I don't have any i2c display up and running here.... If this works, someone should write some documentation in the wiki :-( bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Luis C. <lfc...@lf...> - 2005-06-02 06:52:40
|
Michael Reinelt wrote: >Hi all, > >Paul answered my question about i2c-over-parport, and pointed me here: > > > >>http://www.linuxhq.com/kernel/v2.6/12-rc3/Documentation/i2c/i2c-parport >> >> > >Looks like this i2c-parport is part of the standard kernel (at least my >2.6.11). Anyone out there could try this one with the current i2c code? >I don't have any i2c display up and running here.... > > > The current I2C code is PCF8574 specific and will probably not work with just any I2C displays. While the bus related stuff is probably OK, it will depend on how this particular I2C display was wired. I have no 'real' i2c displays around here to test. >If this works, someone should write some documentation in the wiki :-( > > >bye, Michael > > > Luis Correia |
|
From: Michael R. <re...@eu...> - 2005-06-03 17:17:18
|
Hi Luis, > The current I2C code is PCF8574 specific and will probably not work > with just any I2C displays. While the bus related stuff is probably > OK, it will depend on how this particular I2C display was wired. Ah, I understand: The current i2c support is HD44780 specific... thanks, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X