lcd4linux-users

[lcd4linux] Lcd4Linux - comments and code

[Simon W. <Sim...@pa...>]

Hello all,
I've just been having a play with Lcd4Linux and have some comments....

Am I correct (from a very quick scan of the code) that the system relies on 'Flushing' the whole display for each frame, rather than only updating the areas of the screen that actually need updating??? How does implementing a 'dirty' flag (or something), or would this interfere with your clever use of the user defined characters for the bar graphs...

Is there an archive of the mailing list somewhere?

I'd like to adopt a LCD project for a MP3 player I'm putting together (I've seen LCD Proc but the screen update is too slow), what do you guys think about adjusting the code to read form a keypad???

Finally, never go to a party empty handed.
Here's a fix for HD44780.c (from 0.97) to get it displaying correctly on 20x4 (tested) and 16x4 (not tested):
---- code ------
void HD_goto (int row, int col)
{
  int pos;

  pos=(row%2)*64+col;

  /* Cope with 16 or 20 cols */
  if (row>1) pos+= Lcd.cols;

  HD_command (0x80|pos, 40);
}
---- end code -----

cheers,
Simon Wood

Hardware Engineer 
Pace Micro Technology plc
Victoria Road, Saltaire, Shipley
West Yorkshire, BD18 3LF
Tel : +44(0)1274 532000  Fax: +44(0)1274 532029

This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.

Re: [lcd4linux] Lcd4Linux - comments and code

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

Hi Simon,

Simon Wood wrote:
> 
> Am I correct (from a very quick scan of the code) that the system relies on 'Flushing' the whole display for each frame, rather than only updating the areas of the screen that actually need updating??? How does implementing a 'dirty' flag (or something), or would this interfere with your clever use of the user defined characters for the bar graphs...

you should tell your mailer to wrap long lines :-)

yes, you're right, we're flushing the whole display. As far as I know,
there have been no problems with this by now. The largest display I've
seen so far is 20x4, which makes 80 characters. If we'd implement a
dirty detection, we'd have to send a lot of positioning codes, a few
bytes each. I don't think this would save us a lot of bandwith.

There is a big advantage, too: if for some reason (overload, cable
disconnect, ...) one or more characters get lost, the will be redrawn
the next time.

The X11-driver does update modified areas only, and so will do a driver
for graphics displays (maybe there will be one in the future, and it
will support color, too.)


> Is there an archive of the mailing list somewhere?

Yes, there is. look at SourceForge. But it's a very low-traffic list, so
the archives are quite small...

> I'd like to adopt a LCD project for a MP3 player I'm putting together (I've seen LCD Proc but the screen update is too slow), what do you guys think about adjusting the code to read form a keypad???

I'm not shure about this. lcd4linux is designed following the KISS
approach (keep it small and simple), and I think it should stay this
way.

the serial driver is designed as a output-only device. which makes the
code much simpler. 

If we would parse a keypad - what should we do with the input? How code
it in the config file? A lot of questions....

Maybe lcdproc would better fit your needs in this case. I don't want to
be a replacement for lcdproc, but an alternative.

> Finally, never go to a party empty handed.
> Here's a fix for HD44780.c (from 0.97) to get it displaying correctly on 20x4 (tested) and 16x4 (not tested):

Thanks a lot, but this has been fixed in the CVS some time ago.

bye, Michael

-- 
netWorks       	                                  Vox: +43 316  692396
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4					  GSM: +43 676 3079941
A-8045 Graz, Austria			      e-mail: re...@eu...