lcd4linux-devel — lcd4linux development team

[Lcd4linux-devel] RE: [lcd4linux] problem with i2c connected LCD display

[Luis.F.Correia <Lui...@se...>]

Hi!

> -----Original Message-----
> From: paul kamphuis [mailto:pau...@xs...] 
> Sent: Wednesday, February 09, 2005 2:50 PM
> To: Luis.F.Correia
> Subject: Re: [lcd4linux] problem with i2c connected LCD display
> 
> Thanks for the reply,
> I am not sure if I am supposed to reply directly, or keep the 
> messages 
> going through the list.

Well, you should reply always to the list. 
We get searchable archives that way...

> Can you give me a reason on why it would be so slow. It is 
> obvious that 
> it is slower then parallel port. But I used the same i2c connected 
> display on a 20 MHz microcontroller without a problem.

The hardware I have is a WRAP board, and it's interface runs with 3.3V,
it may be a problem for me, because I had to make a 3.3-5 adaptor.

Anyway, the amount of data lcd4linux produces needs an interface
fast enough to process it. I was unable to get a usable interface.

> 
> I am willing to give it a shot, if you are prepared to 
> provide me with 
> some assistance on where to start and how to start. It would 
> be my first 
> effort on writing code on linux.

No problem, I'm not really a C expert but at least I can help you
to follow the 'good line'. :)

> 
> Paul
> 

Luis

Re: [Lcd4linux-devel] nexcom nsa1045

[Michael R. <re...@eu...>]

Hi Georg,

> your wrote on the (sourceforge) homepage about upcoming support for the 
> nexcom blade ( 2004-09-18)
> 
> and that it is running with an adopted HD44780 driver.
> 
> What have I to change/to do to get the display running (incl keypad 
> would be perfect?

Well, the lcd is supported with LCD4Linux-0.10.0-RC1, which can be found 
on the sourceforge download page. Please consider that the homepage on 
sourceforge is outdated, please visit http://lcd4linux.bulix.org.

The keypad is basically supported: Keys are polled, and there's a debug 
output if a key was pressed or released, but still no handler for such 
events in lcd4linux. But this will change soon.


If you have any additional questions, feel free to ask!

bye, Michael

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

[Lcd4linux-devel] nexcom nsa1045

[Georg K. <g.k...@ba...>]

Dear lcd4linux Team,
=20
your wrote on the (sourceforge) homepage about upcoming support for the
nexcom blade (2004-09-18)
and that it is running with an adopted HD44780 driver.
What have I to change/to do to get the display running (incl keypad
would be perfect?
=20
Tip: From nexcom I got following link concerning nexcom LCDs:=20
 <http://linux.exosec.net/> http://linux.exosec.net/
=20
=20
kind regards,
many thanks in advance
=20
Georg Kaefer
backbone internet service GmbH=20
=20

Re: [Lcd4linux-devel] Small changes in sample-config?

[Michael R. <re...@eu...>]

Hi Andreas,

>>Thanks.. but could you please test the examples? I'm not shure about the 
>>"UsBusy 1" which activates busy-flag checking (which should give you a 
>>performance gain)

> Hmmm... UseBusy 1 works. I cant realize a performance gain and i dunno
> how to check it out. How can i find out? With -vvv it prints
> out "using busy-flag checking". But a performance gain? Hmmmm... Hard
> to find out. The update-speed seems to be a lil more faster, but it could
> be false.

Well, 'performance gain' may be the wrong word. Especially on slower 
machines, you should see a much lower cpu usage of lcd4linux. You could 
simulate this by lowering all ethe update intervals, so all display 
updates are done very often.


bye, Michael

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

RE: [Lcd4linux-devel] Small changes in sample-config?

[<An...@t-...>]

>Subject: Re: [Lcd4linux-devel] Small changes in sample-config?
>
>Hi Andreas,
>
>> thank you for putting it in. Its much more better than my
>> suggestion...
>
>Thanks.. but could you please test the examples? I'm not shure about the 
>"UsBusy 1" which activates busy-flag checking (which should give you a 
>performance gain)
>
>bye, Michael

Hmmm... UseBusy 1 works. I cant realize a performance gain and i dunno
how to check it out. How can i find out? With -vvv it prints
out "using busy-flag checking". But a performance gain? Hmmmm... Hard
to find out. The update-speed seems to be a lil more faster, but it could
be false.

Regards,
Andreas

Re: [Lcd4linux-devel] Wiki/Trac

[Javi <ja...@gs...>]

=2D----- El Jueves, 6 de Enero de 2005 17:16, Michael Reinelt escribi=F3: -=
=2D----
 > I've set up a Subversion repository[1] and a Trac environment for
 > LCD4Linux. You can access the LCD4Linux wiki/website at
 > http://lcd4linux.bulix.org


Hello list.

I've submitted some documentation into de wiki page for 'MySQL plugin' and =
'POP3 pluging'.
I would appreciated if someone can read/correct it because my english is ve=
ry poor and there may be
lots of mistakes ;-)

Rgds.

Javi.

Re: [Lcd4linux-devel] Small changes in sample-config?

[Michael R. <re...@eu...>]

Hi Andreas,

> thank you for putting it in. Its much more better than my
> suggestion...

Thanks.. but could you please test the examples? I'm not shure about the 
"UsBusy 1" which activates busy-flag checking (which should give you a 
performance gain)

bye, Michael

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

RE: [Lcd4linux-devel] Small changes in sample-config?

[<An...@t-...>]

Hi Michael,

thank you for putting it in. Its much more better than my
suggestion...

Thanks,
Andreas

-----Original Message-----
From: lcd...@li...
Subject: Re: [Lcd4linux-devel] Small changes in sample-config?


Hi Andreas,

> It took me a while to find that all out. Esp. the
> Model-Number is a nice hint. I forgot that the
> second time now.

Thanks for pointing this out. I changed the lcd4linux.conf.sample and 
added three sample sections for HD44780, following your suggestions. I 
added these sections to the wiki, too.


bye, Michael

Re: [Lcd4linux-devel] Small changes in sample-config?

[Michael R. <re...@eu...>]

Hi Andreas,

> It took me a while to find that all out. Esp. the
> Model-Number is a nice hint. I forgot that the
> second time now.

Thanks for pointing this out. I changed the lcd4linux.conf.sample and 
added three sample sections for HD44780, following your suggestions. I 
added these sections to the wiki, too.


bye, Michael

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

[Lcd4linux-devel] Small changes in sample-config?

[<An...@t-...>]

Hi All!

It took me a while to find that all out. Esp. the
Model-Number is a nice hint. I forgot that the
second time now.

May we want change this passage of the config-file:

(...)
Display HD44780-20x4 {
    Driver 'HD44780'
    Port '/dev/parports/0'	
#   Port '0x378'
    Bits '8'
    Size '20x4'
    asc255bug 0
    Icons 1
    Wire {
	RW     'GND'
	RS     'AUTOFD'
	ENABLE 'STROBE'
	GPO    'INIT'
    }
}
(...)

Into this passage:

(...)
Display HD44780-20x4 {
    Driver 'HD44780'
### For Display (kernelconcept.de) :
#   Model 'HD66712'
    Port '/dev/parports/0'	
#   Port '0x378'
    Bits '8'
    Size '20x4'
    asc255bug 0
    Icons 1
    Wire {
	RW     'GND'
	RS     'AUTOFD'
	ENABLE 'STROBE'
	GPO    'INIT'
    }
### WinAmp - Wiring used by display
### from kernelconcept.de
#    Wire {
#	 RW	  'AUTOFD'
#	 RS	  'INIT'
#	 ENABLE 'STROBE'
#	 GPO	  'GND'
#   }
}
(...)

?

Sure, not the best place to explain. But it helps a bit. 
I dunno how i should name the displays from that
company.

Dunno if you want it. =)

Andreas

Re: [Lcd4linux-devel] Wiki/Trac

[Michael R. <re...@eu...>]

Hi Sam,

> I've set up a Subversion repository[1] and a Trac environment for
> LCD4Linux. You can access the LCD4Linux wiki/website at
> http://lcd4linux.bulix.org

Well, this looks absolutely cool! I really love it!

> I've started gathering some information from the original LCD4Linux
> website (at SF) and putting them into the new Wiki, as examples. I'll
> let you do the other pages.
Great, thanks! I will look for a wiki crash course, and try to start 
some pages.

> I've also created (still for examples) the upcoming 0.10 milestone,
> and a ticket for this milestone (concerning the documentation needs).
Hmm, at the moment I'm not going to look into this, as I'm very short of 
time (as you may have noticed :-) Just finished spellforce, and my 
real-life job got me again :-(

> In order to complete this setup, I need to know who are the authorized
> users (both for source commits and for Trac administration), and a
> password for each of them. For the moment, only me as the
> administration rights, so that's not very good :)
But I tried to modify some of the content, looks like this worked?

As for the users, is this authorization needed for Wiki editing, or for 
other stuff?

I will send you my username and a password with PM. All other lcd4linux 
developers who are interested in working with this stuff should do so, too!


bye, and thanks again, Michael

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

Re: [Lcd4linux-devel] Wiki/Trac

[Maxime P. <max...@bu...>]

Hi,

> I think we should accept Maxime's invitation and put the wiki there
> first, then migrate slowly the rest (maybe use the tracker for bug
> reports, then when releasing final 0.10 move to SVN ...).
> It would be too much work to set up a wiki at SF, then migrate it to
> trac.

I've set up a Subversion repository[1] and a Trac environment for
LCD4Linux. You can access the LCD4Linux wiki/website at
http://lcd4linux.bulix.org

I've started gathering some information from the original LCD4Linux
website (at SF) and putting them into the new Wiki, as examples. I'll
let you do the other pages.

I've also created (still for examples) the upcoming 0.10 milestone,
and a ticket for this milestone (concerning the documentation needs).

In order to complete this setup, I need to know who are the authorized
users (both for source commits and for Trac administration), and a
password for each of them. For the moment, only me as the
administration rights, so that's not very good :)

We will discuss about the source tree migration later.

> Maxime : I really thank you to help us. If you can't afford giving time
> for the project, please let me know and we'll discuss about it.

I'm currently on holidays, so there's no problem about it.
Enjoy !

- Sam

--=20
/ Maxime Petazzoni - <max...@bu...> - bulix.org |
| Zwe (zwe.bulix.org) - TracTux (https://tractux.bulix.org)   |
| Gpg Id: 0x83E6AE0D  - Jabber: sa...@ja... ________________/

Re: [Lcd4linux-devel] Wiki/Trac

[Xavier V. <xav...@fr...>]

Hello Michael, Maxime and the others

> Thanks for your mail and your explanations. This sounds great (although
> I didn't find the time to have a closer look, for a simple reason: Got
> Spellforce: Shadow of Phoenix as a cristmas present :-(
Oh no, he got Spellforce-addict once more :)

> For we didn't even start writing/changing docs for 0.10, going for a 
> wiki seems the right decision at this point. Changing other things 
> (project management, tickets, source code management) seems not (at 
> least to me; as always YMMV). But we should think about this later!
> So for the moment, I sugest the following:
> (...)
> What do you think?
I think we should accept Maxime's invitation and put the wiki there
first, then migrate slowly the rest (maybe use the tracker for bug
reports, then when releasing final 0.10 move to SVN ...).
It would be too much work to set up a wiki at SF, then migrate it to
trac.

As always, your wish is my command, but I think trac is excellent and I
really suggest to migrate to it when we can :
- we have to change the website : migrate the website to trac's wiki
- we need good bug reporting : use trac's one
- ....
For the moment, I understand that a total migration may look crasy, so
let's go for a partial migration today.

Bye !
PS : From tomorrow to Monday, I'm in Spain so I probably won't be able
to answer. I think Maxime is more able than me to help the migration to
the wiki, and I have full confidence in him.

Maxime : I really thank you to help us. If you can't afford giving time
for the project, please let me know and we'll discuss about it.
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] Wiki/Trac

[Michael R. <re...@eu...>]

Hi List, Maxime,

Thanks for your mail and your explanations. This sounds great (although
I didn't find the time to have a closer look, for a simple reason: Got
Spellforce: Shadow of Phoenix as a cristmas present :-(

As I wrote in another mail, we *have to* release 0.10 aka CVS. The code 
is stable for half a year now, the only reason for not releasing it is 
the lack of documentation (the internals of lcd4linux changed a lot, and 
therefore the current docs are completely out of date). And we have to 
implement some of the features 0.9.11 had and 0.10 lacks (GPIO support, 
virtual screens/scrolling and so on...)

For we didn't even start writing/changing docs for 0.10, going for a 
wiki seems the right decision at this point. Changing other things 
(project management, tickets, source code management) seems not (at 
least to me; as always YMMV). But we should think about this later!

So for the moment, I sugest the following:

- leave the SourceForge stuff as is, CVS, mailing lists, trackers, web 
pages, ...

- set up a wiki page for lcd4linux 0.10 documentation

- place some links on the SourceForge web site to the wiki

- write docs for 0.10 within the new wiki

- release 0.10.0

- release 0.10.1

- think about life, the universe, and everything....


What do you think?


bye, Michael

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

Re: [Lcd4linux-devel] Wiki/Trac

[Michael R. <re...@eu...>]

Hi there,

>>On the other hand, SF CVS servers are not known to be reliable and I
>>won't be bothered to switch to somethinkg else ...
> 
> Hehe, you're right. But don't forget that Svn is pretty different from
> CVS, and there will be some re-education to be done for all
> developpers. You can read more and start learning using the Subversion
> Book[2].

You are right, SVN is probably a lot better that CVS. I already thought 
about switching to SVN.

But my/our primary goal is to get 0.10 out to the public. Changing 
source code management infrastructure at this point is Not The Right 
Thing (tm).

Let's stay with SF CVS for the time being, let 0.10 become stable, and 
then switch to SVN.


bye, Michael

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

Re: [Lcd4linux-devel] Wiki/Trac

[Xavier V. <xav...@fr...>]

I found a tool called cvs2svn ( http://cvs2svn.tigris.org/cvs2svn.html )
which can help us to migrate the CVS content to a new subversion
repository.

-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] Wiki/Trac

[Xavier V. <xav...@fr...>]

> > On the other hand, SF CVS servers are not known to be reliable and I
> > won't be bothered to switch to somethinkg else ...
> Hehe, you're right. But don't forget that Svn is pretty different from
> CVS, and there will be some re-education to be done for all
> developpers. You can read more and start learning using the Subversion
> Book[2].
As for myself, I just had two little scripts to update and commit with
commands taken from some SF doc and never really cared about how it
worked. So if migrating to subversion is just changing these scripts, it
won't be difficult :p
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] Wiki/Trac

[Maxime P. <max...@bu...>]

Hi Xavier,

> One question, is it possible for guests to modify pages, or must one
> be authentified ? It could be usefull to let some pages within full
> access.

> Moreover, are there some ACL implemented ? I mean is it possible to
> create a "documentation" group which could only modify pages related
> to doc ? (maybe not useful for us, but worth knowing)

Trac currently implements basic permission management. You can
restrict the wiki edition (and a lot of others features) to
authenticated users (or a specific user) only. I suggest you read the
Trac permissions documentation[1]. In the future, Trac will support
per-page ACL.

> On the other hand, SF CVS servers are not known to be reliable and I
> won't be bothered to switch to somethinkg else ...

Hehe, you're right. But don't forget that Svn is pretty different from
CVS, and there will be some re-education to be done for all
developpers. You can read more and start learning using the Subversion
Book[2].

- Sam

[1] http://projects.edgewall.com/trac/wiki/TracPermissions
[2] http://svnbook.red-bean.com/
--
/ Maxime Petazzoni - <max...@bu...> - bulix.org |
| Zwe (zwe.bulix.org) - TracTux (https://tractux.bulix.org)   |
| Gpg Id: 0x83E6AE0D  - Jabber: sa...@ja... ________________/

Re: [Lcd4linux-devel] Wiki/Trac

[Xavier V. <xav...@fr...>]

Le mardi 28 d=E9cembre 2004 =E0 12:43 +0100, Maxime Petazzoni a =E9crit :

> In your situation (and considering the mail entitled 'lcd4linux wiki'
> from Michael, sent 2004-12-12 on this list), I see a couple of
> advantages.
> First of all, Trac is a Wiki. It will allow you to build a full
> website quickly, and it will provide a excellent documentation support
> (one of your requirements was that each contributor could maintain it's
> plugin documentation. This will be possible).
One question, is it possible for guests to modify pages, or must one be
authentified ?
It could be usefull to let some pages within full access.

Moreover, are there some ACL implemented ? I mean is it possible to
create a "documentation" group which could only modify pages related to
doc ? (maybe not useful for us, but worth knowing)

> Next, Trac provides a Roadmap system. It list incoming milestones with
> descriptions. Tickets (I'll tell more on them later) targeted for a
> specific milestone are aggregated, and the ratio between active and
> resolved tickets is displayed as a milestone progress bar.
> A Timeline let you know of almost everything new on the project :
> commits, page edits, tickets creations/closings, etc.
> Finally, the tickets. Trac tickets are the bugtracking system. By
> specifying some key information in the tickets (milestone, severity,
> priority, ...), Trac is able to build sorted tickets list (by
> milestone, by priority, ...).
I saw it for zwe, it's excellent :p

> The only drawback I see in this migration is that Trac is based on
> Subversion. I can host the related Subversion repository without any
> problem, but if you are currently hosted by SF, it meens that you are
> using CVS. But considering the migration would be
> interesting. Subversion[4] is a more powerfull tool than CVS, and the
> import from CVS is possible.
On the other hand, SF CVS servers are not known to be reliable and I
won't be bothered to switch to somethinkg else ...

Bye !
--=20
Xavier VELLO <xav...@fr...>

[Lcd4linux-devel] Wiki/Trac

[Maxime P. <max...@bu...>]

Lcd4linux developpers, Michael,

As you can probably guess from the preceding mail by Xavier, I'm
posting here to present a solution to your Wiki and Bugtracking needs.

The solution i'm bringing to you today is based on a wonderful tool
called Trac[1]. It's a web-based software project management
system. Trac relies on Python, Sqlite and Subversion.

In your situation (and considering the mail entitled 'lcd4linux wiki'
=66rom Michael, sent 2004-12-12 on this list), I see a couple of
advantages.
First of all, Trac is a Wiki. It will allow you to build a full
website quickly, and it will provide a excellent documentation support
(one of your requirements was that each contributor could maintain it's
plugin documentation. This will be possible).
Next, Trac provides a Roadmap system. It list incoming milestones with
descriptions. Tickets (I'll tell more on them later) targeted for a
specific milestone are aggregated, and the ratio between active and
resolved tickets is displayed as a milestone progress bar.
A Timeline let you know of almost everything new on the project :
commits, page edits, tickets creations/closings, etc.
Finally, the tickets. Trac tickets are the bugtracking system. By
specifying some key information in the tickets (milestone, severity,
priority, ...), Trac is able to build sorted tickets list (by
milestone, by priority, ...).

I'm hosting a demo[2] Trac environment. You can login as trac admin using
demo/demo. Feel free to test all the features. You can also check an
active Trac environment, with milestones and tickets filled on the
Zwe[3] webpage.

The only drawback I see in this migration is that Trac is based on
Subversion. I can host the related Subversion repository without any
problem, but if you are currently hosted by SF, it meens that you are
using CVS. But considering the migration would be
interesting. Subversion[4] is a more powerfull tool than CVS, and the
import from CVS is possible.

I don't have a very good upload speed (128kbits/s), but I have a very
good connection uptime. I can also provide other kind of hostings if
you need : DNS/Mail/SSH/Web/MySQL/additional svn repos/..., just ask and it=
 can be done in the
next 5 minutes :P

Here it is. Enjoy-

Regards,
- Sam

[1] Trac: http://projects.edgewall.com/trac
[2] Demo: https://ssl.bulix.org/projects/demo
[3] Zwe : https://ssl.bulix.org/projects/zwe
[4] Svn : http://subversion.tigris.org

For information, the box that provides the hosting is my personnal
server, running for bulix.org. It runs Debian 3.1. You can take a look
at the hardware at https://ssl.bulix.org/phpsysinfo. As this box host
my $HOME via NFS, I just can't let it fall.

--=20
/ Maxime Petazzoni - <max...@bu...> - bulix.org |
| Zwe (zwe.bulix.org) - TracTux (https://tractux.bulix.org)   |
| Gpg Id: 0x83E6AE0D  - Jabber: sa...@ja... ________________/

[Lcd4linux-devel] Little xmas gifts for lcd'linux developpers

[Xavier V. <ge...@gm...>]

Hello everybody !
I just got 10 invitations to gmail to distribute. If someone wants
one, just send me a mail :p

Michael : About the wiki, I talked with Maxime about trac and this
would be a good choice, but we would have to move the website to his
server to use it. But we can make a redirection from lcd4linux.sf.net
to the new place. He should have written to you about trac.

Bye !

[Lcd4linux-devel] lcd4linux wiki

[Michael R. <re...@eu...>]

Hi there,

As there is some ... erhm... stagnation in writing documentation for 
lcd4linux, a new idea came to my mind today: Why not make the 
documentation/manual a wikiwiki page?

I see a lot of advantages:

- editing is easy
- each author can keep his documentation up to date (think of the plugins!)
- users can add hints/corrections/whatever to the wiki
- users can add configurations/photos and stuff

But there are several questions, too:
- should the whole lcd4linux website be a wiki, or just parts of it?
- where should it be hosted? (SourceForge does not provide a wiki, AFAIK)

the code for 0.10 seems to be quite stable, and is ready for release for 
months now (at least as a release candidate). I refused to release 
because of the lack of documentation. But I *really* want to bring it 
out to the public...


Comments are welcome!

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

Re: [Lcd4linux-devel] HD44780 changes

[Michael R. <re...@eu...>]

Hi Luis,

> Ok, here it goes my first try to support I2C:
> This is a huge mess, because i'm working on a CVS version of some weeks 
> ago.
> Since the functions were empty, I think i'm not stepping on anyone's toes.

I tried to apply your "patch", it worked, but it does not compile. I'm 
afraid there's a problem with the i2c.h include.

That's what I get when I do a make:

gcc -DHAVE_CONFIG_H -I. -I. -I.    -I/usr/X11R6/include -D_GNU_SOURCE 
-Wall -W -g -O2 -c drv_HD44780.c
In file included from /usr/include/linux/sched.h:12,
                  from /usr/include/linux/module.h:10,
                  from /usr/include/linux/i2c.h:31,
                  from drv_HD44780.c:216:
/usr/include/linux/jiffies.h:16: error: parse error before "jiffies_64"
/usr/include/linux/jiffies.h:20: error: parse error before "get_jiffies_64"
In file included from /usr/include/linux/cpumask.h:8,
                  from /usr/include/linux/sched.h:15,
                  from /usr/include/linux/module.h:10,
                  from /usr/include/linux/i2c.h:31,
                  from drv_HD44780.c:216:
/usr/include/linux/bitmap.h: In function `bitmap_empty':
/usr/include/linux/bitmap.h:15: error: `BITS_PER_LONG' undeclared (first 
use in this function)
/usr/include/linux/bitmap.h:15: error: (Each undeclared identifier is 
reported only once
/usr/include/linux/bitmap.h:15: error: for each function it appears in.)

and so on...

The first error is a missing "u64" declaration, which is defined in 
asm/types.h, but only if the symbol __KERNEL__ is defined (which is not 
in a userspace program)

I commented out all failing sections in the driver with a #if 0, and 
checked in the driver. Maybe you want to have a look at it, and find out 
how to make it compile cleanly.

bye, Michael


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

Re: [Lcd4linux-devel] HD44780 changes

[Luis C. <lfc...@lf...>]

Luis.F.Correia wrote:

>Hi List, especially Luis,
>
>I just checked in a new version of drv_HD44780.c. I did some code 
>cleanups, and separated the parport specific stuff from the display 
>specific stuff, and already wrote a framework for other 'busses'. There 
>is support for a keyword 'bus' in the display section of lcd4linux.conf, 
>which can be 'parport (default) or 'i2c'. There are already skeleton 
>functions for I2C access.
>
>So Luis can start filling these skeletion functions!
>
>But take care, I'm currently working on the HD44780 driver, too! So 
>update regularly!
>
>The reason on my side is that I got a Nexcom 19" blade server donated by 
>OpenSystems, which has a 16x2 display, and four keys.
>
>Yes, keys! I'm working on keypad support for lcd4linux.
>
>stay tuned!
>
>  
>
Ok, here it goes my first try to support I2C:
This is a huge mess, because i'm working on a CVS version of some weeks ago.
Since the functions were empty, I think i'm not stepping on anyone's toes.

This reads the following config variables:
    Port '/dev/i2c-0'
    Device '70'

and my config file looks like this:

Display HD44780-I2C {
    Driver 'HD44780'
    Model 'WRAP1C-PCF8574'
    Port '/dev/i2c-0'
    Device '70'
    Bus 'i2c'
    Bits '4'
    Size '20x4'
    asc255bug 0
    Icons 1
    Wire {
        RW     'DB5'
        RS     'DB4'
        ENABLE 'DB6'
        GPO    'GND'
    }
}


-------------------------------------
includes at the top of the file:
#include <linux/i2c.h>
#include <linux/i2c-dev.h>

global variable:
/* handle for I2C device*/
static int i2c_device;

Functions:

/****************************************/
/***  i2c dependant functions         ***/
/****************************************/


static void drv_HD_I2C_nibble (const unsigned char controller, const 
unsigned char nibble)
{
  /* clear ENABLE */
  /* put data on DB1..DB4 */
  /* nibble already contains RS bit! */
  i2c_smbus_write_byte_data(i2c_device, 0, nibble);

  /* Address set-up time */
  ndelay(T_AS);
 
  /* rise ENABLE */
  i2c_smbus_write_byte_data(i2c_device, 0, nibble | SIGNAL_ENABLE);
 
  /* Enable pulse width */
  ndelay(T_PW);

  /* lower ENABLE */
  i2c_smbus_write_byte_data(i2c_device, 0, nibble);

  /* Address hold time */
  ndelay(T_H);

}

static void drv_HD_I2C_byte (const unsigned char controller, const 
unsigned char data)
{
  /* send data with RS disabled */
  /* send high nibble of the data */
  drv_HD_I2C_nibble (controller, ((data>>4)&0x0f)|SIGNAL_RS);

  /* Make sure we honour T_CYCLE */
  ndelay(T_CYCLE-T_AS-T_PW);

  /* send low nibble of the data */
  drv_HD_I2C_nibble(controller, (data&0x0f)|SIGNAL_RS);
}

static void drv_HD_I2C_command (const unsigned char controller, const 
unsigned char cmd, const int delay)
{
  /* send data with RS disabled */
  drv_HD_I2C_byte (controller, cmd);
 
  /* wait for command completion */
  udelay(delay);
}

static void drv_HD_I2C_data (const unsigned char controller, const char 
*string, const int len, const int delay)
{
  int l = len;
 
  /* sanity check */
  if (len<=0) return;
 
  while (l--) {
    /* send data with RS enabled */
    drv_HD_I2C_byte (controller, *(string++));
     
    /* wait for command completion */
    udelay(delay);
  }
}

static int drv_HD_I2C_load (const char *section)
{
    int dev;
    char *bus,*device;

    bus    =cfg_get(section, "Port", NULL);   
    device =cfg_get(section, "Device", NULL);   
    dev    =0x70;

    info("%s: initializing I2C bus %s",Name,bus);
    if ((i2c_device = open(bus,O_RDWR)) < 0)
    {
      error("%s: I2C bus %s open failed !\n",Name,bus);
      return -1;
    }

    info("%s: initializing I2C slave device 0x%x",Name,dev);
    if (ioctl(i2c_device,I2C_SLAVE, (dev>>1) ) < 0)
    {
        error("%s: error initializing device 0x%x\n",Name,dev);
        close(i2c_device);
        return -1;
    }

    info("%s: detecting I2C device 0x%x on bus %s ",Name,dev,bus);
    if (i2c_smbus_write_quick(i2c_device,I2C_SMBUS_WRITE) < 0)
    {
        error("%s: i2c slave-device 0x%x not found!\n",Name,dev);
        close(i2c_device);
        return -1;
    }

    if (cfg_number(section, "Bits", 8, 4, 8, &Bits)<0) return -1;
    if (Bits!=4) {
    error ("%s: bad %s.Bits '%d' from %s, should be '4' ", Name, 
section, Bits, cfg_source());
    return -1;
    }   
 
    info ("%s: using %d bit mode", Name, Bits);
 
  /* initialize *both* displays */
    drv_HD_I2C_nibble  (allControllers, 0x03); udelay(T_INIT1); /* 4 Bit 
mode, wait 4.1 ms */
    drv_HD_I2C_nibble  (allControllers, 0x03); udelay(T_INIT2); /* 4 Bit 
mode, wait 100 us */
    drv_HD_I2C_nibble  (allControllers, 0x03); udelay(T_INIT1); /* 4 Bit 
mode, wait 4.1 ms */
    drv_HD_I2C_nibble  (allControllers, 0x02); udelay(T_INIT2); /* 4 Bit 
mode, wait 100 us */
    drv_HD_I2C_command (allControllers, 0x28, T_EXEC);           /* 4 
Bit mode, 1/16 duty cycle, 5x8 font */

    info("%s: I2C initialization done", Name);

  return 0;
}


static void drv_HD_I2C_stop (void)
{
  /* clear all signals */
  // drv_generic_i2c_data (0);
  /* close port */
  // drv_generic_i2c_close();

    close(i2c_device);
}
-------------------------------------

Michael, please feel free to redirect that SCUD missile you have to my 
email address :)

Cheers!

Luis Correia

Re: [Lcd4linux-devel] I can't actively work for l4l anymore by now

[<xav...@fr...>]

Hello all !

> Somehow your mail has been cut off.
>
> Anyway, that's bad news! But I'm looking forward to welcome you back in
> october/november.

Sorry, I tried to post from my phone with a WML webmail, but it seems to =
cut the
messages :/

In fact, I'm in Toulouse for my "pr=E9pa" and will only return in Perpign=
an the
last week of october, but just for a week, and then go back to Toulouse,
without any linuxbox :(
So I won't be very active in the project (or any computing project).

If you plan releasing 0.1.10 soon, and find bugs in my code, feel free to=
 modify
it without expecting me to reply. About the documentation, if you like my=
 doc
system but can't understand how it works, just write the doc in plain tex=
t, and
I'll markup it during my holidays.

Bye all !

PS: It's not a definitive goodbye. I really like this project and will sp=
end a
lot of time on it during my holidays. I'm not planning letting you down, =
but I
don't have time to geek during the prepa.