LCDproc development and user support list

Text archives Help

[Lcdproc] CwLnx display corruption - possible cause and fix

Chronological Thread 
  • From: dplatt AT (Dave Platt)
  • Subject: [Lcdproc] CwLnx display corruption - possible cause and fix
  • Date: Mon Apr 30 19:53:02 2007

> So the init part of the driver just sends the command to set the display to
> the speed that LCDd wants it to be, a single operation rather than two.
> Your sending the opposite of the config then the config shouldn't be
> reliable in all cases if the commands are mis-interpreted when sent at the
> wrong (for the hardware) speed. You're making the false assumption that the
> hardware is not matching the config when it may well be.
> As the set/reset method *is* reliable it indicates that speed change
> commands sent at the "wrong" speed are interpreted correctly so you may as
> well just send the one the config calls for... Indeed they pretty much have
> to be interpreted correctly otherwise how does any application set up the
> device how it wants it? Catch 22...
> It is never safe to assume the state of any hardware, if a particular state
> is required it must be explicitly configured.

I agree with you - there is a definite Catch 22 involved with this device.
As far as I can tell, this is just something that's built into the device
design. Or, at least, if there is a way out of the Catch 22, it's not
explicitly documented in the data sheet.

The initialization architecture which was in the driver when I started working
with it, *did* do the "wrong thing" right out of the box... that is,
if you run it right after power-up (when the device is configured at
19200), the first thing it does is send commands at 9600 bits/second.

You may be right, in that it's possible that the device might be
capable of recognizing a change-speed command sent at the "wrong speed"
(e.g. at 9600 when it's configured at 19200) under some circumstances.
Perhaps that's one of the effects of sending a long-space - it may
"prime" the device to be able to recognize a change-speed command
sent at the wrong baud rate. Once again, this isn't documented at
all in the data sheet - long-space/break/framing-error isn't mentioned

I'll try this out in the next day or so... I'll have the driver
configure the Linux port for the correct speed, send a long-space,
send the correct speed-change command to the device, drain, delay,
and then long-space again. If a prolonged test cycle shows that
this works as well as the "wrong speed" approach my current patch
uses, then I'll update my patch. Doing the set-speed operation at
the "right speed" is certainly cleaner, if it actually works

Archive powered by MHonArc 2.6.18.

Top of page