EZIO Driver for LCDproc

grahama

Yep, RTFM :-[

New line works a treat, thanks!

Actually, I tried to read the specification, but the link "http://drivers.portwell.com/CA_Manual/EZIO/EZIO-FINAL.PDF" no longer works.
Couldn't find any other links to EZIO-Final.PDF online either which is unusual.

I have now installed the driver (and maybe fixed something with cron) and now LCDd / lcdproc / lcdexec are all working - buttons worked to navigate the menu and change settings.

It didn't work after a reboot, so I have to work that out, but I'm happy that I've been able to re-utilise all of the hardware :)

update: /usr/local/etc/LCDd.conf was overwritten on reboot, losing my changes.
I'm finding this aspect of pfSense to be frustrating as well as it's use of tcsh. I'm yet to customise these things to suit my preference.

fabricioguzzy

Hello Everyone,
I am facing problems to make lcdproc work.

I got a LCD Display "HD44780 Compatible" connected via FTDI USB (Chipset is FTDI 245) - It works fine on Windows so I know the display is fine.
Now trying to make lcdproc work is being really difficult. The Service does't stand up in anyway and I can´t find any LOG for troubleshooting.
Could anyone help me with that?

Reading other posts I could find the hd44780 driver that comes with pfsense 2.3.4 is wrong. is it true? I tried to replace it with no sucess.

Any help will be really appreciated.

Thanks
FAbricio.

stephenw10

This thread is for the EZIO display only. I have replied to your post in the main LCDproc thread.

Steve

regexaurus

Working here on a SmoothWall UTM-300 (Caswell CAR-3030)

At first it seemed not all the display buttons were working, but after hitting ESC (maybe a few times?) a menu appeared that I could navigate through to change settings (e.g. disable heartbeat, etc.). Relevant sections of my LCDd.conf:


[server]
DriverPath=/usr/local/lib/lcdproc/
Driver=hd44780
Bind=127.0.0.1
Port=13666
User=nobody
WaitTime=5
ToggleRotateKey=Enter
PrevScreenKey=Left
NextScreenKey=Right

[hd44780]
ConnectionType=ezio
Device=/dev/cuau1
Keypad=yes
Size=16x2
KeyMatrix_4_1=Enter
KeyMatrix_4_2=Up
KeyMatrix_4_3=Down
KeyMatrix_4_4=Escape

Is this pretty much a manual thing for now, or can we use it with LCDproc in WebGUI?

Thank you!

stephenw10

Nice GIF. ;D

Boyer1701

OMG THANK YOU - this thread is what caused me to register for this forum - the driver works like a charm, amazing!
(Caswell CAR-3000 board)

ColdStoner

Love to see this!! I was previously getting by w/ the lb216 and the hex dump method.

Anywho, I've downloaded HD44780_EZIO_Driver_pfSense2_3_32bit.zip and have extracted the .so to the specified location…

however I am getting an error when starting lcdproc:

Could not open driver module /usr/local/lib/lcdproc/hd44780.so: Shared object "libftdi1.so.2" not found, required by "hd44780.so"

I'm not sure how to get that library installed on pfSense... Ideas?

stephenw10

Are you running 32bit 2.3.X?

Though that file doesn't seem to be present anyway. Are you sure you selected the correct driver and connection type? Can we see you lcdproc.conf file?

Steve

fmertz

@ColdStoner:

Could not open driver module /usr/local/lib/lcdproc/hd44780.so: Shared object "libftdi1.so.2" not found, required by "hd44780.so"

I'm not sure how to get that library installed on pfSense… Ideas?

This is more of a freeBSD thing. You need to add the libftdi1 library. You need to look into the package manager, but it is probably going to look like this, as root: "pkg add libftdi1" (lib FTD (eye) (one). Confusingly, there is also the older version, libftdi, which is not needed here.

Best of luck, keep us posted.

stephenw10

Not sure why you'd need that unless you are using a USB/serial adapter though. And in that case it would still have needed it using the previous manual method. :-\

Steve

ColdStoner

I too am a bit perplexed as to why it needs this particular library, but Ill keep on keeping on tho.

Ill look at turning up a BSD 10.3 box and pulling it from there. I cannot get it to install from with in PF returning a "no package availible"

Thank you.

fmertz

It sort of gets to the heart of things. My (somewhat superficial) understanding is that most LCD panel out there (as in actual stand alone screen) have to be somehow controlled so that characters show up, there is a sense of rows and columns, etc. For mostly historic reasons, most chips that do this are either original HD44780 or later, backward-compatible with the this same HD44780. In a sense, this HD4470 is a standard. Now, if you look at the details of the chip (the datasheet can be found), the front side of it does not really have anything typically found on a PC (like USB, or serial, etc). Some form of an interface circuit has to be present. This is why these HD44780 chips need to be "behind" some other form of interface like parallel port, serial, USB, etc. Then add the dimension that this driver code runs on non-PC architectures as well (e.g. RaspberryPI, etc), and then even more hardware interfaces start to make sense.

Altogether, the software driver for the HD44780 in the lcdproc project sort of mirrors this state of affairs. There is basic HD44780 logic built in, but the reality is that the code is geared towards supporting these very many types of hardware interfaces. Fortunately, some require just code (available from the standard C library), or require direct control (like parallel port). On the flip side, others are best handled by using libraries of pre-existing code. These libraries then become dependencies.

Bottom line, these dependencies allow the same driver to support a lot of different hardware connections at run time, based on config files. The downside of the current setup is that these libraries are, in a sense, hard dependencies, so need to all be present at run time to even load. This is independent of actually using said interface.

In the present, these dependencies are determined at build time. The build system detects the presence of these libraries (on the build system) and makes that fact known to the code. When the code is compiled, these libraries are turned on, and the corresponding feature is turned on (as well as become a dependency). This build feature can of course be controlled with command line options, so even if the library is available at build time, it can be ignored so the dependency does not appear in the resulting code.

The right answer for this is of course making a proper FreeBSD/pfSense package available. It is also possible to make multiple packages available as well. Each package can be compiled with increasing number of dependencies. There can be a base package with no dependencies (except what libraries come with a "naked" system), all the way to a full package that lists all the necessary dependencies.

Here, I am trying to help out by supplying simple binaries. I suspect once there is an official lcdproc version update, the official pfSense maintainer will step forward and compile an official lcdproc package.

If installing these dependencies becomes too much of a hassle, I can re-build the binary with fewer dependencies. Let me know.

stephenw10

Mmm, it does seem odd that your hardware would require it though where as others, like device I have, does not.

Are you using the standard EZIO LCD? Or is it somehow custom?

Steve

fmertz

OK, I rebuilt this driver with fewer dependencies:

$ ldd server/drivers/hd44780.so
server/drivers/hd44780.so:
        libkvm.so.6 => /lib/libkvm.so.6 (0x28205000)
        libc.so.7 => /lib/libc.so.7 (0x2806f000)

File:

$ file server/drivers/hd44780.so
server/drivers/hd44780.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped

Let me know…

hd44780.zip

evilgoat76

I realise I'm a bit late to the party here… I have a confession to make...

I'm partly responsible for this abortion in so much as I didnt shout loud enough about how bad this display is. I worked for Smoothwall at the time and did some work on making this POS work and documenting the API for the developers. I hated it then, now I'm trying to make it work again I hate it even more.

I argued that this diaplay was way more work than was needed and redid the firmware for the board to handle the init and behave as a bog standard serial TTY. I also designed a much nicer, smarter board to sid on the back of the LCD.

Sadly marketing called the shots on the inital design and alsthough the subsequent units followed my spec the evil LCD seems to have remained. I actually quit over this damn appliance!

I have somewhere:

MPLAB ASM for an update to the board thats there with a new, nicer firmware. Certainly on the inital board the ICD header could be gotten to.
Eagle Cad drawings and firmware for a new backpack board. The new board behaves as a bog standard serial TTY, nothing special. Simple and easy to do. It did have support for aux IO and sensing LED states.
The Delphi source code showing how to handle these things and my notes.

I have moved house twice since then. I can picture the folder this lot is in and the dvds are in there with my dev machine backups. In the event I can find them, everything was done in my own time so nothing actually belongs to them and I'll hapilly turn it over, however it does sound like you have it all resoved now. I was just a few months too late.

It is possible, this is also in the code to GPL3 too. Smoothwall Express/GPL was always a version behind, so Express 2 was Corp Server 3, Express 3 was CF/AF 4.0. 4.0 had a rollup that added support for the UTMs so its not beyond the realms of possibility that the LCD code is actually in there.

fmertz

Interesting story, thanks for posting. If you are at liberty to share, to your knowledge, are there any "undocumented" codes we could supplement the driver with? Something like controlling the backlight, or contrast with codes? Thanks.

stephenw10

Ha, that's great. ;D

In other news I have an EZIO-G500 but can find zero documentation for it. It does seem like you can just write to the serial port and it displays stuff but no formatting etc. Fun.

Steve

evilgoat76

@fmertz:

Interesting story, thanks for posting. If you are at liberty to share, to your knowledge, are there any "undocumented" codes we could supplement the driver with? Something like controlling the backlight, or contrast with codes? Thanks.

No Sadly they are pretty basic things. The code consisted of what was basically a RS232 to HD44780 and an overcomplicated keyboard module. It is pretty basic and from what I can see you have gotten all of it. IIRC the modules I looked at had no backlight support. This is one of the reasons I said no to them. The lead dev at the time was less than impressed as he spent two solid weeks polishing the Smoothwall drivers to make them play right. I could alse email the lead dev directly and ask if he would share or contribute to the LCDProc driver. He is VERY pro open source.

IF the interest is there as I have the board footprint I can sort a drop in replacement module if anone wanted to go this route. Things have come on since they were spec'ed (About Mar 2005 IIRC) and I could easilly do a new PCB and host it on OSH park so people can order boards to do themselves. Of the tops of my head the PCB cost would be about $20 for 3.

If anyone wants me to look into this just say and sensible suggestions for features.

evilgoat76

I have reached out to the lead Dev and asked what code from SmoothWall can be shared if any.

stephenw10

Can't thank you, have some karma instead. :)

Steve