[Lcdproc] lcdserializer problems

[Matteo Pillon]

--dTy3Mrz/UPE2dbVg
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Christian,

On Tue, Aug 08, 2006 at 12:54:15AM +0200, Christian Kruft wrote:
> >Do you really need 2 controllers? 4x20 is usually built with only one
> >controller (one enable pin).
> Yes, I got a HD44780 compatible 4x20 - onboard it haves to hd44780 - so=
=20
> there are to enables.

Ok, it's very easy to implement. Just choose an escape code to select
enable pin number.

> >I tink reinit is useful, because there are not only hd44780 displays
> >out there, but also almost-compatible ones, that need a different init
> >to work well (like the extended mode of ks0073). Only if you implement a
> >way to choose init in the hardware (a jumper, for example), software
> >reinit doesn't make sense anymore.
>
> Why? The PIC initalizes it for 4 bit. I used the lcdserializer driver=20
> for testing  and I've logged the serial port - the drivers sends a=20
> standard init. Why twice?

Try setting ExtendedMode=3Dyes
Here is ks0073 datasheet www.lcd-module.de/eng/pdf/zubehoer/ks0073.pdf

> >Why do you want this?
>
> One transmission failure and theres crap on the lcd until full new=20
> screen or rest.

Ok.
It can be enabled with an option in configfile.
Anyone wants to implement this? (I'm busy with something other right
now)

> >Uhmm, 0xFD and 0xFF correspond to useful characters in the hd44780
> >charmap and very useful in the ks0073 one (curly braces).
> >The escape approach of lcdserializer is not so much extendible,
> >pic-an-lcd has a more well-thought design.
> >It uses 2 escape codes, one for instructions (0x11) and one for data
> >(0x12). The latter is used only when the character to send is less
> >than 0x20.
> >This reduces overload from data escape and allows to use escape codes
> >for something else up to 0x20.
>
> Ok, I what do u recommend? I did a hardware-wakeup for a media-pc
> using VDR. While Shutdown, a perl script converts the next
> recording time and the actual time to strings which are send throug
> the serial line. The lcd shows the next wakeup time and the
> clock. When VDR is up and runnig, it could display channel data and
> so on to the lcd. Theres a lcdproc plugin out there. Because of 0xFE
> is coammand mode, I made the PIC reacting to this and switching
> modes. It now knows if it is data for the lcd or a command to set
> timer. Currently I use 0xFF as escape from lcdproc. The PIC now does
> all incoming data understand as commands.  Before sending wakeup
> time and time I kill LCDd and send 0xFE (echo -ne '\xFF' >
> /dev/ttyS0).  This works great at the moment.  But I don't know if
> 0xFF is ok. I thought that wouldn't get used in "normal" transfers
> to LCD.  I hope u understand what I did - my written English isn't
> very well.


If you want to retain compatibility with pic-an-lcd, we have to know
the others command bytes, anyone has the datasheet? Google isn't very
useful for this ;-).

With pic-an-lcd escape design, you can still use your perl script,
just add an escape characher under 0x20 that substitutes 0xFF.
Alphanumeric characters have ascii code below 0x20 (included, it's the
space), so your script won't be affected in any way.


Yours seems a good project, make it public when it's finished, much
people will be interested in it.


Bye.

PS: the new patch I sent yesterday includes support for your interface,
just use connectiontype=3Dvdr-lcd.

--=20
 * Pillon Matteo

--dTy3Mrz/UPE2dbVg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFE2KZgdF6kRp1ZHz0RApH1AKC2FmjZ9Zye/057dXkVzbiqI2ZwZACfU8wz
KnZd0CbEjTTw0K1YnzVIxJo=
=Wjz2
-----END PGP SIGNATURE-----

--dTy3Mrz/UPE2dbVg--