LCDProc 0.5.4-dev
-
Truthfully, I'm not sure. The driver is for 0.5.2, and that's what I've used it with. I didn't seem to be able to get 0.5.4-dev working with it, but I don't know enough about the package to be able to get it working.
I would assume tho it would be better to call it the "Lanner LCM" driver/port since it's neither the HD44780 spec nor the LCM-162 spec (at least the comments on the patch make it seem that way.)
well, if the driver is for 0.5.2 I don't think it will work for 0.5.4. But if someone could compile it for 0.5.4 I could integrate with the name you just told…
Ciao,
Michele -
Brak,
If you can make the Lanner hardware available to me, I can come up with proper driver code for it. This thread is labeled 0.5.4, but I think the lcdproc-dev package is actually on the current production release 0.5.5 (New development is done against 0.5dev). We probably have enough of the base functionality to take it from here and get it working completely. I would hope we could get the big clock, vbars, hbars, maybe even special characters and menus. If there are enough differences with an existing driver (HD or sdeclcd), then I can submit a patch upstream so this would become supported going forward. I would make the driver against 0.5dev, and backport it to 0.5.5. I could test Linux and FreeBSD, and compile with OpenBSD and NetBSD to be sure. Let me know.
-
I have it working with the 0x378 port. My problem is, that on every reboot my LCDd.conf file is overwritten. Esp. the line ConnectionType=winamp is reverted ti ConnectionType=lcd2usb. How can i make my changes permanent ?
-
The LCDd.conf file is generated each time the package is synced, which happens when ever the service is started.
If the required connection type is not in the package yet then you would have to edit /usr/local/pkg/lcdproc.inc to include it (or ask someone else to).It's interesting though that only one connection type (encoding type?) is available for hd44780 when there are many supported.
@LCDproc:
The HD44780 driver supports various ways of connecting HD44780 devices to your system. Each of these different ways is called a connection type of the driver.
On a parallel port, probably the first interface type HD44780 devices were historically connected to, the driver supports the connection types:
4bit: 4bit Wiring
8bit: 8bit Wiring ("lcdtime")
winamp: 8bit Wiring "winamp" Style
serialLpt: Serial LPT Wiring
For serial RS-232 ports you can choose among these connection types:
picanlcd: PIC-an-LCD serial device
lcdserializer: LCD serializer
los-panel: LCD on Serial panel device (http://www.xs4all.nl/~mlf/los/)
vdr-lcd: VDR LCD serial device
vdr-wakeup: VDR-Wakeup module
In recent years, with with parallel ports and serial ports being declared legacy and on the demise on modern computers, the USB connection types get more important. Here are the USB connection types the HD44780 driver supports:
pertelian: Pertelian X2040 LCD display (http://pertelian.com/joomla/index.php?option=com_content&task=view&id=43&Itemid=48)
bwctusb: BWCT USB LCD module (http://www.bwct.de/lcd.html)
lcd2usb: Till Harbaum's LCD2USB (http://www.harbaum.org/till/lcd2usb/)
usbtiny: Dick Streefland's USBtiny (http://www.xs4all.nl/~dicks/avr/usbtiny/)
uss720: Display connected to USS-720 USB-to-IEEE 1284 Bridge (Belkin F5U002)
lis2: LIS2 from VLSystem (http://www.vlsys.co.kr)
mplay: MPlay Blast from VLSystem (http://www.vlsys.co.kr)
ftdi: Display connected to a dual channel FTDI 2232D USB chip
usblcd: USBLCD from Adams IT Services (http://www.usblcd.de/)
Last but not least, for special purposes, there are even more connection types:
i2c: LCD driven by PCF8574(A)/PCA9554(A) connected via I2C
ethlcd: Display connected via TCP to PoE powered ethlcd device (http://manio.skyboo.net/ethlcd/)
-
I have it working with the 0x378 port. My problem is, that on every reboot my LCDd.conf file is overwritten. Esp. the line ConnectionType=winamp is reverted ti ConnectionType=lcd2usb. How can i make my changes permanent ?
Hi Macom2007,
I will release a version of the package with the driver "HD44780-winamp", so you won't have to change it manually on every reboot…I let you know when the new release is online!
Ciao,
Michele -
Hello
I have a Nexcom NSA3110 and NSA5130 both of which have the same LCD assembly. The display works great on both but I can't get the keypad to work. Are the drivers for the keypad seperate from the LCD? Has anyone gotten the keypad for the Nexcom to work? Any help would be appreciated.
Thank you
-
I have a Nexcom NSA3110 and NSA5130 both of which have the same LCD assembly. The display works great.
What driver/connection combination are you using? I assume this is with the lcdproc-dev package in pfSense…
-
scratchi,
try to change the menu section of the lcdproc.conf file using the following data:# If you have a keypad you can assign keystrings to the keys. # See documentation for used terms and how to wire it. # For example to give directly connected key 4 the string “Enter”, use: # KeyDirect_4=Enter # For matrix keys use the X and Y coordinates of the key: # KeyMatrix_1_3=Enter KeyMatrix_4_1=Enter KeyMatrix_4_2=Up KeyMatrix_4_3=Down KeyMatrix_4_4=Escape
this is the only information I found on the nexcom.so driver. Unfortunately the nexcom driver is not in the official release of LCDProc, so it's hard to know what is its code and if it respects all the LCDProc directives…
Ciao,
Michele -
Truthfully, I'm not sure. The driver is for 0.5.2, and that's what I've used it with. I didn't seem to be able to get 0.5.4-dev working with it, but I don't know enough about the package to be able to get it working.
I would assume tho it would be better to call it the "Lanner LCM" driver/port since it's neither the HD44780 spec nor the LCM-162 spec (at least the comments on the patch make it seem that way.)
well, if the driver is for 0.5.2 I don't think it will work for 0.5.4. But if someone could compile it for 0.5.4 I could integrate with the name you just told…
Ciao,
Michelehi guys
are these good news for me and my allnet fw8888 ore not???
my eforts to intergrad these driver (lcmserver) stops very quicklythx max
-
I really hate to bring up a topic that has been asked before, but I am going to anyway. ::)
I have a portwell NAR 5060, that has the MTB134 (aka EZIO-100) lcd in it. Is there anyone that can get this thing to work with LCDPROC? I see Mikrotek RouterOS supports it, as well as Untangle. There has to be someone who can convert it over.
Pretty please!!! -
Here is a .pdf from portwell with all the data on the EZIO. Maybe someone could use it to make a lcdproc driver for it??????
-
That link doesn't offer much but this does:
http://lists.omnipotent.net/pipermail/lcdproc/2004-January/008494.html :)
Looks like it was never updated for 0.5X though and didn't meet the requirements to be included in lcdproc. Would be a good place to start for someone who knows what they're doing! ;)Steve
-
I already had the link you posted, but just found this. I thought the command functions, as well as the sample c style control program might offer some info.
-
I have a advantech appliance with an lcd on serial 2x16 but i do not know how to configure lcdproc
if someone can help me with this lcd
I posted an archive from their websitethanks
p.s: please delete extension .txt
-
Using the .txt extension causes the file to be corrupted, use .png instead.
Steve
-
ok ..
now it is ok -
The LCM-100 appears to be virtually identical to the early version EZIO/MTB-134. As such no driver exists for lcdproc 0.5X. Yet. :(
Steve
-
thanks….I will use it under linux
but i have another appliance fwa9106 with sample code in attach -
Perhaps I'm not searching for the right thing, but is there any way to keep the backlight on?
I'm using a firebox X-series and it works great with the new dev driver, but considering the rest of the rack never disables the backlights on the status lcd's I'd prefer to be able to read the traffic monitor at a glance, without waking it up. -
The backlight on the firebox LCD is deliberately always on a timer. This is because at least some of the boxes have an LCD with a limited backlight life and most of these boxes have already seen thousands of hours use. There are quite a few reports of failed backlights on the x-core thread.
I'm in favour of allowing users to take the risk as long as they have the facts. The current driver does not have the option though.Steve