EZIO Driver for 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?
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.
-
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
-
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.
-
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.
-
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
-
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 strippedLet me know…
-
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.
-
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.
-
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
-
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.
-
I have reached out to the lead Dev and asked what code from SmoothWall can be shared if any.
-
Can't thank you, have some karma instead. :)
Steve
-
To my (superficial) knowledge, the serial-to-HD44780 interface is implemented with a programmable micro-controller. Is that code available, and shareable? I always wished I could see that code to see if there was any optimization that could be performed.
FWIW, lcdproc.com has an example of a similar implementation, and the micro code is shared.
-
To my (superficial) knowledge, the serial-to-HD44780 interface is implemented with a programmable micro-controller. Is that code available, and shareable? I always wished I could see that code to see if there was any optimization that could be performed.
FWIW, lcdproc.com has an example of a similar implementation, and the micro code is shared.
I may have it. I'm going to go and grab that folder from storage aqt the weekend. From memory the code initalises the PIC, does the usual register bits then sits in a loop with the RCIF interrup enabled.
If there is a serial interrupt the char is read and simply stuffed out the port with the relevant work to the control line. R/W is tied in read only mode so you cant actually 'talk' to the display, its one way.
There was then the non-braindead version where the keypad matrix was scanned and on a keypress a char was simply punted out the serial port, I dont know if this made it out into the wild, the suggestions in here with the status request type messages suggest it didnt. I didnt do much with the keypad but my understanding from the dev was that the polling method is the correct way of doing it.
The chip used was a PIC16F628A with (for some reason) an external oscillator. If you take the early boards off the back of the LCD, there was a connector marked P5. Attached is the raw hex file from the original. Again, on the eval (this may have changed) The code protection bits were NOT set. I also go back on the lack of backlight control I think it was actually possible, there were two transistors on the back but I dont remeber their function. The display is (for some reason) driven in 4 bit mode just to make things easier.
Reprogramming this with an ICD2/PicKit would be trivial
The last PCB drawing no in my notebook is B9303367AI3200824, I've writen releasae next to it so I'm guessing thats whats out there.
IF Any of mine got out they would be M123406, and they are addressed as a TTY @ 9600bps
The chip is the same we use in a lot of our vehicle control systems so its a capable device. A new firmware is not beyond the bounds of possibility and probobly not a lot of work. I'm half tempted to go rip the one in my appliance apart and experiment. How many people actually have the ability to procran the Ic? I can go totally to town on the chip as I know it inside out but I know stuff all about the driver side of things and *nix.Attachment is an intel .hex file suitable for MPLAB
-
Fascinating. Everything I have seen with these devices is 2400 bps. Yes, 2400!
For the keyboard, you have to send a command to get the status. Then the PIC sends a response with the status of the keys.
What would it take to program one of these? I mean once we had a compiled file, would something like an arduino be able to push it in the PIC? Enhancing the code while still using the existing hardware seems like fun, and some folks might actually use this…
-
This is great. :)
I think it might be a tough sell if the change broke compatibility with the original OS. Though personally I won't be going back.
Still never seen the keys work on the display I have for some reason.
Steve
-
Fascinating. Everything I have seen with these devices is 2400 bps. Yes, 2400!
For the keyboard, you have to send a command to get the status. Then the PIC sends a response with the status of the keys.
What would it take to program one of these? I mean once we had a compiled file, would something like an arduino be able to push it in the PIC? Enhancing the code while still using the existing hardware seems like fun, and some folks might actually use this…
Pulled the one in my unit out and had a poke, the board has changed a little, one of the driver transistors has been removed, I dont know why it was there I suspect to spread the load of the backlight. You could use PWM here and control the brightness. I've never seen these with the backlight off but it would appear there is the facility.
What is really interesting is the contrast pot, or rather, its lack. There is now a digital pot on the board, ISL90728W so the contrast may be adjustable.
This suggests one thing right off the bat, there IS a later version than the last I saw and there IS more going on than serial to parralel. I suggested to thge MFR at the time that escape style codes could be used and my one I did just that.A look at the disassembly shows there is more in the IRQ routines than I recall, the hex dump is from this display so i'll do a diff when I have the old one. This does however confirm there is a 3rd version of this damn thing. Disassembling this will take a bi as it'll need commenting and to be fair, its not THAT well written.
I have sucked the code off, they still dont set the CP bits. I've also wiped it, verified its blank then reflashed it so J5 on the back is a standard Microchip ICD port. Your choices are:
PicKIT 2, 3 and ICD2/3 or anything newer. The ICD2 has some 'issues' with Win64 so mine is long gone. My PicKit 3 is a cheap china special and works. Yes you can use an arduino to burn the chip too, google is your friend.
The hardware looks straight forward as I remeber it. The 4 bits of display data are on RB4 thru 7. Remaining ports pins drive the 'new' I2C pot chip. RA1,2, 3,4 and 5 are the key matrix. If you wanted to investigate dead keys this is your spot. RA1 and RA2 look to be used to also drive RS and !E to the display.
I will verify the board layout over the weekend.
New firmware should be easy….
Init the chip
Init the LCD
Enable interrupts for serial
Sit in a loop and see what comes bacl when you twoddle the colum lines. Store this and if it changes stuff a keycode out the UART
Deal with IRqs as they happen, test what you have, if its <32 its a control code, go deal with it, else spit it out to the lcd.I'd suggest (as I did at the time) all non printables like BS, clear, home cr lf etc did as they should
ESCn then can be used for the backlight, contrast etc.
One fly in the ointment is that the pot is volatile. Now the EEPROM has a finite life, anyone thats had an older Audi knows where this path leads. The thing seems to be biased by resistors to give a good screen contrast out of the box so its not an issue so would we be happy sending commands to set contrast? Do we even want that facility? (I hate bit bang I2C)IF I were a gambling man I'd suggest the matrix or ribbon on stephenw10's is either out of the FPC connector or duff. Dont be tempted to clean the connector end of the ribbon with anything chemical, you'll annihalate the contacts. Do check the little black plastic 'gate' is on and not kicking around loose in the box, these did come off in transit before now. If it has pop it back on and a bit of Kaptan tape will keep it there. Two screws in the base plate of the module and one in the lip of the case and the whol lot pops out as a unit and you can see the button pads.
-
Circuit diagram for current version. It seems that the change I suspected was a pot is actually an improved RS232 driver.
The backlight control powers the WHOLE display down, so on returning backlight you'll be required to send another init sequence. The now missing Q2 is simply a load sharing setup, it WAS a way to do PWM on the backlight. The tracks have been merged into one larg polygon for some reason, I can se ethe old PTHs are still there for both tracks so this may be an error tahts disabled backlight control hence no point fitting Q2.New firmware should be easy. I do now have to re-assemble this unit and prepare it for its new home but soon as its gone I'll get a hold of another and/or see if this will mock up in PICsim easilly.
Unless someone wants to loan a display assembly?
StephenW10 - all you need to meter out the keyboard membrane is here.
-
Could you post a picture of your device? I took a look at mine a couple nights ago and could not really see the programming header, etc. you are talking about. My device has a sticker on the micro-controller that says "02A", which I think refers to the more recent firmware version. This is also referred to in the documentation. I acquired my display stand alone off of eBay. I do not have the appliance it was installed in. I'll post pictures of mine, too.
-
Mmm, wondering if this was customised for the Smoothwall boxes. That display is used in a number of other firewalls as well as Portwell's own gear.
Steve
