LCDProc 0.5.4-dev

tix

There may have been other factor(s) here [cable modem locked up and wouldn't pass traffic], but at 96 hrs uptime, my display quit again and I couldn't log in again. I've rebooted and will monitor and report.
I think this is just a coincidence but want to report anything that might be an issue.

This time on reboot I have 2 LCDd processes running but can't 'see' lcdproc.sh unless I make my puTTy window wide enough to display the output????


[2.1-DEVELOPMENT][root@pfsense.]/root(6): ps aux | grep lcd

Stretched screen width and repeated command:


[2.1-DEVELOPMENT][root@pfsense.]/root(7): ps aux | grep lcd
root   41210  0.0  0.6  3656  1420  ??  IN   12:59PM   0:00.01 /bin/sh /usr/local/etc/rc.d/lcdproc.sh start
[2.1-DEVELOPMENT][root@pfsense.]/root(8): ps aux | grep LCD
root   51129  0.0  0.5  3352  1164  ??  IN   12:59PM   0:00.01 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf
nobody 51245  0.0  0.6  3368  1424  ??  SNs  12:59PM   0:09.83 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf
[2.1-DEVELOPMENT][root@pfsense.]/root(9):

Not that this is a big deal but weird. Does it happen to anyone else?

stephenw10

Yep same here, I have to maximise the window see it. Also is won't show up at all on the serial console which has a much smaller resolution.
Weird. :-\

I've been playing around with all sorts of things, different delays, different kill commands. I've not once had it boot cleanly. It either boots to two copies of LCDd, one of which is running as root, or kills LCDd completely.

Steve

easyhugo

@mdima:

@easyhugo:

Hi Guys

Is it possible to ad this Lcd to

http://allnet.de/1577.html?&tx_mmallnetproductplugin_pi1[showUid]=421433&cHash=949c8a38a8
ftp://212.18.29.48/ftp/pub/allnet/utility-server/fw8888/lcm_server_1.0.tar.bz2

i,m trying this for some time but with no success, see other posts from me

thx max

Hi Max (easyhugo),
it's impossible to know for me which driver this LCD panel uses… do you know the chipset? Can it use one of the drivers already made or you need another driver?

Ciao,
Michele

Hi
sorry but no driver work with this display, it does not work without these lcm server.

@stephenw10:

My German is very bad! :-[ (Only beaten by my non-existant Italian! ::))

However, according to [url=http://www.ipcop-forum.de/forum/viewtopic.php?f=22&t=26948#p231301]this post by IPCop ledgend Wintermute the display in the FW8888 is an LCM-162.

This doesn't appear to be supported directly by LCDproc but this blog post seems to show it is possible. That's quite old now so support maybe better integrated.

What drivers/versions have you tried?

Steve

Edit: This post confirms this.

and yes wintermute is an excellent ipcop programmer, but ipcop is not an freebsd os so i cant copy the files .
i have tried to copy the lcm to the pfsense and change the config files but with no success.
my test with these lcm if i tried the dev version was not born :D so at now i will connect the guys from allnet how this lcm will work
the answer i would then post

thx

edit:
from the lcm pckage:

Make commands:
Static binary:
gcc –static -o lcm_server lcm_server.c

Dynamic linked binary:
gcc -o lcm_server lcm_server.c

Execution command:
lcm_server /dev/ttyS1 "Banner"

Command FIFO:
/var/run/lcm_cmd

Available commands:
Clear -- Clear the LCM display
Home -- Set the cursor back to row 0, column 0
Display {on/off/nocur} -- Turn display on, off and on without cursor
BKLight {on/off} -- Turn LCM backlight on and off
Setpos {0~1} {0~15} -- Set the cursor position to row and column
Write {text} -- Write the text to LCM start from
current cursor position
Examples:
echo "Display oncur" > /var/run/lcm_cmd
echo "Setpos 0 0" > /var/run/lcm_cmd
echo "Write test message" > /var/run/lcm_cmd

Key FIFO:
/var/run/lcm_key

Available keys: UP, DOWN, RET, ESC

Example:
cat /var/run/lcm_key

Note: There is no key de-bounce mechanism on LCM.
Multiple key response may happen while receiving keys.

mdima

Hi,
as for the problems restarting the package, deleting the "two seconds delay" in the script while killing the package binaries seems to solve the problem.

I will post a new version of the package soon.

Ciao,
Michele

stephenw10

Hi Michele, I hope you're feeling better. :)

Removing the delay(s) completely didn't work for me on my X-Core box. In fact I tried many combinations of delays in different places an failed to get a clean boot.

Steve

mdima

@stephenw10:

Hi Michele, I hope you're feeling better. :)

Removing the delay(s) completely didn't work for me on my X-Core box. In fact I tried many combinations of delays in different places an failed to get a clean boot.

Steve

Hi Steve,
mmhhh… I just had a clean reboot, after that the panel was working and:

[2.0.1-RELEASE][root@pfsense2.domain.nt2.it]/root(18): ps -ax | grep lcd
39543  ??  SN     0:00.91 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.p
27085  v0- I      0:00.00 /bin/sh /usr/local/etc/rc.d/lcdproc.sh start
13349   0  R+     0:00.00 grep lcd

[2.0.1-RELEASE][root@pfsense2.domain.nt2.it]/root(23): ps -ax | grep LCD        
37346  ??  SNs    0:00.31 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf
 7034   0  S+     0:00.00 grep LCD

I can't find anything wrong. Also restarting the service quickly, or changing the service properties while the service is running, brings me to the above state, which is consistent.

I will investigate more, but until now the only change I did is to remove the "sleep" lines in the "lcdproc.inc" file and saving the configuration (line 506 and "a bit below").

Where did you remove "sleep" lines from?

Thanks,
Michele

mdima

@stephenw10:

Although what I wrote above is true if you get an 'un-killable' process the main reason the lcdproc.sh remains running is that it is held open by the php call.
You need to background the process (&) like so:
$start .= "\t/usr/bin/nice -20 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php &\n";
Steve

Hi Steve,
I added the & at the end of the command, and yes the lcdproc.sh is not visible anymore with ps -ax (sorry, I come from Windows and I don't know this tricks).

Btw, I made different "restarts" of the service and a reboot, everything was running and there was only 1 client and 1 server running.

I don't know what is going wrong on your boxes…

Ciao,
Michele

stephenw10

@mdima:

Where did you remove "sleep" lines from?

From lcdproc.inc as you did. I also added a "&" to the call to lcdproc_client.php as I details a few posts back.
I'll try taking that out again.

Edit: You type faster than me!

I am relatively new to FreeBSD also. I only knew to do that because that's how it was called in the old Firebox tarball.

I am starting to think that a lot of this might be down to the speed of the box. The X-Core is a relatively old machine. I'll have to try it on the X-e box for comparison. Alternatively you are using a different driver, perhaps the service is able to stop and start faster?

During the boot process the the package config pages are synced. Because the lcdproc package has two pages both are synced however the lcdproc_screens.xml simply calls the lcdproc.xml sync function. This results in the sync function running twice hence the service is restarted twice. Then slight later in the boot process the WAN interface comes up and receives an IP address, this results in a call to restart all packages again.

I'll run some more tests.

Steve

mdima

@Cino:

the results were blank. I dont have anything set, left it for the system to decide. The dashboard says 299000.. I'll set a value and see what happens. Its been awhile since I looked at the lcdproc code, but I'm thinking there was default 10000 if nothing is set via the gui now that i think about it a little more

This is done, you'll find it in the next release of the package!

Ciao,
Michele

mdima

@stephenw10:

@mdima:

Where did you remove "sleep" lines from?

From lcdproc.inc as you did. I also added a "&" to the call to lcdproc_client.php as I details a few posts back.
I'll try taking that out again.

Edit: You type faster than me!

I am relatively new to FreeBSD also. I only knew to do that because that's how it was called in the old Firebox tarball.

I am starting to think that a lot of this might be down to the speed of the box. The X-Core is a relatively old machine. I'll have to try it on the X-e box for comparison. Alternatively you are using a different driver, perhaps the service is able to stop and start faster?

During the boot process the the package config pages are synced. Because the lcdproc package has two pages both are synced however the lcdproc_screens.xml simply calls the lcdproc.xml sync function. This results in the sync function running twice hence the service is restarted twice. Then slight later in the boot process the WAN interface comes up and receives an IP address, this results in a call to restart all packages again.

I'll run some more tests.

Steve

Hi Steve,
so good, you removed the delays exactly where I was removing them from, so nothing to say about that.

If is true, the package is synced twice during the reboot, I don't know how to avoid that (without forcing a manual service restart every time someone changes a setting in the "screens" page), but I confirm you after some reboot, that on my hardware this do not give any problem (X3460 Xeon, SSD HD, Intel dual port NICs, 4GB ram, Sureelect USB panel 20x4, but ok, I understand that like this is easy, I know)…

As for my situation, I achived a total stable situation. I will release the latest changes asap...

Ciao,
Michele

mdima

Released!

The changelog is the following:

The Client now runs in background (added a trailing & at the end of the command that runs the client);
Removed the delays in the script during the service stop;
Fixed the "default max states" information when it is not defined explicitally in the advanced configuration.

Should be the most stable LCDProc ever released… hope will fix (or at least minimize) the issues on all the boxes...

Thanks,
Michele

stephenw10

Nice! :)

One possible solution to the number of restarts might be to add some code to prevent a restart being called unless a change to the config has been made.
Currently:


			/* or restart lcdproc if settings were changed*/
			if(is_service_running(LCDPROC_SERVICE_NAME)) {
				lcdproc_notice("Sync: Restarting the service");
				restart_service(LCDPROC_SERVICE_NAME);

But in fact it restarts whether changes have been made or not.

Or possibly have two separate sync funtions, one that restarts LCDd when you sync lcdproc.xml and one the restarts the lcdproc_client.php when you sync lcdproc_screens.xml.

Maybe just something like this:
Replace:


function sync_package_lcdproc_screens() {
		sync_package_lcdproc();
	}

With:


function sync_package_lcdproc_screens() {
		if(is_service_running(LCDPROC_SERVICE_NAME)) {
		lcdproc_notice("Sync: Restart PHP Client");
		mwexec("ps auxw |awk '/lcdproc_client.ph[p]/ {print $2}'|xargs kill");
		mwexec("/usr/bin/nice -20 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php &");
		}
	}

That would at least reduce the times LCDd is restarted. I don't know if it actually has to do any syncing or whether that's all handled by the pfSense package system. ::)

Steve

stephenw10

Unfortunately it's not booting cleanly on the X-Core box. Imdediately after boot:


[2.0.1-RELEASE][root@x-core.localdomain]/root(4): ps aux | grep lcd
root    2368  0.0  0.6  3656  1356  ??  IN    1:15AM   0:00.05 /bin/sh /usr/local/etc/rc.d/lcdproc.sh start
root    4742  0.0  6.9 36188 16956  ??  SN    1:15AM   0:00.46 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
[2.0.1-RELEASE][root@x-core.localdomain]/root(5): ps aux | grep LCD
root   36882  0.0  0.5  3352  1148  ??  IN    1:15AM   0:00.01 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf
nobody 37026  0.0  0.6  3368  1472  ??  SNs   1:15AM   0:00.17 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf

The interesting thing is that the first instance of LCDd is still running as root because it fails to start correctly. Probably because it is trying to start on port 13666 but there is already an instance of LCDd running on 13666 at that point.
The odd thing is that it is not killed by the startup script hence the kill-loop gets stuck and lcdproc.sh is still running.

Steve

mdima

Hi Steve,
reading the documentation of LCDproc, the only thing that come to my mind is to insert some delays in the parallel port communication (http://lcdproc.sourceforge.net/docs/lcdproc-0-5-5-user.html#ppttrouble).
I think the sdeclcd driver do not accept this as parameter, the only way to do it is by code.

Do you think you could add some "DELAYMULT" in the driver?

Thanks,
Michele

stephenw10

@http://lcdproc.sourceforge.net/docs/lcdproc-0-5-5-user.html#ppttrouble:

Software Too Fast

If you have a super GHz computer it may happen that the signal timing generated by LCDd is too fast. Adjust DELAYMULT in the source file to a bigger value. Parallel port wirings usually don't permit to read back the busy flag of the controller chip, so timing must be adjust so that the controller never is busy.

I don't think this will help since the display runs perfectly once it's correctly started the server and client.

I tried removing the sync function for lcdproc_screens completely. I didn't help. It didn't reduce the number of LCDd restarts since it only restarts LCDd if it's already running and it isn't at that point.

More testing….

Steve

mdima

@stephenw10:

The interesting thing is that the first instance of LCDd is still running as root because it fails to start correctly. Probably because it is trying to start on port 13666 but there is already an instance of LCDd running on 13666 at that point.
The odd thing is that it is not killed by the startup script hence the kill-loop gets stuck and lcdproc.sh is still running.

This looks strange… were you able to save the service options from the interface in order to make the script to recreate the start/stop script? I say this because lcdproc.sh should not be visible anymore...

Also, if you run manually the script "lcdproc.sh stop" does it work?

Which options of killing do work for you? (for example, kill -9)

Thanks,
Michele

stephenw10

Once I have logged via ssh I can kill the extra LCDd process with any method. But is that because I am logged in as root?

I believe it is only still running because it is stuck in the kill loop. As soon as I have killed the process manually the rc script continues and creates another php client.

I've spent so much time thinking about this I ended up dreaming about it! ::)

Steve

m4f1050

Have you tried to sudo su the kill command? Is there such thing in FreeBSD 8.1?

mdima

Hi Steve,
I removed the "while cycle" in lcdproc.sh. Now the script should not loop at the startup. I checked both some rapid "service restarts" then a "reboot", at the end I only had one server and client running.

Btw, I think this it just a workaround, what is not clear is why in your case more instances of the client and the server are run at the startup.

I didn't update the version of the package, in order to get the change you should remove then install the lcdproc-dev package.

Please let me know if this solve your problem!!

Thanks,
Michele

stephenw10

I'll update and try that.
I tried removing the loop before and while it solved the stuck rc script I still ended up with two instances of LCDd, one running as root. :-\

Steve

mdima

Hi Steve,
mmhhh… can you send me your config.xml file? (of course, hide the password, public ips, and so on)

Ciao,
Michele

stephenw10

Here's my config file, password redacted, it's test box so it doesn't have a public IP.
I don't see it in my logs any more, possibly because the logging level is now back at 3 or I was using the 'debug' version of LCDd, but previously there was a line at boot something like:

LCDd: Could not open 13666, aborting

There is still a log line:

LCDd: Connect from host 127.0.0.1:58234 on socket 12

This implies that at some point there are two clients running.

Steve

config-x-core.localdomain-20120223131917.xml.txt

stephenw10

I have replicated some of my previous testing for reference.
Editing lcdproc.inc so that the resulting lcdproc.sh is:


#!/bin/sh
# This file was automatically generated
# by the pfSense service handler.

rc_start() {

	ps auxw |awk '/lcdproc_client.ph[p]/ {print $2}'|xargs kill
	ps auxw |awk '/LCD[d]/ {print $2}'|xargs kill
	/usr/bin/nice -20 /usr/local/sbin/LCDd -u nobody -c /usr/local/etc/LCDd.conf
	/usr/bin/nice -20 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php &

}

rc_stop() {

	ps auxw |awk '/lcdproc_client.ph[p]/ {print $2}'|xargs kill
	ps auxw |awk '/LCD[d]/ {print $2}'|xargs kill
}

case $1 in
	start)
		rc_start
		;;
	stop)
		rc_stop
		;;
	restart)
		rc_stop
		rc_start
		;;
esac

Results in after boot:

[2.0.1-RELEASE][root@x-core.localdomain]/root(1): ps aux|grep lcd
root   16096  3.0  6.9 36188 16980  ??  SN    1:41PM   0:00.27 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
root   16748  3.0  6.9 36188 16980  ??  SN    1:41PM   0:00.27 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php
[2.0.1-RELEASE][root@x-core.localdomain]/root(2): ps aux | grep LCD

And in the system log:


Feb 23 13:41:31 	LCDd: Critical error while initializing, abort.
Feb 23 13:41:31 	LCDd: sock_init: error creating socket - Address already in use
Feb 23 13:41:31 	LCDd: sock_create_inet_socket: cannot bind to port 13666 at address 127.0.0.1 - Address already in use

Which implies this wasn't happening before.

Steve

mdima

mmhhh… Steve, stupid question.

Are you sure that somewhere there is a script that runs the package at the startup, as a surplus of the times where you had to run LCDproc manually because it was not compatible with the sdelcd driver?

Did you start from scratch with this test box?

Thanks,
Michele

mdima

Hello everybody,
any update on this package? None is using it or it's considered running and stable?

Thanks for any feedback,
Michele

stephenw10

Sorry, not much spare time for testing.
As it stands, although it doesn't start cleanly, it is fully functional on the X-Core. The additional LCDd hardly uses much by way of resources and it sorts itself out the first time one of the interfaces changes. So if you are using a ppp WAN then when the address changes all packages are restarted and it come up clean.

My test box is a new install of 2.0.1 with no changes other than adding lcdproc-dev and some firewall rules so I can access it via the WAN interface for convenience.

Steve

Brak

I can only get lcdproc-dev to not crash-loop on my Firebox X Core when I spam the left arrow button and hope I can get the lcdproc menu to open up. I do this right after I restart/start the service. If I get the menu open, everything then works fine when I exit the menu.

I also have the issue of if an interface goes down, lcdproc crashes and attempts to restart.

mdima

mmhhh… what about all the people with non watchguard products?

eventually, do anybody has a firebox to lend me? I promise I send back after I check/fix/give it up...

stephenw10

Hmm, expensive shipping to Milan. Might be cheaper to just buy you one from Ebay! ::)

Steve

mdima

Well, yes, but the shipping would be expensive anyway, plus I get a firebox I don't need… :D

really, this for me is a kind of hobby, and spending (the cheapest I found from Australia) 250 Euro to fix this is really a challenge... :D

Do you think we could involve watchguard for this? Or someone to share the send/return shipping costs...

stephenw10

We can definitely get one cheaper than that. The X-Core box I have here has become a bit temperamental. I'll keep a look out for another one.

Steve

stephenw10

Here's a suggestion, while reading through some other bootup scripts I found this:


// Do not process while booting
if($g['booting']) 
	exit;

Perhaps we could use this somehow to limit the number of reloads? Of course it could easily stop it loading at all. ::)

Steve

mdima

Good hint, thanks!! I will make some experiments with it and let you know…

Ciao,
Michele

marcelloc

@stephenw10:

Here's a suggestion, while reading through some other bootup scripts I found this:
// Do not process while booting
if($g['booting']) 
	exit;
Perhaps we could use this somehow to limit the number of reloads? Of course it could easily stop it loading at all. ::)

Steve

It's on dansguardian as well but I did not saw changes on bootup time or times it tries to restart daemon.

What I did was changing reload option to stop and start.

I'm not sure about That but it looks like pfsense bootup script calls sync_package function for every xml file on package. Dansguardian has about 20 XML files and It's boot takes more then a minute in start / stop calls.

Something I'll try is to do not stop/start daemon if uptime is less then 01 minute for example or check if last stop/start call has less then x seconds.

fmertz

I have a test driver with LED support. It's been tested some on X-Peak and X-Core-e models, but there is code for X-Core as well. The updated FreeBSD driver is here:

https://github.com/downloads/fmertz/sdeclcd/sdeclcd.so

Once up and running, telnet to lcdproc (pretend to be a client) and type

telnet localhost 13666
hello
connect LCDproc 0.5.5 protocol 0.3 lcd wid 20 hgt 2 cellwid 5 cellhgt 8
output 1 <—Short red blink about every 4 seconds
success
output 2 <—Short green blink about every 4 seconds
success

The output logic is this: we have 32 bit to work with, and we need 3 states (Red, Green and off). This is 2 bits. So, in 32 bits, I have 16 time slots to work with. So, basically, code in the LED sequence of colors you want to see (Red, Green or off) and keep filling in the groups of 2 bits by shifting. the sequence just repeats indefinitely.

Worksheet:
XXXX XXXX XXXX XXXX, X is 0,1, or 2, and represents 2 bits

0000 0000 0000 0001 is slow short blink red
0101 0101 0101 0101 is fast short blink red
0011 0011 0011 0011 is medium medium blink red
0000 1111 0000 1111 is slow long blink red
0000 2222 0000 1111 is slow blink alternating between red and green, and off in between

The representation above needs to be made decimal for the “output” command. Sequence is about 4 seconds.

Thanks for letting me know if this works out for everyone. Would be nice to work this out into the PHP client, too.

easyhugo

@easyhugo:

@mdima:

@easyhugo:

Hi Guys

Is it possible to ad this Lcd to

http://allnet.de/1577.html?&tx_mmallnetproductplugin_pi1[showUid]=421433&cHash=949c8a38a8
ftp://212.18.29.48/ftp/pub/allnet/utility-server/fw8888/lcm_server_1.0.tar.bz2

i,m trying this for some time but with no success, see other posts from me

thx max

Hi Max (easyhugo),
it's impossible to know for me which driver this LCD panel uses… do you know the chipset? Can it use one of the drivers already made or you need another driver?

Ciao,
Michele

Hi
sorry but no driver work with this display, it does not work without these lcm server.

@stephenw10:

My German is very bad! :-[ (Only beaten by my non-existant Italian! ::))

However, according to [url=http://www.ipcop-forum.de/forum/viewtopic.php?f=22&t=26948#p231301]this post by IPCop ledgend Wintermute the display in the FW8888 is an LCM-162.

This doesn't appear to be supported directly by LCDproc but this blog post seems to show it is possible. That's quite old now so support maybe better integrated.

What drivers/versions have you tried?

Steve

Edit: This post confirms this.

and yes wintermute is an excellent ipcop programmer, but ipcop is not an freebsd os so i cant copy the files .
i have tried to copy the lcm to the pfsense and change the config files but with no success.
my test with these lcm if i tried the dev version was not born :D so at now i will connect the guys from allnet how this lcm will work
the answer i would then post

thx

edit:
from the lcm pckage:

Make commands:
Static binary:
gcc –static -o lcm_server lcm_server.c

Dynamic linked binary:
gcc -o lcm_server lcm_server.c

Execution command:
lcm_server /dev/ttyS1 "Banner"

Command FIFO:
/var/run/lcm_cmd

Available commands:
Clear -- Clear the LCM display
Home -- Set the cursor back to row 0, column 0
Display {on/off/nocur} -- Turn display on, off and on without cursor
BKLight {on/off} -- Turn LCM backlight on and off
Setpos {0~1} {0~15} -- Set the cursor position to row and column
Write {text} -- Write the text to LCM start from
current cursor position
Examples:
echo "Display oncur" > /var/run/lcm_cmd
echo "Setpos 0 0" > /var/run/lcm_cmd
echo "Write test message" > /var/run/lcm_cmd

Key FIFO:
/var/run/lcm_key

Available keys: UP, DOWN, RET, ESC

Example:
cat /var/run/lcm_key

Note: There is no key de-bounce mechanism on LCM.
Multiple key response may happen while receiving keys.

hi

the guys from allnet are not the fastest, no response to my mail from 18.2.2012
so google is now my friend angain to my problem with these lcm server on fw8888

in found an interesting site http://www.tecnowledge.net/2009/06/getting-lcdproc-to-work-with-an-lcm-162-freebsd/
how the managed these lcm server in freebsd
this description are from 2009 with an lcdproc version 0.5.2 but now im not sure if these changes are now included

thx max

max

stephenw10

In a parallel discussion we have established that the lcm-162 is in fact almost identical to the firebox lcd (or at least the nexcom display is).
Try using the firebox sdeclcd driver and see if you get anything at all.

Steve

fmertz

Execution command:
lcm_server /dev/ttyS1 "Banner"

This tells me the interface is serial, not parallel. Good old RS-232. My SDEC LCD driver will not work.

Looking through the code here:```
ftp://212.18.29.48/ftp/pub/allnet/utility-server/fw8888/lcm_server_1.0.tar.bz2


It seems like the commands for the LCD are the "usual" set (same as SDEC LCD, and possibly HD44780). Being serial interface, you can give a shot to the HD44780, part of lcdproc. You will have to read the documentation for the driver to properly configure it for your display. The reward is that, once working (if it does), then clients like lcdproc itself, or the pfSense PHP client will work, too. Good luck, and keep us posted.

PS: [http://www.tecnowledge.net/2009/06/getting-lcdproc-to-work-with-an-lcm-162-freebsd/](http://www.tecnowledge.net/2009/06/getting-lcdproc-to-work-with-an-lcm-162-freebsd/) is for a parallel port interface, not serial.

mdima

Hi fmertz,
well, if the command/behavior is the same, maybe the sdec driver could accept the port as parameter from the client (there are already serial and parallel ports). Just an idea…

Ciao,
Michele

fmertz

This would require new code. The parallel interface is driven directly with in/out machine language commands. Serial ports are typically coded with more abstraction, i.e. treated like files. At this point, let's see if the HD driver will do…

LCDProc 0.5.4-dev

Products

Services

Support

News

Resources

Company

Our Mission

Subscribe to our Newsletter