Help identify lcd display on Smoothwall SWG700 [Edit: Portwell EZIO]



  • I have been using pfSense for some time on watchguard x750e. I recently got a used Smoothwall SWG700 for a good price, with a bit more power than the x750e. I could install pfSense on the unit but could not get the LCD to display. I know a little about lcdproc dev, from reading on this site. I would like to get LCD to display status information and have tried different settings but got nowhere.

    I tried to get help from open source smoothwall section, seems they are not really open. I think they want my first born. You can do a search on swg700 on their site and you will see what I mean.

    Can someone please help me ID this screen? Is it usable on LCD proc dev? The original smoothwall OS on the unit seems to work well.

    Its a serial connection with only 3 wires on com port 2. Looks like it get power directly from the power supply. Here's what it looks like. Thanks you.






  • Hmmm  :( :( :(. I think on the picture, it looks a lot like the LCD on a Check Point UTM-1 270. Anyone got this UTM-1 270 LCD working? Check Point is a popular brand, I'm sure someone here has it working. Please help.



  • Did you ever get this to work as I have the same LCD?


  • Netgate Administrator

    I looked at one of those a while back. It's almost certainly this:
    http://www.portwell.com/products/detail.php?CUSTCHAR1=EZIO-300

    I never found a way to make it work with lcproc. They seem to have their own custom protocol there. Potentially someone could write a driver….
    http://drivers.portwell.com/CA_Manual/EZIO/portwell_EZIO_300_UserManual.pdf

    Steve


  • Netgate Administrator

    My interest was toggled.

    Still no way to make it work with lcdproc but I did find a couple of new pieces of information that at least allowed me to confirm the screen operating.

    Firstly the rs232 module operates at a blistering 2400bps! So to talk to it we need to set the com port to that speed. Usually that would be handled by whatever application is talking to the module but to do it from the command line we need to setting to stick so:

    [2.4.0-BETA][root@s4.stevew.lan]/root: stty -f /dev/cuau1.init speed 2400
    

    It reports 9600 but it has set correctly as you can confirm by:

    [2.4.0-BETA][root@s4.stevew.lan]/root: stty -f /dev/cuau1
    speed 2400 baud;
    lflags: echoe echoke echoctl
    oflags: tab0
    cflags: cs8 -parenb clocal
    
    

    Obviously that's assuming the LCD is on com2 which most are because the console is on com1.

    Then you need to initialise the module with some hex codes. It will accept ascii directly after that but you need hex to clear the screen, move the cursor etc.

    [2.4.0-BETA][root@s4.stevew.lan]/root: cat pfsense.hex > /dev/cuau1
    

    If you see anything on the display that confirms it's type.

    Steve

    pfsense.hex.txt



  • Will try this and report back.



  • It does look like one of the EZIO devices. Here's what I have for them:

    EZIO 100 Info
    http://www.graphicartsolutions.com/tech/EZIO-FINAL.PDF

    EZIO 300 Info
    http://www.graphicartsolutions.com/tech/EZIO-300.pdf

    A hardware installation guide for one of the EZIO family devices
    http://www.graphicartsolutions.com/tech/CAR_3000_EZIO_Installation.pdf

    Hope it helps.



  • Hi

    This is exactly the same issue I am having.. I have a few Caswell CAR-3000 applicances running pfSense and I'm trying to get the EZIO 300 LCD working. I managed to tes the display out by sending hex to COM2 in DOS using:

    serialsend.exe /baudrare 2400 /devnum 2 /hex "\xfe\x28\xfe\x28\xfe\x01TEXTLINE01\xfe\xaaTEXTLINE02"

    Just trying to do that in FreeBSD.  It looks to me like it's on /dev/cuau1 but no joy sending like this:

    echo -e "\xfe\x28\xfe\x28\xfe\x01TEXTLINE01\xfe\xaaTEXTLINE02" > /dev/cuau1

    Did the "pfsense.hex" posted previously work? (I can't check right now as I am not at the device but keen to do so).  Hopefully someone can put me out of my misery as its driving me mad :D



  • I was kindly sent this from Portwell support which I thought I'd share so hopefully it takes us closer to solving it.

    I can't compile on pfSense as there's no cc or gcc and couldn't get it installed so I compiled on a virtual box and copied across but I got an strange error when running it (I am assuming some dependency not installed on pfSense).

    I am not worried about updating the display in realtime, just once on boot so I figured I could call this vaia script on boot - anythign to get rid of "**" which the LCD shows at present

    Hope it helps

    ezio-freebsd.c.txt



  • I can confirm Stephen's hex file works :)



  • Netgate Administrator

    :)

    The FreeBSD echo command doesn't  parse those escape sequences so you can't send hex directly like that unfortunately. Took me a while to realise that.

    I was looking at the various lcdprodc drivers to see what might be closest to use as a base. The thing that looks closest is the serialVFD driver but it has no button support which is unfortunate.

    It's somewhat beyond my coding skills though.

    Steve


  • Netgate Administrator

    Ha, just read your other thread. fmertz, who rewrote the sdec driver, is completely right. Just use the mtc_s16209x driver for maximum win!

    I'm sure I tried that before but probably had the wrong baud rate.

    Buttons don't work. Heartbeat appears incorrectly. Backlight control not functioning as expected. Scope for improvement…  ;)

    Steve




  • I don't think the EZIO devices offer any backlight control.


  • Netgate Administrator

    Yes I believe you're right. Or at least it's not documented if the backlight/contrast are controllable.

    The mtc_s16209xdriver is not perfect. In fact when you compare the command sequences it uses vs the documented EZIO comamnds it's hard to see how it works at all.

    It does not initialise the display correctly. You need to send that string yourself other wise the display will not respond after a power cycle. Not a reboot where the display remains powered. I just kept the shellcmds detailed above to do that.

    The 'beginning of line' values are wrong which means everything is offset to the right by one character which screws the heartbeat icon.

    There is no function to read the keypad though it seems like it could be added relatively painlessly.

    Steve



  • @stephenw10:

    The mtc_s16209xdriver is not perfect.

    If there is a sense that there are at least a few of these devices out there, let me know if there is any interest in getting this driver updated (or a new one created) to work as per the spec.


  • Netgate Administrator

    Oh I'm sure there are more than a few and there would be a number of users for a real, more complete driver here.

    The EZIO is the standard display used by Portwell (who are also Caswell?). They are the OEM supplier for a number of other manufacturers.

    There seem to be several versions, 100, 300 etc but I believe they are backward compatible. The instruction set seems to be the same.

    Thanks.

    Steve



  • Hmm, after taking a look at some of the upstream lcdproc driver code, how about the lb216 driver? The code seem to match with the published EZIO spec just about perfectly.

    2 issues:

    • A backlight is supported by this lb216 driver. Best case, the command is ignored by the EZIO device, or we discover there is a controllable backlight!

    • There is no code for the keypad

    Also, the defaults are "wrong" for the EZIO device, but are configurable:

    "Speed=2400" and "Device=/dev/…" have to be added to the config file.

    If anyone has a chance to test this out, let me know.


  • Netgate Administrator

    Ooo nice catch.

    It works better. The text lines up correctly so I assume it's setting start position right.

    The backlight, contrast and brightness settings do nothing.

    However the screen is not initialised from power off. I still have to send the hexfile at it with the start sequence in it:

    FE 28 FE 28
    

    After that lcdproc kicks in

    Steve



  • So, if I was to make a code change to this existing lb216 driver, we would need a way to instruct the driver to behave either as it was coded before for the lb216, or as an EZIO device. The "obvious" way is to put a new line in the configuration file, like "Variant=EZIO". If we do this however, there would be no easy way for the existing pfSense lcdproc integration package to set it. So, question:

    What would be a good parameter to use in the configuration file to nudge the driver to adopt the EZIO behavior, instead of the default lb216, with no code change to the pfSense lcdproc package?

    "Speed" is not good because there are apparently some lb216 devices at 2400 bps already (as per the code), even if the default is 9600.
    "Device" is not helping us because both would use the same "COM2" device.
    What else can you think of (I have no pfSense instance running at the moment)?

    Thanks.


  • Netgate Administrator

    Display size might be good to use. I trued some different values and they don't seem to actually affect the EZIO display at all. There are probably some options that don't actually exist as an lb216 device either.

    However my preference would be for a separate driver. That would mean making changes to the lcdproc package to have it selectable but that's relatively easy.

    Steve



  • Finally got around to acquiring and setting up this EZIO device. Running off of my Debian Linux ARM NAS, with a Serial/USB adapter, a couple of yost adapters, and a rollover cable. Also has to borrow a motherboard-to-DB9 ribbon cable off of an old Nokia appliances. And to think this is not even that deep into the junk pile…



  • Netgate Administrator

    Nice.  ;D



  • @stephenw10:

    Ha, just read your other thread. fmertz, who rewrote the sdec driver, is completely right. Just use the mtc_s16209x driver for maximum win!

    I'm sure I tried that before but probably had the wrong baud rate.

    Buttons don't work. Heartbeat appears incorrectly. Backlight control not functioning as expected. Scope for improvement…  ;)

    Steve

    Hi Steven
    Don't supose you could share a screen shot of your settings in lcdproc as I can't even get my one to start! lol

    edit = got it to start but it still shows only two * on the screen.



  • Problem is that none of the existing lcdproc drivers have the correct initialization sequence for this EZIO device, yet. So, FOR NOW the device has to be initialized "by hand". If you read this thread again, there is a short file that has to be sent to the display. The file has the right initialization string. After that, the lb216 driver can be used with some success.

    Best of luck, keep us posted.

    PS: I have offered to write a proper driver for these EZIO devices as the spec is available. Let us know if you can help with the effort, like testing prototypes along the way.



  • @fmertz:

    Problem is that none of the existing lcdproc drivers have the correct initialization sequence for this EZIO device, yet. So, FOR NOW the device has to be initialized "by hand". If you read this thread again, there is a short file that has to be sent to the display. The file has the right initialization string. After that, the lb216 driver can be used with some success.

    Best of luck, keep us posted.

    PS: I have offered to write a proper driver for these EZIO devices as the spec is available. Let us know if you can help with the effort, like testing prototypes along the way.

    Thought Steven said use mtc_s16209x driver for maximum win! ill have a go at what you said. tho I kind of suck at this kind of thing. Here goes!

    Okay ive reread twice which hex file ? how would I send this to the screen. This is mega confusing for an idiot like me.



  • I suppose you also need to make sure the device is correct (second serial port), and the speed is also correct (2400 bps)…



  • @fmertz:

    I suppose you also need to make sure the device is correct (second serial port), and the speed is also correct (2400 bps)…

    when I set it too the second serial port lcd does not even start.



  • Netgate Administrator

    Use the hex file from here:
    https://forum.pfsense.org/index.php?topic=99320.msg690716#msg690716

    Put it in /root.

    Then call it using the shellcmd package (needs to be installed) using the commands in the attached screenshot.

    Or run them manually to test.

    Steve




  • @stephenw10:

    Use the hex file from here:
    https://forum.pfsense.org/index.php?topic=99320.msg690716#msg690716

    Put it in /root.

    Then call it using the shellcmd package (needs to be installed) using the commands in the attached screenshot.

    Or run them manually to test.

    Steve

    The txt file Steve?
    also what is the best way to put it in /root?

    (Uploaded file to /tmp/pfsense.hex.txt.) this the right way using the upload part within pfense?

    Cheers


  • Netgate Administrator

    Yeah, it's appended with .txt because the forum only allows certain file types.

    You will need to move it from /tmp as that exists only in RAM so will be lost at reboot.

    The best way to move files to and from the firewall, in my opinion at least, is to use SCP:
    https://doc.pfsense.org/index.php/HOWTO:_Access_pfSense_filesystems_remotely_with_scp

    You can use WinSCP in Windows and drag and drop etc. Just enable SSH in System > Advanced > Admin Access and you will be able to connect.

    Steve



  • Thanks got winscp working and the file in the right place.

    I ran the first comand in putty and got this error

    [2.3.3-RELEASE][root@pfSense.localdomain]/root: stty -f /dev/cuau1.inti speed 24                                            00
    stty: /dev/cuau1.inti: No such file or directory


  • Netgate Administrator

    I think you just typo'd that. It should be:

    stty -f /dev/cuau1.init speed 2400 
    

    Steve



  • Yea I did I found that out :)

    I get this now and nothing happens

    ![2017-04-05 (1).png](/public/imported_attachments/1/2017-04-05 (1).png)
    ![2017-04-05 (1).png_thumb](/public/imported_attachments/1/2017-04-05 (1).png_thumb)


  • Netgate Administrator

    If you have lcdproc installed and configured already go to Status > Services and stop lcdproc. Now run the command again and the start lcdproc again.

    You can't send data to the serial port while lcdproc has it open. The shellcmd package writes to it before lcdproc starts.

    Steve



  • @stephenw10:

    If you have lcdproc installed and configured already go to Status > Services and stop lcdproc. Now run the command again and the start lcdproc again.

    You can't send data to the serial port while lcdproc has it open. The shellcmd package writes to it before lcdproc starts.

    Steve

    Awesome thanks the LCD now says pfSENCE Rules! is that all the steps to get it working thanks again man this helps loads

    Its working!!! thanks so much looks so much better now.


  • Netgate Administrator

    No problem. Hopefully you can help test any drivers later.

    Steve



  • @stephenw10:

    No problem. Hopefully you can help test any drivers later.

    Steve

    Sure no problem.



  • UPDATE: Well, it looks like after going around in a proverbial circle with different options, the new plan is to supplement the existing HD44780 driver. There is already support for a bunch of connection types, including serial, and adding support for these EZIO devices seems pretty straightforward. I have a prototype running, without keypad support, and it seems to run fine. This HD44780 driver is already very modular, and already has the more sophisticated screen update logic built in. As these EZIO devices run at 2400 bps, it is not exactly like we have a lot of bandwidth to work with, so an optimized update logic is a plus. At the base, the EZIO commands match up with the HD44780 commands, so it is a pretty good fit.

    If someone wanted to try the existing HD44780 driver, provided the device is initialized "manually" ahead of time, it would probably already work. Just make sure the device and speed parameters are updated in the LCDd.conf file.

    The code I have right now has the new initialization logic built in, I can share it later. I am working on the keypad code, which is proving to be a bit of a challenge…

    I spoke with the upstream LCDproc maintainer. There is a plan to produce an official release soon. So, if we manage to get this new code added in the upstream project, it would be possible for the FreeBSD and pfSense maintainers to pull this new release from a trusted source and possibly add this to pfSense as an updated package, all "officially", for everyone to simply make use of.

    Let me know of any thoughts.


  • Netgate Administrator

    Sounds like a fine plan.  :D

    From what I could see the EZIO unit is an HD44780 compatible display with a programmable board attached to it to provide an 'easier' way to talk to it. I did look at way to talk directly to the display instead but gave up. I guess it make sense the HD44780 driver would work with it.

    Steve



  • The LCDproc documentation has quite a bit of hardware-related details, including great ASCII schematics. While researching this EZIO device, I can across this implementation for a serial interface "in front" of an LCD controller (itself in front of the HD44780 LCD):

    http://www.xs4all.nl/~mlf/los/

    The EZIO device has to be a similar design. Firmware code for that micro-controller is also listed.

    FWIW, I reached out to Portwell USA support, but they were unable to locate the firmware code.  :P

    In your observation, is the backlight hard wired to the power (always on) or is it attached to an output pin on the micro-controller? If it is, there is this off chance the backlight is programmable, if the firmware allows it. This is not documented, which suggests software cannot control it…