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

stephenw10

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

Riftcore

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

stephenw10

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

stty -f /dev/cuau1.init speed 2400

Steve

Riftcore

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)

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

Riftcore

@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.

stephenw10

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

Steve

Riftcore

@stephenw10:

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

Steve

Sure no problem.

fmertz

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.

stephenw10

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

fmertz

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…

stephenw10

I found not way to control it but it would not surprise me to find it's possible. It would be nice to have but not important, the backlight life if obviously not a factor here if the manufacturer has it fixed on.

I didn't study the connections between the LCD and the module that closely. Once I found there was no easy way bypass it I stopped looking.

Steve

fmertz

Ok, time for a test!

I attached a FreeBSD-compiled driver for an EZIO variant of the HD44780 driver. The code works on my Linux ARM NAS and my funky USB/Serial adapter. Hopefully, it works on the real appliance as well. If someone is up for a test, let me know.

So:

Extract hd44780.so from the attached archive and copy it on the appliance
Check LCDd.conf and make sure it looks like what follows
Start LCDd and see what happens. The server alone shows basic stuff and allows for keypad interaction. Start with ESC and navigate


[server]
Driver=hd44780

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


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

Fair Warning: the attached code is executable. This code is of unknown origin for most of you. It is a development version of a device driver, or so I say. Use at your own risk, only on a system you own, in a non-production environment.

The code is here: https://github.com/fmertz/hd44780-ezio/tree/hd44780-ezio

hd44780.zip

stephenw10

Nice work. Unfortunately it fails to load for me:

 Could not open driver module /usr/local/lib/lcdproc/hd44780.so: /usr/local/lib/lcdproc/hd44780.so: unsupported file layout

Is that compiled 64bit? What FreeBSD version? I was testing in pfSense 2.4 so FreeBSD 11.

Edit: Looks like it is 32bit, any chance of a 64bit version?

Steve

fmertz

Yep, 32bit FreeBSD 10.2.

Ok, let me look around for FreeBSD 11 64bit…

fmertz

OK, I attached a 64bit FreeBSD 10 driver. Let me know.

hd44780.zip

stephenw10

It works! :D ….mostly.

The display looks correct.

The driver initialises the display correctly from power off.

The keypad doesn't work.

I should note I've never seen the keypad work on this hardware, the original OS was not bootable. It may be broken for all I know though it looks in good condition.

Not sure how to test that directly....

Steve

My LCDd.conf for reference:

[server]
DriverPath=/usr/local/lib/lcdproc/
Driver=hd44780
Bind=127.0.0.1
Port=13666
ReportLevel=3
ReportToSyslog=yes
User=nobody
Foreground=no
ServerScreen=no
GoodBye="Thanks for using"
GoodBye="    pfSense     "
WaitTime=5

[menu]
MenuKey=Escape
EnterKey=Enter
UpKey=Up
DownKey=Down

[hd44780]
driverpath=/usr/local/lib/lcdproc/
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
Speed=2400

fmertz

You can test this keypad "manually".

Create a background process to read from the device.```
cat < /dev/cuau1 > nil.dat &


Then, send xFEx06 to the device.```
printf "\376\006" > /dev/cuau1

The keypad status comes back in hex: xFDx4n. No key pressed is x4F. F is binary 1111. Each key pressed makes a bit go to 0, so:

Escape is x4E
Up is x4D
Enter is x4B
Down is x47

So, press one of the keys, then send the command xFEx06. Press another key, then send the sequence. Once done with all keys, check nil.dat with```
od -x nil.dat

stephenw10

Hmm, nothing coming back at all. I would expect to get back 0x4f every time if the keypad was disconnected for example.

Port somehow open write only?

stephenw10

Hmm set the port speed manually and initialised the display…. still nothing coming back

Sending

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

Does correctly clear the display so commands are reaching the module as expected.