mangavalk/lcdproc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove some outdated documentation

Browse Source 
Most of it has been integrated into the User's Guide.
This commit is contained in:
mmdolze
2009-03-23 22:58:44 +00:00
parent 0a811b47f6
commit ddd39c7fd4
11 changed files with 4 additions and 1496 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Makefile.am
+1 -1
View File
@@ -7,7 +7,7 @@ SUBDIRS = shared clients server docs scripts
sysconf_DATA = LCDd.conf
EXTRA_DIST = $(sysconf_DATA) CREDITS README.IRman contrib
EXTRA_DIST = $(sysconf_DATA) CREDITS contrib
dist-hook:
README.IRman
-65
View File
@@ -1,65 +0,0 @@
Hello,
I made a IRman input driver for lcdproc-0.4 wich is now include in
"lcdproc-0.4-pre6". This input driver require "libirman-0.4.1b" the
library with function support for IRman.
I want to help you use this new driver (if anybody other than me use
it... please tell me!!!).
In order to help you compile your own version of LCDd with support for
IRman, I recorded every step I took in order to compile my own copy
based on two file downloaded directly from the internet.
The first file is " lcdproc-0.4-pre6.tar.gz " the current version of
lcdproc. You can download this file from
"http://lcdproc.omnipotent.net/download.php3" The second file is
"libirman-0.4.1b.tar.gz" the current version of libirman. You can
download this file from http://www.evation.com/libirman/ DO NOT USE
THE COPY OF LIBIRMAN FROM LCDPROC HOME PAGE... I don't know what is
wrong with that one but I can't decompress it???
How to compile lcdproc for use with support for IRman:
-Untar lcdproc and libirman:
tar -xzvf lcdproc-0.4-pre6.tgz
tar -xzvf libirman$$$
-Go, configure and compile libirman:
cd libirman-0.4.1b/
./configure
make
cd ..
-Go in lcdproc directory:
cd lcdproc-0.4-pre6
-Here is the modification you need to include IRman driver in lcdproc:
edit Makefile.config
# Irman input... handy!
DRIVERS += -DIRMANIN_DRV
DOBJ += irmanin.o ../../../libirman-0.4.1b/libirman.a
IRMAN=1
-Compile lcdproc
make
-Make sure you have a network interface up and working:
ifup lo
-Go and install your IRman configuration file:
cd server
cd drivers
cp DOTirmanrc ~/.irmanrc
-Modify if needed (if you use another remote control) the .irmanrc file.
-Run LCDd with two driver, irmanin and an output driver:
./LCDd -d irmanin "-d /dev/ttyS0" -d curses
-Try to access the menu by pressing the remote control.
Now if it does not work:
· Try your IRMAN on ttyS0 alone (with other software).
· Try LCDd without the IrmanIN driver.
· ...
David GLAUDE <dglaude@comtech.be>
PS: If you really have successfuly made LCDd working without IRman AND
You have successfuly made IRman device working AND you don't succeed
to make it work together ussing my driver... then maybe I can help and
give you some support (as time permit and if it does not eat up too
much bandwidth).
docs/Makefile.am
+1 -6
View File
@@ -4,12 +4,7 @@ man_MANS = lcdproc.1 lcdexec.1 LCDd.8 lcdproc-config.5
SUBDIRS = lcdproc-user lcdproc-dev
doxygen_input = header.html footer.html
EXTRA_DIST = README.dg \
README.dg2 \
README.glcdlib \
menustuff.txt \
netstuff.txt \
lcdproc.1.in \
EXTRA_DIST = lcdproc.1.in \
lcdexec.1 \
LCDd.8.in \
lcdproc-config.5.in \
docs/README.dg
-68
View File
@@ -1,68 +0,0 @@
William W. Ferrell (choadster@earthlink.net)
Scott Scriven (scriven@cs.colostate.edu).
Hello,
I am the happy new owner of a matrix-orbital LK-204-25 V.
I also made computer science studies (but currently I only program for fun).
The reason why I wanted this LCD screen was to build a MAME/MPEG3/DVD player.
Currently the IR receaver is missing, but I already started to work on my
project by checking LCDPROC capability and trying to make it work the way I
want.
I don't know yet if my developpement will be a client of LCDPROC or if I will
make a stand-alone program (more likely reussing some of your code).
Currently, feature in LCDPROC don't cover yet my need yet.
So, my best option is to support you or your team in building the perfect
server in order for me to build only a client.
So, I downloaded v0.4-pre5 and started to hack. ;-)
I was a little bit confuse with your documentation, sometime talking about
version 0.3.x or about comming feature, but reading the source code (and
the sgml description that I only founded later) was the best.
I made some "minor" change to a few source file (this is what I remember):
* Cleaning the help screen from LCDd.
* Adding a speed option to MtxOrb driver.
* Updated MtxOrb help screen to indicate those change.
* Added some error checking to parameter sended to MtxOrb driver.
* Added fake support for big number into curses driver.
* Some modification to the debug_driver in order to compile.
* Added bignum widget in order to use that feature from the driver.
* Added big cloc[K] (24H) to lcdproc to test the new widget. (ugly/blinking)
* Added a General Purpose Output function to the MtxOrb driver.
Here is some kind of todo-list one liner only:
* Implement a debug/error to a syslog server rather than printf(stderr,...
* General Purpose Output support.
* Make "LCDproc Server" and "End Screen" (build-in screen) optionnal.
* Make HeartBeat working with General Purpose Output (led blinking).
* KeyPad support.
* Make KeyPad local feedback using General Purpose Output (led blinking).
* Make the server port number (listen) a param/config option.
* Accept incoming 'telnet' (specific port) as a new i/o device (vt100/ansi).
* MtxOrb driver across an outgoing 'telnet' session (access server).
My major todo:
* Well, I would like to (one way or another) interconnect IrMan(?) and
LCDProc. I will use LCDProc for the ouput of the name of the song, ...
and maybe for keyboard input. I will also use IrMan or some infrared
library in order to receave remote controle input. Now, I would be nice
to be able to connect to LCDProc and 'register' a new input and/or output
device.
What I am thinking about is to have LCDd be a server with local device
to manage, but also have remote device that could attach themself to
LCDd. I think, by reading your documentation, that you have somethink like
that already in mind. This will allow dynamic addition of new driver without
having to recompile LCDd...
Change you should make yourself:
* Update the network protocol description with heartbeat function.
* Remove reference/out of date description related to 0.3.x
I made many change to a lot of different file... (sorry)
I don't have the tool/knowledge available to give you a patch with only my
modification. So, I send you a taz.gz with everything after my change.
I won't have much time to spend on LCDPROC for about two week (and the
week-end in between). This give you time to check my change and incorporate
anything you find interesting.
docs/README.dg2
-79
View File
@@ -1,79 +0,0 @@
Hello,
In order to compile LCDd (the lcdproc server) with support for IRman,
you need to put libirman in a neighbor directory.
Currently I use version 0.4.1b and this is hard coded into makefile and
#include string. (could do better).
Now for libirman to "work" you need a .irmanrc file with description of
you infrared "code" and mapping to command in my driver.
A template of such a file is given in the driver directory. This template
will only work with my JVC remote control, but you already have configured
IRman, you should be able to modify it for yours.
David GLAUDE
FINDING THE COMPONENT:
lcdproc: deamon to display information on a lcd screen.
version: 0.4-pre5
need libirman and my driver to support input from IrMan.
libirman: library in use to read input from IrMan on a serial port.
version used: 0.4.1b
currently used untouch and just needed to use my driver for lcdproc.
-----------Here stop the currently usefull information------------
The following text describe a project I never finished: LCDCD.
If anybody wish to do such an LCDd client, have a look at cdtools.
David GLAUDE
lirc: standardize interface to control IR receaver and emetteur.
version: 0.5.4
currently not used but might be usefull have support for other IR.
cdtools: command line program to control the cdrom and play audio cd.
might need some patch to have a better output of cd song information.
Hello,
This file describe the personnal developpement I have made and wich sources
you need to bring together in order to integrate everything the same way
I did.
Basicaly, we are talking about a yet another CD player 'yaCDplayer' but
because the name might already have been in use, it was decided to call it
'lcdcd'.
This CD player take as input (control) and output (display of the status) the
lcdproc server. It as thus no user interface on it's own.
Lcdproc is a server that allow the control of LCD screen over TCP connection.
Some LCD screen also have support to connect a keypad, it also offer
input user interface for this program.
Because lcdproc is a very flexible input/output server, it also support for
input comming from a joystic, the keyboard (curses output) or even irman.
It also support multiple driver simultaniously and multiple driver like curses
and joystic for those without an LCD screen and an irman.
Now irman is an infrared receaver with a build in chip to hash the input
signal into a unique key that can be readed throught a serial interface.
An other important think about lcdcd it is that in order to communicate with
lcdproc we use a TCP/IP connection. Lcdproc need to run in background on the
server where the input/output device are connected. Lcdcd must run on the
client where the cdrom is located. In between, we need to have a TCP/IP
network. Now, if you have a firewall, you will let traffic from the client to
the server on port 13666 wich is the default for lcdproc, be carefull there
is not security build in lcdproc and anybody can connect to it. If you don't
have an IP network and the client and the server are located on a single
computer (with the CDROM, the LCD screen and the IrMan connected) then you
need to enable IP on this computer. This can be done by putting an IP address
on a loopback interface (like 127.0.0.1 on lo, try 'ifup lo' it might work
also on your distribution of Linux).
Currently, this ... ---to be continued---
docs/README.glcdlib
-8
View File
@@ -1,8 +0,0 @@
The so-called "meta-driver" glcdlib extends LCDproc's supported drivers by
all the drivers supported by graphlcd-base, which you can get from
http://graphlcd.berlios.de.
In order to be able to use it, you have to get and install the glcdprocdriver
from http://www.muresan.de/graphlcd/lcdproc before configuring the LCDproc
build process --enable-drivers=glcdlib.
Lucian Muresan
docs/hd44780_howto.txt
-696
View File
@@ -1,696 +0,0 @@
HD44780 HOWTO
-------------
There are several ways of wiring up the HD44780 devices. Your choice
will probably be governed largely by your ability to wire up each one
and/or a desire to use the device with other programs.
The LCDproc HD44780 driver supports the following connections on a
parallel port:
- 4-bit
- 8-bit (winamp style)
- extended 8-bit (LCD + LED bargraph)
- serial LPT
And supports a PIC-an-LCD connected to a serial port.
The driver also lets you use multiple displays as a single virtual
display. For example, a 4, 2 and 1 line display can be used to form a
7 line display. The number of displays is limited by the individual
HD44780 driver.
1. Connections
--------------
1.1 Common connections for all connectiontypes
-----------------------------------------------
No matter what connectiontype you choose, you will always need some
connections. They are explaned here.
1.1.1 Power
------------
All variants use the same method of obtaining power. i.e., for each LCD:
LCD pin signal
1 GND (connect to any of pins 18 - 25 of you parallel port)
2 +5V
3 Vadj (contrast)
WARNING: Always double check your power connection, your display probably
wont survive a reversely connected supply !
There are several ways to get 5V:
- Connect to a 5V line intented for disk drives (the red wire is 5V, black
is GND).
- Get it from a joystick port (pin 1 and 9 are 5V, 4, 5 and 12 are GND).
It seems that some soundcards can use these lines for communication, so
if you want to use this first check wether it really gives a 'clean' 5V.
- If you don't have a backlight, you can sometimes get the needed mA's from
the LPT port itself. Connect a few diodes from the data pins to a
capacitor and you have the 5V. If it's strong enough is another question...
- Get it from the keyboard connector. I do not recommend to use this with a
backlight, as the keyboard connector is often protected with a fuse of
100mA or 200mA.
Connecting the contrast adjusting pin (Vadj.):
(variable resistor)
.------.
Vcc ---| 10k |--- GND
`---^--'
/|\
|
Vadj.
1.1.2 Keypad
-------------
You can connect a keypad with all connection types. The maximum supported
number of keys differs per type. There are several ways to connect the keys
to the input pins.
1.1.2.1 Direct keys
--------------------
If you connect a key like sketched below, then you can only connect one key
per input pin. It is a simple solution if you need only few keys.
O 5V
|
|
-
| | 10k
| |
-
|
+-----------o input (X)
|
|
o
\
o
|
|
=== GND
By default, the following keystrokes are generated by the different keys:
X0 A
X1 B
X2 C
X3 D
X4 E
You should modify and recompile the driver to get other keystrokes.
1.1.2.2 Matrix keys
--------------------
Using a matrix, we can connect much more keys. To simplify the drawing here,
we replace all switches with an @ symbol:
X line
|
|
Y line ---+---------
| | |
o | = --@--
\ | |
o |
| |
+---+
|
|
We connect the matrix of keys like this:
Y0 o---|<---@--@--@
| | |
Y1 o---|<---@--@--@
| | |
Y2 o---|<---@--@--@
| | |
Y3 o---|<---@--@--@ O 5V
| | | |
diodes | | | ___ |
1N4148 +----------|___|---+
| | | ___ |
| +-------|___|---+
| | | ___ |
| | +----|___|---+ resistors 22k
| | |
o o o
X0 X1 X2
As you can see, you need 1 resistor per X line, and 1 diode per Y line.
Lcdproc will presume that you have a keypad with a layout like a telephone
connected, with X and Y lines connected as show. To be more precise, it
assumes this:
X0 X1 X2 X3
Y0 1 2 3 A
Y1 4 5 6 B
Y2 7 8 9 C
Y3 * 0 # D
If you only need 10 keys, leave the rest away. However, the lcdproc menu is
controlled by the keystrokes A to D. You should modify and recompile the
driver to get an other keypad layout.
You can buy arrays of keys that are connected like this in the electronics
shop. They usually call it a matrix keypad. To hook it to lcdproc, you
would only need to add the resistors and diodes.
If you want to use just one return line, for example with the serialLpt
wiring, it looks (completely drawn) like this:
O 5V
|
.-.
| | 4k7 or 22k
diodes | |
1N4148 '-'
___ |
Y0 o---|<---o o---+
___ |
Y1 o---|<---o o---+
___ |
Y2 o---|<---o o---+
___ |
Y3 o---|<---o o---+----o return line
If the driver generates keypresses without you actually pressing a key,
it might be that the unconnected input lines are picking up
electromagnetic waves from the air. In that case connect the unconnected
input lines (pin 10, 11, 12, 13 and 15 of the LPT) to VCC = 5V.
1.1.3 Backlight
---------------
A small extension allows you to switch the backlight of the display on
and off. At the moment only the 4bit and winamp connection types support
this. The extension uses one output pin, you cannot use that pin for other
functions anymore. The wiring looks like this:
O 5V
___ |
+---|___|---+
LPT Sub-D connector | 4k7 |
| |e
___ | b |/
BL pin o------------|___|---+---------|
1k |\
bc327 |c
| LCD connector
|
+--------o 15 backlight
+--------o 16 GND backlight
|
=== GND
Note: 4k7 means 4,7 kohm.
The BC327 transistor has the following connections:
_____
| |
|bc327|
|_____|
| | |
| | |
| | |
c b e
Sometimes the backlight connections are not on the 'main' connector, but on
the side. If that is the case, there is usually NO RESISTOR present to limit
the current through the LEDs. Therefor you should then add a resistor after
the transistor of about 10 ohm (see display documentation).
If you want the backlight to light a bit while it's switched 'off', you can
add a resistor bypassing the transistor from e to c, with a value of, say
47ohm or 22ohm. (My 4x20 has an internal resistor of 6ohm, so with 47 ohm
extra it lights at only 1/9th. I like this. Joris.)
1.2 4-bit
----------
This is originally based on "lcdtext" (by Matthias Prinke).
The pinouts are:
printer port LCD
D0 (2) D4 (11)
D1 (3) D5 (12)
D2 (4) D6 (13)
D3 (5) D7 (14)
D4 (6) RS (4)
D5 (7) RW (5) (LCD3 - 6) (optional - pull all LCD RW low)
D6 (8) EN (6)
D7 (9) EN2 (LCD2 - 6) (optional)
If you want to connect more than two displays to the parallel port then
wire D5 (pin 7) to the enable line (pin 6) of the third LCD. Then for
displays four to seven use:
printer port LCD
STR (1) EN4
LF (14) EN5
INIT (16) EN6
SEL (17) EN7
The optional keypad can be connected as follows:
printer port keypad
D0 (2) Y0
D1 (3) Y1
D2 (4) Y2
D3 (5) Y3
D4 (6) Y4
D5 (7) Y5
nSTRB (1) Y6
nLF (14) Y7
INIT (16) Y8
nSEL (17) Y9
nACK (10) X0
BUSY (11) X1
PAPEREND (12) X2
SELIN (13) X3
nFAULT (15) X4
The optional backlight wiring should be connected to D5, pin 7.
1.3 8-bit "Winamp"
-------------------
This type of connection should work with winamp.
printer port LCD
D0 (2) D0 (7)
D1 (3) D1 (8)
D2 (4) D2 (9)
D3 (5) D3 (10)
D4 (6) D4 (11)
D5 (7) D5 (12)
D6 (8) D6 (13)
D7 (9) D7 (14)
nSTRB (1) EN (6)
nLF (14) nRW (5) (EN3 6 - LCD 3) (optional)
INIT (16) RS (4)
nSEL (17) EN2 (6 - LCD 2) (optional)
If you want the display to work with the Winamp plugin, wire nLF (pin 14)
to nRW of your LCD. You can then use the plugin in bidirectional mode (wich
is much faster). With 3 connected LCDs this is not possible.
Note from Benjamin: I haven't tried using winamp while having the third LCD
connected to this line.
The optional keypad can be connected as follows:
printer port keypad
D0 (2) Y0
D1 (3) Y1
D2 (4) Y2
D3 (5) Y3
D4 (6) Y4
D5 (7) Y5
D6 (8) Y6
D7 (9) Y7
nLF (14) Y8
INIT (16) Y9
nACK (10) X0
BUSY (11) X1
PAPEREND (12) X2
SELIN (13) X3
nFAULT (15) X4
The optional backlight wiring should be connected to nSEL, pin 17.
1.4 Extended 8-bit "lcdtime"
-----------------------------
This is originally based on "lcdtime" (by Benjamin Tse
<blt@ComPorts.com>) and allows you to combine the LCD with a LED
bargraph. The LCD is driven by LCDproc and the LEDs by another program
such as portato. Further details can be obtained from:
http://metalab.unc.edu/pub/linux/system/status/lcdtime-0.2.tar.gz
http://metalab.unc.edu/pub/linux/system/status/meter-0.2.tar.gz
http://metalab.unc.edu/pub/linux/system/status/portato-1.2.tar.gz
Theoretically this wiring sends the data over twice as slow as the
winamp or ext8bit wirings, because it only sends 4 bits at a time.
The LCD connections are:
printer port LCD
D0 (2) D0 (7)
D1 (3) D1 (8)
D2 (4) D2 (9)
D3 (5) D3 (10)
D4 (6) D4 (11)
D5 (7) D5 (12)
D6 (8) D6 (13)
D7 (9) D7 (14)
nSEL (17) -
nSTRB (1) RS (4)
nLF (14) RW (5) (LCD2 - 6) (optional - pull all LCD RW low)
INIT (16) EN (6)
See the lcdtime tar-ball (above) for full details of the bargraph
connections.
The optional keypad can be connected as follows:
printer port keypad
D0 (2) Y0
D1 (3) Y1
D2 (4) Y2
D3 (5) Y3
D4 (6) Y4
D5 (7) Y5
D6 (8) Y6
D7 (9) Y7
nSTRB (1) Y8
nSEL (17) Y9
nACK (10) X0
BUSY (11) X1
PAPEREND (12) X2
SELIN (13) X3
nFAULT (15) X4
The backlight wiring should be attached to nSEL, pin 17. Because the portato
program (mentioned above) also uses this pin to control the bargraph, you
cannot use the backlight control together with the bargraph.
1.5 Serial LPT
---------------
This interface uses a handful of wires to interface to the
HD44780. Suitable for high noise, long connections. Designed by
Andrew McMeikan <andrewm@engineer.com>. The original wiring and
driver can be found at:
http://members.xoom.com/andrewmuck
I (Joris) have extended this driver and the wiring a bit. It now supports
keys again (it had earlier supported keys, but some time did not).
Further I have extended the driver and the wiring to be able to run
using 2 instead of 3 output pins. That's even one less pin ! :)
Of course the use of fewer lines than the other wirings can not stay
without drawbacks. In this case the simplicity of the long feeding wires
is compensated by some intelligence in the decoding of the data. If you
have no experience with the soldering iron, I do not recommend to build
this wiring.
OK, so here is the wiring. First of the 'simple' 3 wires version. IC1 is
the shift register, a 4094. Do not forget to connect the 5V to pin 16 and
GND to pin 8 of the IC.
IC1
-----------
| 4094 |
5V | shift reg | display
O | | /keys
| 1| |3
+----|STR Q0|---------------------o 7 D0
| | |4 /Y0
Data | 2| Q1|---------------------o 8 D1
D3 5 o---------------------------|D |5 /Y1
| | Q2|---------------------o 9 D2
| 3|CK |6 /Y2
D4 6 o---------------------------| Q3|---------------------o 10 D3
| | |10 /Y3
| 15| Q4|---------------------o Y4
+----|OE |11
| Q5|---------------------o 4 RS
| |12 /Y5
| Q6|---------------------o Y6
| |13
| Q7|---------------------o Y7
| |9
| QS|-- +--o 5 RW
| __|10 |
| QS|-- ===
| |
-----------
D2 4 o-------------------------------------------------------------o 6 EN
D7 9 o-------------------------------------------------------------o 6 EN2
(2nd LCD)
5V O-----+--------+----------------------------------+-----o 2 VCC
| | |
| | |
|100n O 16 .-.
--- IC1 | |<---o 3 Vlcd
--- O 8 | |10k
| | '-'
GND | | |
18..25 o-----------+--------+--------------------------+-------+-----o 1 GND
|
=== GND
The second possible wiring is with 2 output lines. This one is a bit more
complex. If you do not understand the schematic, do not build it.
IC2
-----------
| 74HCT164 |
| shift reg | display
| | /keys
Data 1| |3
D3 5 o-----------------------+---|D Q0|---------------------o 7 D0
| | |4 /Y0
| 2| Q1|---------------------o 8 D1
+---|D |5 /Y1
| Q2|---------------------o 9 D2
| |6 /Y2
| Q3|---------------------o 10 D3
| |10 /Y3
Clock 8| Q4|---------------------o Y4
D4 6 o---------------------------|CK |11
| Q5|---------------------o 4 RS
___ 9|\ 8 9|_ |12 /Y5
+--|___|--+----| >o----|R Q6|---------------------o Y6
| 22k | |/ | |13
| --- IC1 | Q7|---+ +--o 5 RW
| --- | | | 5V |
| |100p ----------- | O ===
| | | |
| === | .-.
| | | |22k
+--------------------------------------+ | |
| '-'
| ___ 11|\ 10 | 5|\ 6
+--|___|--+----| >o-------------------||----+-----| >o---o 6 EN
22k | |/ 22p |/
--- IC1 IC1
---
|22p
| IC1=74HCT14 (6x Schmitt trigger inverter)
===
5V O--+-------+------+------+------------------------+-----o 2 VCC
| | | | 13|\ 12 |
| | | +---| >o- |
|100n O 14 O 14 |/ .-.
--- IC1 IC2 | |<---o 3 Vlcd
--- O 7 O 7 1|\ 2 3|\ 4 | |10k
| | | +--| >o- +--| >o- '-'
GND | | | | |/ | |/ |
18..25 o--------+-------+------+-------+----------+-----+------+-----o 1 GND
|
=== GND
1.6 PIC-an-LCD serial device "picanlcd"
----------------------------------------
The PIC-an-LCD module is also supported. It is not connected to the LPT port
but to a serial port, which saves you from a lot of potential problems.
To use it, specify the device to which you have connected the module in the
config file with the Device= setting. The default is /dev/lcd.
It does not support a keypad nor backlight switching.
1.7 LIS2 Usb device
===================
LIS2 from VLSystem (http://www.vlsys.co.kr) is a full featured usb vfd module
with four channel fan controls. This device can be access as a serial device with
help of the kernel modules ftdi_sio wich map the usb port to a serial port (/dev/ttyUSBx).
To use LIS2 with LCDproc, you will need a few settings in the config file :
[server]
Driver=hd44780
[hd44780]
size=20x2
ConnectionType=lis2
#Device=/dev/ttyUSB0
extendedmode=false
Size of the display (size=20x2), driver to use in ConnectionType: lis2, the serial Usb
device as device settings (default is /dev/ttyUSB0), and extendedmode should be left to false,
as this device don't seems to support hd44780 extended mode.
The device support only a subset of the hd44780 specification. For now, I find this function:
Function #1 : Clear Screen
Send char(0)
Send char(160)
Send char(0)
Send char(167)
Function #2 : Cursors move: (x,y)
Send char(0)
Send char(160 + y)
Send char(x)
Send char(167)
Function #3 : Write a char
Send char(asciiCode) : asciiCode 0 to 7 can be redefine to user charset (see below).
Function #4 : Redefine a char
Send char(0)
Send char(171)
Send char(matriceNum) : Ascii code of char to refine, from 0 to 7
Send char(line) : the line to change
Send char(pixel) : define wich pixel of the line is on or off.
There's 5 pixels by line, adresse by power of 2, from right to left (16, 8, 4, 2, 1).
Function #5 : Fan Control
Send char(0)
Send char(174)
Send char(0)
Send char(0)
Send char(fan1)
Send char(0)
Send char(fan2)
Send char(0)
Send char(fan3)
Send char(0)
Send char(fan4)
Send char(0)
Send char(0)
fanX is a value from 0 to 255, 0 is fan off, 255 is fan full speed.
1.5.1 Keypad
------------
To understand this part of the serialLpt documentation, you also need to
read the keypad section in this document.
serialLpt wiring supports a keypad. The 3 wires version supports
8 keys, or if you use multiple return lines up to 8 x 5 = 40 lines. The
2 wires version supports 7 keys, or with multiple return lines
7 x 5 = 35 keys.
The return lines are the following:
nACK (10) X0
BUSY (11) X1
PAPEREND (12) X2
SELIN (13) X3
nFAULT (15) X4
On lines longer than, say a meter, you should buffer the return line(s).
If you only have 1 return line, you can buffer it with two remaining
buffers from the 74HCT14:
1|\ 2 13|\ 12 ___
keypad o-----| >o------| >o---|___|---+---o input pin on LPT port
return |/ |/ 220E |
IC1 IC1 ---
--- 1nF
|
===
Also a backlight is suported. You will also need a port from the 74HCT14 for
that. The BL output below should be connected to the BL input in paragraph
1.1.3.
___ 3|\ 4
Data o-----|___|--+----| >o----o BL output
LPT-D3 470k | |/
--- IC1
---
|100nF
|
===
2. Compiling
------------
Make sure that the HD44780 files are built when you run configure. This
can be done by specifying "--enable-drivers=all" or by
"--enable-drivers=hd44780".
3. Running
----------
Modify the LCDd.conf file before you run LCDd. In this config file are
detailed instructions on how to configure the HD44780 driver.
Then as usual, start LCDd with the correct config file:
LCDd -c ./LCDd.conf
for example.
If you want to override the driver selection in LCDd.conf then use:
LCDd -c ./LCDd.conf -d HD44780
If you use this, the HD44780 driver will read the options from the config
file.
4. Miscellania
---------------
This text originally taken from a message by Bill Farrow
<bfarrow@arrow.bsee.swin.edu.au>.
Updated February 2000, Benjamin Tse (blt@ComPorts.com)
Updated October 2001, Joris Robijn (joris at robijn.net)
docs/menustuff.txt
-144
View File
@@ -1,144 +0,0 @@
CAUTION:
This file may contain outdated information.
In order to find current information about the LCDproc client-server
protocol see the LCDproc Administrator's Guide in docs/lcdproc-dev/
========================================================================
Menus
This file originally described how the menus should become implemented.
Now that they are implemented, the description is also in the source:
server/menu.h. The current menu contents can be found in server/menus.c.
Reading these files it becomes easy to understand the menus.
I (Joris) have given the file you are reading a new purpose:
client-supplied menus.
fixme: some of this stuff is described better in
./docs/lcdproc-dev/language.docbook so this file should
probably be removed after extracting the information that is
not anywhere else; see also ./docs/netstuff.txt (Volker)
INTERNAL SERVER DATA
In the server dir there is a file named client_menus.h from 3 april 2000
which describes the data structures that we should probably need.
typedef struct client_menu {
char id[];
LL *items;
} client_menu;
(LL is a list)
typedef struct client_menu_item {
char id[];
int type; // Title, function, submenu, slider, checkbox, etc...
int value; // Holds stuff like "true", 43, etc...
char text[]; // Text to display here...
char child[]; // For the "submenu" type
} client_menu;
DEFINING BY CLIENTS
To define a menuitem using the widget language the following functions have
been defined in the file client_functions.c:
(In my opinion the menu_add functions can be left away, because a submenu
is an item as well.)
menu_add_item
menu_del_item
menu_set_item
The functions are not implemented yet, but looking at what we need, the
parameters could look like this:
menu_add_item itemname itemstring itemtype [-m menu] -v initvalue
menu_del_item itemname
menu_set_item itemname [-v value] [-s itemstring]
You should not need to define the first menu of a client. The name of the
client is known and will be used to give the menu a name. The first level
menu will simply be created automatically when a client defines an item in
it's menu.
(Or is there any reason why the client should create its own menu ? A client
should not be able to create two main menus anyway)
The following item types exist:
title A title to be used on the top of the menu.
menu A submenu. Refer to this new menu using the -m option.
action An action. The client is notified that the user wants the
action to be executed.
checkbox A checkbox. The client is notified whenever the state is
changed.
slider A checkbox. The client is notified whenever the slider is
moved.
fixme: missing description of numeric, alpha, ip, ..., see
./docs/lcdproc-dev/language.docbook (Volker)
Note that I have changed the 'function' menu type to 'action' here. The name
'function' was only appropriate internally, because a function was called.
For clients we only know an action will be performed.
fixme: missing reference to lcdexec (Volker)
RETURNED DATA
The server should inform the client on events. It should be able to return
strings like:
action itemname
checkbox itemname newvalue
slider itemname newvalue
EXAMPLE SESSION
We have an M3 player here.
menu_add_item action play "Play"
menu_add_item action stop "Stop"
menu_add_item menu tracks "Select Track"
menu_add_item action track1 "1: Leg"
menu_add_item action track2 "2: Palomine"
menu_add_item action track3 "3: Kid's allright"
menu_add_item action track4 "4: brain-Tag"
menu_add_item menu CDs "Select CD"
menu_add_item action cd1 "1: Bettie Serveert - Palomine"
menu_add_item action cd2 "2: Rammstein - Herzeleid"
menu_add_item slider volume "Volume"
When you should switch CD using the second submenu, the client will be
informed with:
action cd2
Then the client knows the user has selected the second CD, and the items of
the Track menu should be changed according to the contents of the CD:
menu_set_item track1 -s "1: Wollt ihr das bett in flammen sehen"
menu_set_item track2 -s "2: Der meister"
menu_set_item track3 -s "3: Weisses fleish"
When the user changes the volume slider, the client will be informed with:
slider volume 40
When it is set at 40%.
fixme: missing description of menu_goto for session control (Volker)
--
Complete rewrite, Joris Robijn, 20011015
docs/netstuff.txt
-313
View File
@@ -1,313 +0,0 @@
CAUTION:
This file may contain outdated information.
In order to find current information about the LCDproc client-server
protocol see the LCDproc Administrator's Guide in docs/lcdproc-dev/
========================================================================
LCDproc client/server protocol, V0.2
---------------------------------------------
fixme: most of this stuff is described better in
./docs/lcdproc-dev/language.docbook so this file should
probably be removed after extracting the information that is
not anywhere else; see also ./docs/menustuff.txt (Volker)
QUICKSTART
----------
- Open a socket to the LCDproc port (usually 13666).
- say "hello"
- the server will notify you of a good connection, and some info
on the type of display available.
- Identify yourself. "client_set name some_sort_of_name"
- Add a new screen. "screen_add my_screen"
- Put a widget on the screen.
"widget_add my_screen my_widget string"
- Now, update the widget whenever your status info changes...
"widget_set my_screen my_widget 1 1 Booger!"
- When you're done, just close the socket.
- You probably want to read on for more information, once you've
gotten the LCDproc server to display something. :)
DETAILS
-------
There are two parts to the spec:
A language for client/server to interact with.
A protocol guiding interactions.
=================== The protocol ==================================
The protocol is context-free. So, no commands require responses; and
responses are simply commands.
The client may send updated info at any time, and the server decides
whether to display it. An ideal communication may flow like this:
client->server server->client
------------------ -------------------
(idle) (nothing)
(idle) "I'm listening"
new stats... (nothing; displays updated stats)
new stats... (nothing...)
new stats... (nothing...)
new stats... "Okay, be quiet"
(idle) (nothing; displays new screen)
... ...
(idle) "Your slider moved up"
Set slider value: 43 (nothing; displays updated slider)
(idle) (nothing)
... ...
But the client could safely continue to send new stats, knowing that
the server isn't listening and won't display it. Also, the client could
ignore the slider change, and the slider onscreen simply wouldn't move.
=================== The syntax ==================================
The language is ascii-based, so a human can telnet to a port and talk
to the server. This helps with development and debugging.
With that in mind, a commandline-like syntax seems good:
function arg1 arg2 arg3 ...
The syntax dictates that the first word is a function name, and the
rest of the line is passed to that function as an argument.
String-type arguments should always come last. So, for example:
set_label 23 3 2 Hey, booger. What's up?
The first argument is a label id number, the 2nd and 3rd are x,y
coordinates onscreen, and the rest of the line is a string.
=================== The command set ==================================
The naming convention dictates that function names are lower-case,
with underscores ("_"'s) between words.
The naming convention also requires that function-name words go in
descending order. So, "screen_set_priority" would be okay, but
"set_screen_priority" would not.
Id's are strings. (the "#id" things)
In general, we're trying to keep the command set small. Especially the
server->client functions, so that clients won't have to handle a lot of
different types of input.
Now, the function list:
client->server functions
-------------------------
hello
Client init. You must send this before the server will pay
any attention to you. You'll get some info about the server
in return... (a "connect" string)
client_set [-name #id]
Set client's name and other info
screen_add #id
Add a new screen
screen_del #id
Remove a screen
screen_set #id [-priority integer] [-name "my_name"] [-duration integer]
[-wid width] [-hgt height] [-heartbeat type]
Initialize a screen, or reset its data.
Heartbeat types can be:
on, heart "Heart" icon
normal, default User's choice
off, none None
slash Rotating slash
Priority values are as follows:
0 You feel like getting kicked off the server, don't you?
1 The world is about to explode
16 Emergency priority
32 Very high priority (important)
64 High priority (normal)
128 Normal (recommended)
192 Low priority (normal)
224 Very low priority (very unimportant)
240 Boring as hell
255 This screen won't show up very much even if there are
no other screens queued...
An example of using priorities is as follows.
Imagine you're making an mp3 player for LCDproc. When the
song changes, it's nice to display the new name immediately.
So, you could set your screen's priority to 64, wait for
the server to display (or ignore) your screen, then set the
screen back to 128. This would cause the mp3 screen to
show up as soon as the one onscreen was finished, then
return to normal priority afterward.
Or, let's say your client monitors the health of hospital
patients. If one of the patients has a heart attack, you
could set the screen priority to 16 (emergency), and it
would be displayed immediately. It wouldn't even wait for
the previous screen to finish. ... And it would stay there
most of the time until the user did something about it.
A priority of 1 would stay onscreen permanently, with
flashing lights and other visual cues if possible.
... Please *don't* use this priority. :)
The duration can be either a positive number, or -1. A
positive number indicates how many display frames the screen
should last for. A 0 or -1 means that the server should use
"auto" duration, which is probably a good idea. This will be
whatever the user wants. It defaults to 4 seconds (32
frames), or will be calculated for things such as scrollers.
widget_add #screen #id type [-in #id]
Add something onscreen
Widget types can be any of the following: "string", "hbar",
"vbar", "title", "icon", "num" "scroller", "frame", ... more
later? Widgets are drawn in the order you create them.
You can put a widget inside a frame by adding "-in #id", where
#id is the name of a frame.
widget_del #screen #id
Kill something onscreen
widget_set #screen #id data
Set (reset) widget's data
Note that the "string" type should be used for frame buffers.
Strings should not be bigger than the screen.
The widgets take these arguments for data:
string x y text
hbar x y length_in_pixels
vbar x y length_in_pixels
icon x y binary_data
num x number_between_0_and_9
title text
scroller left top right bottom direction speed text
A scroller is a string which scrolls.
This is useful for things such as the disk
usage screen, which may be very tall.
The speed is how many display frames to delay
between scrolling. Each display frame is
1/8th of a second, by default.
Direction must be "h" for horizontal, "m" for
marquee style horizontal or "v" for vertical
scrolling..
Positive speeds indicate frames per movement.
Negative speeds indicate movements per frame.
frame left top right bottom wid hgt dir speed
Frames occupy the area (left, top)-(right,bottom)
onscreen, and the inside area is wid x hgt.
The inside may be bigger than the actual size,
so that the frame will scroll.
server->client functions
-------------------------
connect args
Verifies connection; gives info about the LCD, etc...
bye
Notifies the client of a server shutdown.
huh? [info]
Notifies the client of a request error.
listen [#screen [#widget [#widgets...]]]
Notifies client that "server is listening for data".
ignore [#screen [#widget [#widgets...]]]
Tells the client "shut up".
key #id
Sends a keypress to the client.
client->server functions
-------------------------
client_add_key #id
Tells the server the client can handle keypresses of type #id.
#id is just "Up", "Down", "Left", "Right", "Enter", "Escape", ...
All keypresses are disabled by default, so you'll have to tell
the server which ones you want to accept...
client_del_key #id
Tells the server to never send that keypress.
All keypresses are disabled by default.
menu_add #id
Add a new menu.
menu_del #id
Get rid of a menu.
menu_set [top] [name my_menu_name]
if (top) Gets added to "Client Menus".
else Client must insert it into its own menu heirarchy.
menu_item_add #menu #id
Add a new, blank menu item.
menu_item_del #menu #id
Delete a menu item.
menu_item_set #menu #id type [value] text
(re)Set the menu item's data.
If type is "checkbox" or "slider" or "menu", [value] should
contain appropriate info. (like true, 43, or #menuid)
backlight [on] [off] [blink] [flash] [toggle]
Requests that the backlight be toggled... The backlight
command will likely be ignored, but users can enable it if
desired.
The LCDproc server has [will have] several backlight modes:
On Stays on all the time
Off Stays off all the time
Load? Turns off when the load average is low
Shell? Controlled by a user-supplied shell script
Open Can be controlled by all clients
Vis Controlled by the currently visible client
driver_add #id? type args
Start up a new output driver.
Nice if you want to check on your machine remotely with the
curses driver.
driver_del #id? (or type)
Stop a running output driver.
Good for reclaiming your joystick when you want to play games...
server->client functions
-------------------------
menuevent #menu #item #action
Tells the client that a menu item was selected/used/etc...
The client should handle this according to what type of menu
item has been activated, and should probably send the server a
new item definition if the item was a checkbox or slider.
server/drivers/README
+2 -95
View File
@@ -3,98 +3,5 @@ UNDERSTANDING LCDPROC DRIVERS
LCDproc drivers are compiled as modules that will be loaded by the
LCDd daemon's core on request.
To understand how to write a driver see docs/API-0.5.txt and the
section about the driver API in the Admin Guide.
-------- 8< snip >8 ------------------
The remainder of this file may be horribly outdated.
Treat the information contained herein with caution.
You have been warned.
------------------------------ lcd_logical_driver ------------------------------
The first thing that is done is that lcd_init (lcd.c) is called. This function
first sets up basic housekeeping details. Then it calls lcd_drv_init, which
initializes the basic functions for the lcd structure.
Each function loops through the list of currently loaded and active drivers.
The framebuffer is set to point to the appropriate framebuffer. Then
the function determines what function to call (for each driver) - which
is one of three possibilities:
1. driver->function() > 0
Call the driver function contained in driver->function();
2. driver->function() == NULL
Ignore (no function);
3. driver->function() == -1
Call the generic driver.
The generic driver functions are drv_base_* and are contained in drv_base.c
Note that these drv_base_* functions are also installed as part of the "base"
driver, and thus could be called not only once, but many times.
So... to clear the screen (after initializing the drivers) one might do
this - and it leads to the sequence of activities shown...
lcd.clear;
--> lcd_drv_clear;
--> driver->clear;
--> drv_base_clear;
--> driver->clear;
--> MtxOrb_clear;
--> driver->clear;
--> drv_base_clear;
--> driver->clear;
In the first case, the "base" driver is called. In the second, the "MtxOrb"
driver is called, and it has a function to use. In the third, an unnamed
driver is called, but it delegates back to the base function. In the fourth,
the driver has no function; so it is ignored.
SUGGESTED SIMPLIFICATIONS
1. Remove the base driver entirely.
The base driver does not provide any substantial advantage, and significantly
complicates code.
2. Separate the input driver data from the output driver data.
This promotes easier comprehension and allows more specialization of each.
Some drivers may only have input or output components; some may have both.
This also permits coding such that only one output device is allowed
while multiple input devices are allowed.
3. Use only ONE output driver for each invocation of the server.
This simplifies coding - since there is then only one size, one width, one
height. It also removes the need for scanning a big loop for functions to
execute.
Given these enhancements, all of drv_base.c could be eliminated, and
probably most or all of lcd.c. It would dramatically reduce all of the
processing overhead necessary to handle screen output.
MORE SUGGESTIONS AND ENHANCEMENTS
1. Make input keys driver-specific.
This permits the use of each and every key without overlap. For example,
it would keep a joystick button press from conflicting with a LCD display
button.
2. Specify the standard (configurable) set of keys for server actions
in each driver.
This permits not only a unique standard configuration for each device,
it also hides what that is from the program itself. If this is configurable,
it also makes it possible to adjust this set of keys during operation.
To understand how to write a driver see docs/API-0.5.txt or the
section about the driver API in the Developer's Guide.
server/drivers/ideas.txt
-21
View File
@@ -1,21 +0,0 @@
Hmm...
How to do multiple drivers...
lcd_sample_func(parameters)
{
D'oh..
}
lcd_driver_caller()
{
foreach driver (@drivers)
{
if(driver supports function)
call driver's function
else if(driver uses defaults)
call default function
else don't do anything
}
}