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 18:19:02 2007

> Do you really need to set/reset the port speed? You seem to have found out
> how to make the hardware behave.
> If the device is already at the rate you want, simply setting it to that
> rate won't have any effect other than ensuring there is nothing left in any
> buffers. If it's not at the desired rate setting it will flush all the
> buffers and place it at the speed you want.

The problem is this: LCDd knows the speed at which it wants to talk with
the device (since that information is in the config file), and it has
full control over its side of the connection, via the Linux serial
port driver ioctls. Unfortunately, it does not know what speed the device
is currently configured for, since a previous run of LCDd (or another
program) might have left the display operating at either 9600 or 19200
bits/second. The two speeds (host-side and device-side) have to be
made to match, somehow, or the device will receive nothing but garbage.
Unlike a Hayes-compatible modem, the CwLinux display does not have an
"autobaud" capability - it cannot automatically match the speed of
the incoming data.

The CwLinux devices are known to power up at a speed of 19200 bits/second.
As far as I can tell, this is the *only* thing that a program can count
upon. There doesn't seem to be any way to force the device back to
this state without either power-cycling it, or sending a command (i.e.
you can't do it just by dropping DTR, or sending a long-space). Nor
is there any way to figure out what speed the device is using, other
than sending it a command at one speed or the other and seeing if it
responds - and if you "guess" the wrong speed, then the device is
likely to interpret the command you send as garbage or line noise, and
either display gibberish or do something else of a somewhat random

Since one has to send data to the device in order to either [1]
switch speeds, or [2] poll the device to figure out what speed it's
operating at, I decided to stick with approach [1].

My guess is that the most reliable way to use these devices is to
stick with 19200 bit/second operation only, and never try to
communicate with them at 9600 bits/second at all... just ignore
the device's ability to communicate at a lower speed. I'm not sure
why the original author of the CwLinux driver went to the trouble of
trying to support 9600 bit/second operation... it doesn't seem to be
any more reliable than 19200 (in my installation at least) and it
adds complexity to the startup code.

However, with the current code structure, both speeds seem to be
supportable with good reliability, regardless of the speed at which
the device was previously configured.

Archive powered by MHonArc 2.6.18.

Top of page