LCDproc development and user support list

Text archives Help


[Lcdproc] CwLnx display corruption - possible cause and fix


Chronological Thread 
  • From: dplatt AT radagast.org (Dave Platt)
  • Subject: [Lcdproc] CwLnx display corruption - possible cause and fix
  • Date: Tue May 1 06:19:01 2007

"Dave Liquorice"
<allsorts AT howhill.com>
wrote:

> 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.

Well, Dave, I gave it an honest good try to make it work in the way
that you proposed. And, I'm sorry to say, I can't make it function.
I wish I had, as doing things "the right way" would have been cleaner
and more satisfying.

All of my experiments this evening point to the same conclusion: if
the CwLinux device is configured for 19200 bit/second operation (as it
is when it's powered up), it doesn't seem to be able to recognize any
command (even a "change speed" command) sent at 9600 bits/second. It
just doesn't work. Sending a long-space beforehand, in an attempt to
reset the device or prod it into an autobaud mode, seems to have no
beneficial effect.

I share your distaste for sending commands to a device at the "wrong
speed", for fear of their being misinterpreted and causing the device
to sprout petunias from both ears and then PLING off to Tumbolia.

Unfortunately, with the CwLinux devices, doing this seems to be
inevitable if the driver is going to allow the user to select the
operation speed. There's no way to avoid it.

I've looked through the earlier version of the code, and it also can
and does send commands to the CwLinux at the "wrong speed", just as my
version does. Consider: at power-up, the CwLinux device initializes to
19200 bits/second. The older CwLinux driver configures the serial
port to this speed, sends a "change to 9600 bits/second" command,
sends a long-space, then reconfigures the PC serial port to 9600
bits/second and starts talking to the device. No speed mismatch so
far... all is good.

Now, reboot the system.

When LCDd starts up this time, the device is still at 9600
bits/second, as it hasn't been power-cycled. The CwLinux driver
configures the port for 19200, and sends a "Change to 9600
bits/second" command (which my experiments strongly suggest is not
recognized properly, as it's at the wrong speed)... so the device
stays at 9600 (and perhaps displays a bit of garbage from the garbled
command). Immediately thereafter, the driver resets the port to 9600,
long-spaces, and sends a "clear display" command... and everything
continues to work fine.

So... both the older code, and my own version, have a tendency to send
a "change speed" command to the device under conditions where the
device may not recognize it... because it's already at the speed at
which it's being told to switch. Based on my tests to date, this
seems to be non-harmful - I haven't been able to put the display into
any sort of wonky mode by running this test multiple times.

The only way that I can see to be completely "legal" in talking with
the device, is to remove support for 9600 bit/second operation from
the driver entirely, and never tell the device to change speeds. Even
this won't work 100% reliably - if another program changes the device
to 9600 before LCDd starts up, LCDd won't work with the device at all.

Or, I suppose we could add a driver shutdown function, and switch the
device back to 19200 when LCDd exits. This won't work, either, in
cases where another program changes the display speed, or if the
system panics and LCDd never has a chance to shut down cleanly.

At this point, the effect of sending the speed-change commands to the
device at the wrong speed, occasionally, appear to be benign. If test
reports from CwLinux users indicate that this isn't always true, then
further work may be necessary... but if the current (inelegant)
approach doesn't actually cause problems in practice, then I'd guess
that it's good enough.





Archive powered by MHonArc 2.6.18.

Top of page