lcd4linux-devel Mailing List for lcd4linux (Page 36)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Michael,

In January you released the 0.10 RC1 of lcd4linux. Can you give some 
information on what remains to be done prior to 0.10 release?

Cheers,

Paul

Hi there,

I just checked in some changes to several plugins (pop3, mysql, imon,
i2c_sensors), and I kindly ask you to test them and give us some feedback.

The change is that these plugins did a lot of things beside the
"AddFunction()" call. I moved these stuff into its own function
(configure_xy), and this function will be called on a first-use basis.
This way there are no more annoying errors on startup like "i2c_sensors:
unable to autodetect i2c sensors!" or "[POP3] No 'Plugin:POP3.server1'
entry from /etc/lcd4linux.conf, disabling POP3 account #1" which may
confuse the user.

Have Fun!

bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Hi Michael

The problem is indeed in configure.in. The nested AC_CHECK_HEADERS 
doesn't work properly. (not sure why)

AC_CHECK_HEADERS(linux/compiler.h,
       [AC_CHECK_HEADERS(linux/i2c.h,[

AC_CHECK_HEADERS(linux/i2c-dev.h,[has_i2c=true],[has_i2c=false]$
               ],[has_i2c=false])]
       [has_i2c=false]
)

There are actually two problems. One of them generates the warnings on 
linux/i2c-dev.h
If I understand correctly, the behaviour of autoconf is changed. Instead 
of only preprocessing the header files, they now try to compile the 
files. If the file doesn't compile the warning is generated, so the 
developers (i.e. us) can change it.
In the current autoconf versions, the file is still accepted if 
preprocessing goes well. But for future versions of autoconf, the check 
is based on if the file actually compiles. So it is recommended that we 
eliminate the warning by listing the required include files to make 
linux/i2c-dev.h compile.

This is done by:
AC_CHECK_HEADERS(linux/i2c-dev.h,[has_i2c=true],[has_i2c=false],[#include 
<linux/compiler.h>;#include <linux/i2c.h>;])

Using this line as the third line in the nested sequence above, still 
doesn't work. All 3 includes are correctly validated, but for some 
reason has_i2c is never set to true.
I solved by changing the entire nested sequence to:
AC_CHECK_HEADERS(linux/compiler.h linux/i2c.h 
linux/i2c-dev.h,[has_i2c=true],[has_i2c=false],[#include 
<linux/compiler.h>;#include <linux/i2c.h>;])

That works for me to enable i2c support, and also disables i2c support 
when linux/compiler.h is missing.

I still have to do some additional tests, but you can give it a try with 
the above line.

Cheers,

Paul

Michael Reinelt wrote:

>Hi Luis,
>
>  
>
>>Although you do have ifdef's around my I2C functions, and after I
>>manually enable I2C by editing config.h, it seems to ignore the
>>drv_generic_i2c.h file, as it spews out errors at tthe end, and
>>drv_generic_i2c.c is not being compiled at all...
>>
>>What does the configure look for in order to detect I2C as present?
>>    
>>
>
>Well, editing config.h isn't enough. The drv_generic_i2c.o will not be
>compiled and linked if configure cannot find the i2c includes (or thinks
>they're unusable, as it happens here).
>
>The detection is done within configure.in, line 57, which sets the
>variable "has_i2c" to true or false. This variable is checked in
>drivers.m4, at the very end, and ex-/includes drv_generic_i2c.o, and
>defines the WITH_I2C preprocessor symbol.
>
>configure checks for compiler.h, i2c.h and i2c-dev.h. Take a look at
>your config.log, it should contain some messages about i2c.
>
>
>bye, Michael
>
>  
>

Hi Luis,

> Although you do have ifdef's around my I2C functions, and after I
> manually enable I2C by editing config.h, it seems to ignore the
> drv_generic_i2c.h file, as it spews out errors at tthe end, and
> drv_generic_i2c.c is not being compiled at all...
> 
> What does the configure look for in order to detect I2C as present?

Well, editing config.h isn't enough. The drv_generic_i2c.o will not be
compiled and linked if configure cannot find the i2c includes (or thinks
they're unusable, as it happens here).

The detection is done within configure.in, line 57, which sets the
variable "has_i2c" to true or false. This variable is checked in
drivers.m4, at the very end, and ex-/includes drv_generic_i2c.o, and
defines the WITH_I2C preprocessor symbol.

configure checks for compiler.h, i2c.h and i2c-dev.h. Take a look at
your config.log, it should contain some messages about i2c.

bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Hi! 

> -----Original Message-----
> From: Paul Kamphuis [mailto:pau...@xs...] 
> Sent: Wednesday, March 30, 2005 1:46 PM
> To: Luis.F.Correia; lcd4linux devel
> Subject: Re: [Lcd4linux-devel] I2C modifications to HD44780 driver
> 
> Ok, I was to quick on the previous mail.
> In i2c_Open I assigned the section pointer to the Section 
> variable, and 
> it all works now!!!

Great, now what do I need to change?

> 
> Now the only thing that remains is to sort out why autoconf doesn't 
> validate linux/i2c-dev.h properly.

Let's validade only i2c-dev.h, and assume that i2c.h also exists.

> 
> Cheers,
> 
> Paul
> 
> 

Luis

Ok, I was to quick on the previous mail.
In i2c_Open I assigned the section pointer to the Section variable, and 
it all works now!!!

Now the only thing that remains is to sort out why autoconf doesn't 
validate linux/i2c-dev.h properly.

Cheers,

Paul

Hi!

> -----Original Message-----
> From: Paul Kamphuis [mailto:pau...@xs...] 
> Sent: Wednesday, March 30, 2005 1:30 PM
> To: Luis.F.Correia; lcd4linux devel
> Subject: Re: [Lcd4linux-devel] I2C modifications to HD44780 driver
> 
> Hi Luis,
> 
> I found the problem. The wire configuration is not read 
> correctly from 
> the config file. It uses the default all the time. (and I have RS/RW 
> wired differently)
> This is how my display definition is constructed:
> 
> Display HD44780-I2C {
>     Driver 'HD44780'
>     Bus 'i2c'
>     Port '/dev/i2c-0'
>     Device '38'
>     Bits '4'
>     Size '16x2'
>     asc255bug 0
>     Icons 1
>     Wire {
>         RW     'DB4'
>         RS     'DB5'
>         ENABLE 'DB6'
>         GPO    'GND'
>     }
> }
> 
> Is that correct?

It seems to be ok, I'll have to make additional checks in order to see if
the values
are really read correctly. I just copy/pasted that piece of code from
another driver...

I can't make an actual test in any of my current development platforms, as
none has
a working I2C bus.

Luis Correia

> I noticed that the Section and Driver strings are allways 
> empty strings 
> in drv_generic_i2c.c is that correct?
> 
> thanks,
> 
> Paul
> 
> 
> Luis.F.Correia wrote:
> 
> >Hi Paul! 
> >
> >  
> >
> >>-----Original Message-----
> >>From: Paul Kamphuis [mailto:pau...@xs...] 
> >>Sent: Wednesday, March 30, 2005 8:01 AM
> >>To: Luis Correia; lcd4linux devel
> >>Subject: Re: [Lcd4linux-devel] I2C modifications to HD44780 driver
> >>
> >>Hi Luis and Michael,
> >>
> >>I did a check this morning. A 'normal' build doesn't enable the i2c 
> >>support as you both noticed. The reason for this is that in 
> >>the autoconf 
> >>phase of the build the include file linux/i2c-dev.h is not 
> >>detected as 
> >>valid. I am not sure of the reason but it has to do with the 
> >>way it is 
> >>validated by autoconf. I edited configure.in to return true 
> >>for the i2c 
> >>support even in the invalid case. It now builds nicely and 
> >>i2c support 
> >>is also enabled.
> >>Unfortunately doesn't work properly yet. I'll have to look 
> >>into it later 
> >>today. My guess is, that it has to do with the specification of the 
> >>ENABLE, RW, RS control signals. At least the observed 
> behaviour seems 
> >>similar to what I had initialy.
> >>
> >>    
> >>
> >
> >Well, all you will need to do is to create a setup similar to what is
> >in the lcd4linux.conf.sample, search for 'WRAP1C'.
> >
> >Copy that definition, edit where appropriate and it should work.
> >
> >You'll need to edit the i2c bus, the device address and where do
> >the signals go in terms of databus.
> >
> >However, if your 4 data pins do not correspond to the lower 
> 4 bus bits
> >(ie D0 - D3) then the code needs another rewrite, but it is doable.
> >
> >
> >  
> >
> >>Later today I should have some more time to test.
> >>
> >>Cheers,
> >>
> >>Paul
> >>
> >>    
> >>
> >
> >Tell me your thoughts on this!
> >
> >Luis Correia
> >
> >
> >-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT Products from 
> real users.
> >Discover which products truly live up to the hype. Start reading now.
> >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >_______________________________________________
> >Lcd4linux-devel mailing list
> >Lcd...@li...
> >https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
> >
> >
> >  
> >
> 
> 

Hi Luis,

I found the problem. The wire configuration is not read correctly from 
the config file. It uses the default all the time. (and I have RS/RW 
wired differently)
This is how my display definition is constructed:

Display HD44780-I2C {
    Driver 'HD44780'
    Bus 'i2c'
    Port '/dev/i2c-0'
    Device '38'
    Bits '4'
    Size '16x2'
    asc255bug 0
    Icons 1
    Wire {
        RW     'DB4'
        RS     'DB5'
        ENABLE 'DB6'
        GPO    'GND'
    }
}

Is that correct?
I noticed that the Section and Driver strings are allways empty strings 
in drv_generic_i2c.c is that correct?

thanks,

Paul

Luis.F.Correia wrote:

>Hi Paul! 
>
>  
>
>>-----Original Message-----
>>From: Paul Kamphuis [mailto:pau...@xs...] 
>>Sent: Wednesday, March 30, 2005 8:01 AM
>>To: Luis Correia; lcd4linux devel
>>Subject: Re: [Lcd4linux-devel] I2C modifications to HD44780 driver
>>
>>Hi Luis and Michael,
>>
>>I did a check this morning. A 'normal' build doesn't enable the i2c 
>>support as you both noticed. The reason for this is that in 
>>the autoconf 
>>phase of the build the include file linux/i2c-dev.h is not 
>>detected as 
>>valid. I am not sure of the reason but it has to do with the 
>>way it is 
>>validated by autoconf. I edited configure.in to return true 
>>for the i2c 
>>support even in the invalid case. It now builds nicely and 
>>i2c support 
>>is also enabled.
>>Unfortunately doesn't work properly yet. I'll have to look 
>>into it later 
>>today. My guess is, that it has to do with the specification of the 
>>ENABLE, RW, RS control signals. At least the observed behaviour seems 
>>similar to what I had initialy.
>>
>>    
>>
>
>Well, all you will need to do is to create a setup similar to what is
>in the lcd4linux.conf.sample, search for 'WRAP1C'.
>
>Copy that definition, edit where appropriate and it should work.
>
>You'll need to edit the i2c bus, the device address and where do
>the signals go in terms of databus.
>
>However, if your 4 data pins do not correspond to the lower 4 bus bits
>(ie D0 - D3) then the code needs another rewrite, but it is doable.
>
>
>  
>
>>Later today I should have some more time to test.
>>
>>Cheers,
>>
>>Paul
>>
>>    
>>
>
>Tell me your thoughts on this!
>
>Luis Correia
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Lcd4linux-devel mailing list
>Lcd...@li...
>https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
>
>
>  
>

Hi Paul! 

> -----Original Message-----
> From: Paul Kamphuis [mailto:pau...@xs...] 
> Sent: Wednesday, March 30, 2005 8:01 AM
> To: Luis Correia; lcd4linux devel
> Subject: Re: [Lcd4linux-devel] I2C modifications to HD44780 driver
> 
> Hi Luis and Michael,
> 
> I did a check this morning. A 'normal' build doesn't enable the i2c 
> support as you both noticed. The reason for this is that in 
> the autoconf 
> phase of the build the include file linux/i2c-dev.h is not 
> detected as 
> valid. I am not sure of the reason but it has to do with the 
> way it is 
> validated by autoconf. I edited configure.in to return true 
> for the i2c 
> support even in the invalid case. It now builds nicely and 
> i2c support 
> is also enabled.
> Unfortunately doesn't work properly yet. I'll have to look 
> into it later 
> today. My guess is, that it has to do with the specification of the 
> ENABLE, RW, RS control signals. At least the observed behaviour seems 
> similar to what I had initialy.
> 

Well, all you will need to do is to create a setup similar to what is
in the lcd4linux.conf.sample, search for 'WRAP1C'.

Copy that definition, edit where appropriate and it should work.

You'll need to edit the i2c bus, the device address and where do
the signals go in terms of databus.

However, if your 4 data pins do not correspond to the lower 4 bus bits
(ie D0 - D3) then the code needs another rewrite, but it is doable.

> Later today I should have some more time to test.
> 
> Cheers,
> 
> Paul
> 

Tell me your thoughts on this!

Luis Correia

Hi Luis and Michael,

I did a check this morning. A 'normal' build doesn't enable the i2c 
support as you both noticed. The reason for this is that in the autoconf 
phase of the build the include file linux/i2c-dev.h is not detected as 
valid. I am not sure of the reason but it has to do with the way it is 
validated by autoconf. I edited configure.in to return true for the i2c 
support even in the invalid case. It now builds nicely and i2c support 
is also enabled.
Unfortunately doesn't work properly yet. I'll have to look into it later 
today. My guess is, that it has to do with the specification of the 
ENABLE, RW, RS control signals. At least the observed behaviour seems 
similar to what I had initialy.

Later today I should have some more time to test.

Cheers,

Paul

Luis Correia wrote:

> Michael Reinelt wrote:
>
>> Hi Luis,
>>
>>  
>>
>>> My devel system is Fedora Core 3 with all the latest updates. Yes, it
>>> is a 2.6 series kernel.
>>>   
>>
>> Mine is debian sarge/sid/experimental/dangerous/bleeding_edge/.., but
>> with a self-brewed vanilla kernel 2.6.11
>>
>>  
>>
>>> But I2C is a major hack if you ask me...
>>>   
>>
>> Full ACK.
>>  
>>
>>> Kernel has it's own i2c functions, the lm_sensors project also has 
>>> some other functions.
>>>   
>>
>> I did have a look at lm_sensors, looks like they don't use the i2c
>> interface at all, but access the /proc or /sys files only.
>>
>>  
>>
>>> Let's do this, please include these two files, and i'll see what can
>>> be done about detecting the proper i2c includes.
>>>   
>>
>> I commited your patch with some modifications, and added all the auto*
>> stuff. It compiles cleanly here, but for a simple reason: configure
>> decieds that linux/i2c.h is unusable, and therefore deactivates I2C
>> support :-)
>>
>> Please give it a try!
>>
>>  
>>
> I did... it seems there is still a problem...
>
> Although you do have ifdef's around my I2C functions, and after I 
> manually enable I2C by editing config.h, it seems to ignore the 
> drv_generic_i2c.h file, as it spews out errors at tthe end, and 
> drv_generic_i2c.c is not being compiled at all...
>
> What does the configure look for in order to detect I2C as present?
>
>> bye, Michael
>>
>>  
>>
>
> Luis
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Lcd4linux-devel mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
>
>

Michael Reinelt wrote:

>Hi Luis,
>
>  
>
>>My devel system is Fedora Core 3 with all the latest updates. Yes, it
>>is a 2.6 series kernel.
>>    
>>
>Mine is debian sarge/sid/experimental/dangerous/bleeding_edge/.., but
>with a self-brewed vanilla kernel 2.6.11
>
>  
>
>>But I2C is a major hack if you ask me...
>>    
>>
>Full ACK.
>  
>
>>Kernel has it's own i2c functions, the lm_sensors project also has 
>>some other functions.
>>    
>>
>I did have a look at lm_sensors, looks like they don't use the i2c
>interface at all, but access the /proc or /sys files only.
>
>  
>
>>Let's do this, please include these two files, and i'll see what can
>>be done about detecting the proper i2c includes.
>>    
>>
>I commited your patch with some modifications, and added all the auto*
>stuff. It compiles cleanly here, but for a simple reason: configure
>decieds that linux/i2c.h is unusable, and therefore deactivates I2C
>support :-)
>
>Please give it a try!
>
>  
>
I did... it seems there is still a problem...

Although you do have ifdef's around my I2C functions, and after I 
manually enable I2C by editing config.h, it seems to ignore the 
drv_generic_i2c.h file, as it spews out errors at tthe end, and 
drv_generic_i2c.c is not being compiled at all...

What does the configure look for in order to detect I2C as present?

>bye, Michael
>
>  
>

Luis

Hi Luis,

> My devel system is Fedora Core 3 with all the latest updates. Yes, it
> is a 2.6 series kernel.
Mine is debian sarge/sid/experimental/dangerous/bleeding_edge/.., but
with a self-brewed vanilla kernel 2.6.11

> But I2C is a major hack if you ask me...
Full ACK.
> Kernel has it's own i2c functions, the lm_sensors project also has 
> some other functions.
I did have a look at lm_sensors, looks like they don't use the i2c
interface at all, but access the /proc or /sys files only.

> Let's do this, please include these two files, and i'll see what can
> be done about detecting the proper i2c includes.
I commited your patch with some modifications, and added all the auto*
stuff. It compiles cleanly here, but for a simple reason: configure
decieds that linux/i2c.h is unusable, and therefore deactivates I2C
support :-)

Please give it a try!

bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Hi Michael,

> -----Original Message-----
> From: Michael Reinelt [mailto:re...@eu...] 
> Sent: Monday, March 28, 2005 8:08 AM
> To: lcd4linux devel
> Subject: Re: [Lcd4linux-devel] I2C modifications to HD44780 driver
> 
> Hi Luis,
> 
> > I told you i'm not very keen with this patch thighy... Here is the
> > correct tar.gz file with all files in it!
> > I forgot to tell you that the diff was created against last 
> night CVS at
> > sourceforge.
> 
> Thanks for the tar. Looks much better now :-)

Sorry about the mess. It was very late and I really wanted to put it out.
> 
> Anyway, I cannot compile it.I get tons of compiler errors, 
> all resulting
> from the including of linux/i2c.h. Seems to me that this file is not
> intended for userland inclusion :-)

Apart from the automake stuff not having the two new files, it does 
compile cleanly.

My devel system is Fedora Core 3 with all the latest updates.
Yes, it is a 2.6 series kernel.

But I2C is a major hack if you ask me...
Kernel has it's own i2c functions, the lm_sensors project also has 
some other functions.

When I stated this, I used only the in-kernel provided functions.
Later on, when Paul picked up the pieces, he told me that we cannot
use the in-kernel I2C, but rather use the userspace includes.

This weekend I took the sources with me and edited them in a 'doze
Pc, I had no compiling environment to test, until last night. Since
it did compile ok, I thought all was right.

Let's do this, please include these two files, and i'll see what
can be done about detecting the proper i2c includes.

[snip]

> 
> .... and so on.
> 
> Does it compile cleanly in your environment? If so, why?
> 
> 
> bye, Michael
> 
> -- 
> Michael Reinelt <re...@eu...>
> http://home.pages.at/reinelt
> GPG-Key 0xDF13BA50
> ICQ #288386781

Luis Correia

Hi Luis,

> I told you i'm not very keen with this patch thighy... Here is the
> correct tar.gz file with all files in it!
> I forgot to tell you that the diff was created against last night CVS a=
t
> sourceforge.

Thanks for the tar. Looks much better now :-)

Anyway, I cannot compile it.I get tons of compiler errors, all resulting
from the including of linux/i2c.h. Seems to me that this file is not
intended for userland inclusion :-)

here are some of the errors:

/usr/include/linux/jiffies.h:16: error: Fehler beim Parsen before
"jiffies_64"
/usr/include/linux/jiffies.h:20: error: Fehler beim Parsen before
"get_jiffies_64"
/usr/include/linux/bitmap.h:15: error: `BITS_PER_LONG' undeclared (first
use in this function)
/usr/include/linux/bitmap.h: In Funktion =BBbitmap_full=AB:
/usr/include/linux/bitmap.h:29: error: `BITS_PER_LONG' undeclared (first
use in this function)
/usr/include/linux/bitmap.h: In Funktion =BBbitmap_equal=AB:
/usr/include/linux/bitmap.h:44: error: `BITS_PER_LONG' undeclared (first
use in this function)
/usr/include/linux/bitmap.h: In Funktion =BBbitmap_shift_right=AB:
/usr/include/linux/bitmap.h:85: error: `__shr_tmp' undeclared (first use
in this function)
/usr/include/linux/bitmap.h: In Funktion =BBbitmap_shift_left=AB:
/usr/include/linux/bitmap.h:98: error: `__shl_tmp' undeclared (first use
in this function)
/usr/include/linux/bitmap.h:144: error: `BITS_PER_LONG' undeclared
(first use in this function)
/usr/include/linux/cpumask.h:15: error: variable-size type declared
outside of any function
/usr/include/linux/cpumask.h: In Funktion =BBnext_online_cpu=AB:
/usr/include/linux/cpumask.h:56: error: structure has no member named `va=
l'

.... and so on.

Does it compile cleanly in your environment? If so, why?

bye, Michael

--=20
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Michael Reinelt wrote:

>Hi Luis,
>
>  
>
>>during this small Easter break, I finnaly managed to take a deep look
>>into the changes Paul has made to the HD44780 driver.
>>Here is a small patch to the drv_HD44780.c file, and two new files that
>>abstract all I2C relevant code from the main driver.
>>    
>>
>
>Well, I tried to apply your patch, but there's a problem:
>
>First, please name a tar archive .tar.gz (and not .gz only). Took me
>some time to find out that it's not a diff :-)
>
>Second, the file drv_generic_i2c.c is missing, but the drv_generic_i2c.c
> has been added twice to the tar.
>
>Please send me the drv_generic_i2c.c as soon as possible, so I can
>finish the patch...
>
>after all, your patch looks fine!
>
>bye, Michael
>
>  
>
Hi!

I told you i'm not very keen with this patch thighy... Here is the 
correct tar.gz file with all files in it!
I forgot to tell you that the diff was created against last night CVS at 
sourceforge.

Luis Correia

Hi Luis,

> during this small Easter break, I finnaly managed to take a deep look
> into the changes Paul has made to the HD44780 driver.
> Here is a small patch to the drv_HD44780.c file, and two new files that
> abstract all I2C relevant code from the main driver.

Well, I tried to apply your patch, but there's a problem:

First, please name a tar archive .tar.gz (and not .gz only). Took me
some time to find out that it's not a diff :-)

Second, the file drv_generic_i2c.c is missing, but the drv_generic_i2c.c
 has been added twice to the tar.

Please send me the drv_generic_i2c.c as soon as possible, so I can
finish the patch...

after all, your patch looks fine!

bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Hi!

(This email is mainly directed to Paul and Michael)

during this small Easter break, I finnaly managed to take a deep look 
into the changes Paul has made to the HD44780 driver.
Here is a small patch to the drv_HD44780.c file, and two new files that 
abstract all I2C relevant code from the main driver.

To make this work at all, the ./configure scripts need to know about 
these new files. I'm not an expert with Makefiles, so Michael please 
help me with this one :)...
Unpack the attached file, apply the diff and copy the 
'drv_generic_i2c.[h,c]'.

This patchset is completely untested, as I don't currently have any I2C 
devices available for testing.

Paul, about the SIGNAL stuff, they are defined in the config file.
For example, my PCF based I2C used the same connections as the 4bit 
driver, Martin has made. This is the corresponding config entry:
Display HD44780-I2C {
    Driver 'HD44780'
    Model 'WRAP1C-PCF8574'
    Bus 'i2c'
    Port '/dev/i2c-0'
    Device '70'
    Bits '4'
    Size '20x4'
    asc255bug 0
    Icons 1
    Wire {
        RW     'DB5'
        RS     'DB4'
        ENABLE 'DB6'
        GPO    'GND'
    }
}

Basicly it is here where you say what is connected to where, although 
I'm not sure if it will work if it is wired differently then it is here...

Take a good shot at it and let me know.

Luis Correia, ashamed because it could not be tested... :(

Michael Reinelt wrote:

>Hi there,
>
>Luis.F.Correia schrieb:
>
>  
>
>>I'll need to think about abstracting the SIGNAL_RW* variables, in order to
>>make them work with different hardware implementations, as we both have.
>>Maybe the best way to do it is to create the drv_generic_i2c.c/h files, so
>>that all the relevant code could move there.
>>
>>Michael, do you agree with these proposed changes?
>>    
>>
>
>Of course I am! I even think thats what I suggested, didn't I?
>
>
>bye, Michael
>
>  
>
Yes it is...
meanwhile, time has run away :(
i got some very annoying work related issues to take care of...

Luis

Hi there,

Luis.F.Correia schrieb:

> I'll need to think about abstracting the SIGNAL_RW* variables, in order to
> make them work with different hardware implementations, as we both have.
> Maybe the best way to do it is to create the drv_generic_i2c.c/h files, so
> that all the relevant code could move there.
> 
> Michael, do you agree with these proposed changes?

Of course I am! I even think thats what I suggested, didn't I?

bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Hi,

today i wanted to fo on with my SED133x Driver, but due to some
Hardware issues there will be some delay. But i had some progress
last Weekend, some text have shown on my Display.

I think in a week or so it will go on.

bye,

Andre

Hi Guys and Gal's,

I am an Electronics Engineer.

I am still a newbie at C programming for *nix, but have done years of 
embedded programming :)

I am looking for any info on the optix LCD's as used in the Palm Pilots 
(older palm pro etc) as I have a dead one and would love to use its LCD :)

I will be able to help out with this project, and may even be able to 
port the drivers to FreeBSD (if not already done)

Regards,

Kat.

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.6.0 - Release Date: 2/03/2005

2nd mail tonight  ! 

I'm about to finish a driver for a Noritake VFD Display GU128X32-311 NR
display (You can find it on ebay for very cheap - just search "noritake
VFD").

It's a nice display, very bright, and made a cable to the parallel
port. 

It support a 128x32 graphic mode and 4x21 text-mode through a character
generator. 
My driver support the latest mode since I don't know yet how to handle
the graphical mode in lcd4linux, and beside that pixel-packing in this
display is a little difficult.

I would like to know it anybody has such a display already, and is
willing to give my driver a try (the driver will be ready for testing at
the end of the month, latest)

I will also put on the wiki the schematics for the parallel port cable
to the display.

Julien

Hello, i'm the writer of the SimpleLCD driver.

I wrote this simple driver primarily for serial link test, but also for
an unknown 2x20 serial VFD display I have.

It occurs that my display look very much alike the 
"WincorNixdorf Serial Cashier Displays BA63/BA66" that has been
mentioned on the wiki, ticket #2.

( I can take-over this ticket if you want michael)

After downlowding the doc and wandering a little bit I found out that my
display accept the vt-100 ESC-* code mentionned in the doc, in addition
to the normal ascii set I'm using.

So first of all, I would try the BA63 with this driver (the current CVS
version does not include vt-100 codes yet, but its works for me as it is
now)
My config-file section related to SimpleLCD for this display look like
this : 

Display SimpleLCD {
    Driver 'SimpleLCD'
    Port '/dev/ttyS0'
    Speed 9600
    # The following is to enable Odd parity on the port.
    Options 0001400
    # Not used yet - the ascii value of a black rect in decimal
    BarCharValue 219
    # Not used yet - if the display support ESC-* control sequences.
    VT100_Support 1
    Size '20x2'
}

[...]

Layout L20x2 {
    Row1 {
        Col1  'Temp' 
        Col11 'Fan'
    }
    Row2 {
        Col1 'Xmms'
    }
}

The display is slow, so I recommend putting slow-moving value on top and
fast-moving values on the last line, otherwise it flickers and it's
ugly.

I'm working on the ESC-* control sequence to improve that, *but* when I
start using them, I run into weird timing issues and sometime the LCD
just ignore my commands and then write wherever it wants !

Besides, I also want to keep the Simple mode (without esc-codes) for
other applications.

I also plan to add bar support for it, all al that soon.

Voila !

Julien

Hi Paul,

> I HAVE GOT IT WORKING!!!! :-)
Well, thats good news, indeed!

> On of the things that surprised me was that the commands where send
> using the send_byte command that actually tried to set the RS signal.
> (which should only be done for data) This is the strange thing. parallel
> port code does the same. I guess it has to do with the copy of the
> source code that I got from the web-site.

I double-checked the data sheet, and it looks like there was a mistake
in the Wiki documentation:

The data sheet I got says: RS = Register select, low => instruction
(command), high => data

So the parport code seems to be correct (it must be correct, because
it's working. And always remember: If it works, don't fix it :-)

> The second problem was that the SIGNAL_ENABLE, SIGNAL_RS and SIGNAL_RW
> were never set correctly. I did it manually now. But how should it be done?
These variables are set by a call to drv_generic_parport_wire_ctrl().
There is no such function for I2C. Maybe you should write one. Take a
look at drv_generic_parport.c; maybe there should be a drv_generic_i2c.c
too.

> So, if anyone can tell me what I should do to get this stuff in the
> official code?
As Luis already wrote, send the code to him, he can commit it into CVS.
If you did change something in the parport part, too, I wanna have a
look, too, please!

For the future, I can give you CVS write access, so you can commit
further changes yourself. All I'd need is your SourceForge account name.

bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Paul Kamphuis wrote:

> Hi everyone,
>
> Finally found the time to have a look at the I2C display. Let's start 
> with the good news:
>
> I HAVE GOT IT WORKING!!!! :-)
>
> Turned out there where several issues. Some of them are in the 
> parallel port part too. So that is a bit weird.
>
> On of the things that surprised me was that the commands where send 
> using the send_byte command that actually tried to set the RS signal. 
> (which should only be done for data) This is the strange thing. 
> parallel port code does the same. I guess it has to do with the copy 
> of the source code that I got from the web-site.
>
> The second problem was that the SIGNAL_ENABLE, SIGNAL_RS and SIGNAL_RW 
> were never set correctly. I did it manually now. But how should it be 
> done?
>
> And that's it! Good work Luis! You were nearly there!
> So, if anyone can tell me what I should do to get this stuff in the 
> official code?
>
> cheers,
>
> Paul

Send me the code you've got in a private mail, so that I can take a good 
look at it.
Maybe I can commit it if it looks good enough.

cheers!

Luis

2004	Jan (57)	Feb (71)	Mar (80)	Apr (40)	May (49)	Jun (20)	Jul (3)	Aug (9)	Sep (8)	Oct (2)	Nov	Dec (11)
2005	Jan (10)	Feb (25)	Mar (24)	Apr (26)	May (71)	Jun (35)	Jul (5)	Aug (3)	Sep (18)	Oct (4)	Nov (5)	Dec (2)
2006	Jan (50)	Feb (12)	Mar (7)	Apr (24)	May (1)	Jun (17)	Jul (51)	Aug (38)	Sep (38)	Oct (33)	Nov (8)	Dec (13)
2007	Jan (44)	Feb (25)	Mar (21)	Apr (68)	May (52)	Jun (24)	Jul (17)	Aug (12)	Sep (4)	Oct (14)	Nov (1)	Dec (3)
2008	Jan (9)	Feb (1)	Mar	Apr (5)	May	Jun	Jul (1)	Aug (1)	Sep (5)	Oct (5)	Nov (1)	Dec
2009	Jan (4)	Feb	Mar (2)	Apr (1)	May (21)	Jun (5)	Jul	Aug	Sep (4)	Oct (1)	Nov	Dec
2010	Jan (15)	Feb (36)	Mar (1)	Apr	May	Jun (2)	Jul (3)	Aug	Sep (2)	Oct	Nov (1)	Dec (3)
2011	Jan (22)	Feb (2)	Mar (2)	Apr (1)	May (2)	Jun	Jul (25)	Aug	Sep	Oct	Nov	Dec (4)
2012	Jan (14)	Feb (6)	Mar (20)	Apr (12)	May	Jun (1)	Jul	Aug	Sep (1)	Oct (2)	Nov (2)	Dec
2013	Jan	Feb (3)	Mar (2)	Apr (1)	May (9)	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec (1)
2014	Jan (1)	Feb (1)	Mar (3)	Apr (2)	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar (5)	Apr	May	Jun (11)	Jul (1)	Aug (3)	Sep	Oct	Nov (1)	Dec
2016	Jan (2)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2018	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

lcd4linux-devel Mailing List for lcd4linux (Page 36)

lcd4linux-devel — lcd4linux development team