EZIO Driver for LCDproc

fmertz

Thanks, good to hear confirmation that it works on the real hardware. I was developing this on an ARM NAS (running Debian Linux) with a USB/Serial adapter.

At this point, the code change has been merged upstream with the lcdproc project: https://github.com/lcdproc/lcdproc/pull/82

I assume the pfSense maintainers will pull the lcdproc package after the next release, so everyone can use these EZIO devices right out of the box.

The only "open item" is a (minor?) change to the pfSense lcproc PHP package to include this connection type in the pre-defined list…

grahama

Thanks for your efforts here. This thread has made me join this forum.

You've helped me to make use of the LCD panel on a "Smoothwall S4" that I bought 2nd hand. Smoothwall didn't work for me, so I've been using pfSense for a few days. So far, it's meeting my needs.

I do have LCDproc enabled, but it doesn't run for some reason. I haven't been able to work that out yet nor make use of the menu buttons.

But what I have done is used the stty command and hex file Steve provided to initialise my LCD successfully.
I then have a cron job which keeps the screen updated with CPU temp and time every few minutes.

So thanks for that.

If needed, I can expand my simple shell scripts to show any statistic I can get to fit on the ?32? characters :)

Does anyone have tips for writing on the second line neatly? Right now I just pad in 20+ characters to cause word wrap to happen.

Cheers,
Graham.

fmertz

@grahama:

Does anyone have tips for writing on the second line neatly?

It's in the spec. You can put the cursor at the beginning of the second line with something like this:

printf "\376\300" > /dev/cuau1

From the larger perspective, though, you might want to download and replace the hd44780.so driver file so you have the new code for this EZIO device (make sure you pick the right version for your OS, these files are attached to the first post in this thread). Then make sure LCDd.conf is updated, in particular the device and connection type. As noted above, this code is not available in pfSense, yet, and the glue pfSense package has not been updated either so this new "ezio" connection type is not showing as an option in the GUI. You seem familiar with the command line, though, so this should not be too much of a problem to get up to speed.

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