RE: [lcd4linux] Lcd4Linux - comments and code

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

see below

> -----Original Message-----
> From:	Michael Reinelt [SMTP:re...@eu...]
> Sent:	Thursday, January 18, 2001 4:56 PM
> To:	Simon Wood
> Cc:	'lcd...@li...'
> Subject:	Re: [lcd4linux] Lcd4Linux - comments and code
> 
> 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.
	[Simon Wood]  
	You have a goto at the start of each line anyhow. I need to get my head around what goes on the flush, but it looks like it makes some attempt to not write to a line that hasn't change.

	The largest display you can have with a single HD44780 is 2x40, above that you need to have 2 HD's and therefore either 2 strobes or some extra addressing logic.

	Good info page at:
	http://www.delta-components.de/suchbaum/LCDappNotes/iii.htm

> 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.
	[Simon Wood]  
	To cope with cable disconnection you would have to handle re-initialisation, and that would be really messy/tricky.

	Its seems to grab a fair amount of processor time (up 5% odd on my work machine), I'll see how my (really) crappy machine at home copes.

> > 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.
	[Simon Wood]  
	I agree with the KISS pricinple, I'll keep looking around but the speed of your screen update is appealing.......

> Thanks a lot, but this has been fixed in the CVS some time ago.
	[Simon Wood]  
	OK found that, but it looks like it will only work for the 4x20, and not the 4x16. The change is obvious.....

	Not so obvious is how to handle the 1x16 which has an address change mid line. I guess that no one is using this or they would have complained already.....

	[Simon Wood]  
	I've looked at more detail at the config file and I note that the length of the tokens (when not printed out in bar form) is not configurable. In fact different types seem to output different amounts of right justified values. It may be nice to clarify this is the documentation.

	Happy hacking,
	Simon W.