EZIO Driver for LCDproc

fmertz

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.

stephenw10

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

fmertz

@stephenw10:

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.

I would encourage you to start another thread for this. Also, post pictures. I actually reached out to Portwell for this, but I am told that initiating the effort of finding documentation requires an invoice number. Another avenue would be to reach out to whomever made the appliance this LCD came with and see if they are willing to help.

If it is serial, there is likely some form of a micro-controller involved. I assume the code could possibly be extracted and looked over to find out the commands. Alternatively, maybe there is some code in whatever distribution this LCD came bundled with. Sometimes researching into this leads to other key words that can be thrown in a search engine…

fmertz

Pictures attached.

IMG_20171004_083854.png_thumb

IMG_20171004_083923.png_thumb

IMG_20171004_083907.png_thumb

evilgoat76

Thats a MUCH older board.

When I left the firmware had not been customised despite my insistance. Sadly my unit how now gone off to its new home complete with non working display (Vmware passthrough issues).

Take the unit out, separate the controller from the display (careful its fragile) and flip it over. Theres a programming header position marked with 5 pins as per the circuit diagram.

The chip should be a PIC 16F628A SOIC rather than a through hole. I seem to recall the very early caswell box we had to play with which was a 1st gen LGA775 Celeron D had a 16F84 through hole and four silver buttons, no matrix but tactile switches.

evilgoat76

Another appliance ordered soleley for me to muck about with, so once thats here and I verify I have ESXI doing passthrough right I'll have a play.

The Developer never replied :( Sadly from what I know of him thats not THAT unexpected.

evilgoat76

Well my new one arrived. FUll of bad joints in the PSU, so whipped apart, soldered up, and out of curiosity 8GB of ram popped in. Shouldnt work and didnt on the last, this board is happy with it AND I've allocated all 8GB and used it in ESXI6, 4GB allocated to PF and 4Gb to Freepbx so its stable. So as an aside, there's a newer BIOS out there for these that lifts the 4Gb limit.

The display is a version of the board. This one with a lot of unpopulated options. I set up the simulator as per my diagram and booted the firmware and got the two '*'s so the firmware hasnt changed, a diff confirms this.

Watching the simulator the display IS initalised by the firmware and those two *'s are sent by the PIC as an inialisation test.

![DSC_0180 (Small).jpg](/public/imported_attachments/1/DSC_0180 (Small).jpg)
![DSC_0180 (Small).jpg_thumb](/public/imported_attachments/1/DSC_0180 (Small).jpg_thumb)
![DSC_0181 (Small).jpg](/public/imported_attachments/1/DSC_0181 (Small).jpg)
![DSC_0181 (Small).jpg_thumb](/public/imported_attachments/1/DSC_0181 (Small).jpg_thumb)

evilgoat76

Attached modified firmware simply changes the ** to a more friendly 'OK'
You'll need MPLAB and a PICKit2 or better. Chip is a 16F628A
BACKUP THE FIRMWARE FIRST!

![DSC_0182 (Large).jpg](/public/imported_attachments/1/DSC_0182 (Large).jpg)
![DSC_0182 (Large).jpg_thumb](/public/imported_attachments/1/DSC_0182 (Large).jpg_thumb)
FW.zip

fmertz

Pretty neat!

Is there a human-readable version of this firmware you could share? Maybe there is some neat undocumented feature we could add to the driver… Thanks.

evilgoat76

Documenting it as we speak. Its prettu horrible and from memory not a lot changed from the inital version, spends a hell of a lot of time in un-necessary register saves and generally odd code…


											Save CPU State
    31   01E     00A0  MOVWF wsave                             	Save W reg
    32   01F     0803  MOVF STATUS, W                            	Copy Status to W
    33   020     00A1  MOVWF ssave                             	Save Status

    34   021     2175  CALL 0x175 					Init Display                            
											Restore CPU State
    35   022     0821  MOVF ssave, W      				Load old Status into W                     
    36   023     0083  MOVWF STATUS                              	Reload Status register from W
    37   024     0820  MOVF wsave, W                           	Reload W 

    38   025     1303  BCF STATUS, 0x6                           	BANK0
    39   026     1283  BCF STATUS, 0x5                              BANK0
    40   027     0803  MOVF STATUS, W 				Copy Status to W     			                      
    41   028     00A1  MOVWF ssave        				Save Status         
    42   029     304F  MOVLW 0x4f                             	Load 4Fh into W ('O')
    43   02A     2199  CALL 0x199                             		Call display char routine
    44   02B     0821  MOVF ssave, W                           	Copy old status into W
    45   02C     0083  MOVWF STATUS                              	Reload Status register from W

At least 10 lines of that are un-needed register/context saving.

The serial handling looks simple enough and I'm about to start on that. There is a very simple code block which is pretty much one character in and a huge switch statement based on the character. I should have it mapped out by the end of the evening if my brain hasn't died by then.

evilgoat76

Well its 23:19 and I'm sick of this.

Its overly complicated and silly, theres some nasty code in here and thi HAS to be compiler generated, no human could make such a mess of this without help!

The long and short seems to be that as per what I already knew from the older version, there arent really any fun features in here. For some reason someone went to a lot of trouble to add support for several dozen ASCII control codes only to have them all return an error!

The only returncodes I see are for the buttons, errors and what looks like an ID (That may be useful for autodetection)

The PIC does have control over the display power but its not exposed to the user in any way I can see. It's also power not backlight so to make it work you'd need to sleep the display, then on waking re-init and send the data again. From a firmware point of view thats doable, LCDPROC would need to know what to do.

I'll trace out the protocol tomorrow and I propose rather than a new firmware that I get this into MPLAB, compiling and cleaned up. Once thats done I can bash up a quick Delphi app to excercise and test it, I should be able to generate some init codes/strings although I suspect they will match what fmertz has.

Once thats done I can take a look at these 'stubs'…

   193   0C0     28F9  GOTO 0xf9                              		Yes, goto F9h (Error routine)
   194   0C1     3002  MOVLW 0x2                              		Load W with 02h (STX)
   195   0C2     0223  SUBWF temp, W                          		Subtract W from temp                          
   196   0C3     1903  BTFSC STATUS, Z  	                       	Was it zero?                        
   197   0C4     28F9  GOTO 0xf9                              		Yes, goto F9h (Error routine)	
   198   0C5     3006  MOVLW 0x06                              		Load W with 06h (ACK)
   199   0C6     0223  SUBWF temp, W                          		Subtract W from temp                          
   200   0C7     1903  BTFSC STATUS, Z  	                       	Was it zero?                         
   201   0C8     28FE  GOTO 0xfe                              		Yes, goto FEh
   202   0C9     3008  MOVLW 0x8                              		Load W with 08h (BACKSPACE)
   203   0CA     0223  SUBWF temp, W                          		Subtract W from temp                          
   204   0CB     1903  BTFSC STATUS, Z  	                       	Was it zero?                        
   205   0CC     28F9  GOTO 0xf9                              		Yes, goto F9h (Error routine)
   206   0CD     300C  MOVLW 0x0C                             		Load W with 0Ch	(LF)
   207   0CE     0223  SUBWF temp, W                          		Subtract W from temp                           
   208   0CF     1903  BTFSC STATUS, Z  	                       	Was it zero?                          
   209   0D0     28F9  GOTO 0xf9                              		Yes, goto F9h (Error routine)
   210   0D1     300D  MOVLW 0xd                              		Load W with 0Dh
   211   0D2     0223  SUBWF temp, W                          		Subtract W from temp                           
   212   0D3     1903  BTFSC STATUS, Z  	                       	Was it zero?                          
   213   0D4     28F9  GOTO 0xf9                              		Yes, goto F9h (Error routine)

And see about using them for other things, primarilly turning the display on and off for now.
In doing so I'll change the ID code it returns so it's detectable.

A keypad read returns two bytes :
0xFD - this is always the same.
The next byte should be one of 4 possible bytes, however the code breaks if you try to be clever with the buttons, it factos in the individual buttons but not combinations, when it hits something it doesnt know it just passes the bitmap through, making about 20 lines of assembler redundant but gives us the following:

The return is always 0xBn. The B can be masked off, its not used
The N represents a bitmap containing the status of all the buttons. Its inversed but starting from the right as lsb:
bit 0 - Top Left
bit 1 - Bottom Left
bit 2 - Bottom Right
bit 3 - Top Right

Of course this means we can use a modifier key and get 6 keys for the price of 4!

diplay.zip

evilgoat76

Right. First up, this is easy to get this stuck in odd states.

If the display stops responding


0x00, 0xFE, 0xFE, 0x37

should reset the state machine. In most places 0x00 will put you back to needing to do an init.

Init is

0xFE, 0x28

Then either:
Send chars as needed (You cant use 0x10 or 0xFE)
OR
Send 0x10 and the module will reply with the keystates, this means you HAVE to poll this (STUPID!). The Low baud rate and need to poll explains the issues people have had.
OR
Send 0xFE and one of the following commands…


	5Ah - get ID, returns 0x02,0x05 so sending 0xFE, 0x28, 0xFE, 0x5A from cold will confirm the module is there and give the version (2.5)
	01h - clear display 
	02h - home - Sets Data pointer in LCD to 0
	06h - read keypad
	08h - Display off, Cursor Off, Blink off	
	0Ch - Display on, Cursor off, blink off
	0Dh - Display on, Cursor off, blink on
	0Eh - Display on, Cursor on, blink off
	10h - Cursor left 
	14h - Cursor Right
	18h - Display Left shift
 	1Ch - Display Right shift
	40h - Set Char Gen ram address to 0
	C0h - Home line 2 - Set Data pointer to halfway through data ram
	37h - Reset command mode

I'm not sure what use 0x40 really is
That's all there is. Just going to bash together an app to test and play with now.

fmertz

Ok, so that 0x5A version command is an undocumented feature…

0x40 is documented, it is the beginning code for downloading custom characters.

http://drivers.portwell.com/CA_Manual/EZIO/EZIO-FINAL.PDF

evilgoat76

That sort of makes sense, looking at the code I really couldn't see how you could actually use it though.

The disasembled code now compiles and SORT of works, need to fix what looks like a config word issue.

Lourensb

Hi Guys

I registered here, to see if I can get some help.

I am a very basic user, with limited Skills.

I have a CAR 3000 Portwell unit, that I installed pfSense on, the latest / Current Version.

I followed, and tried about all the Steps, and for some time, all my Display said, was pfSense Rules !

I then Powered the Device down, and not it's back to **

Can you please just give me a complete guide, as to what is needed, to get the Display to work please.

I am willing to test for you also.

System pfSense
Netgate Device ID: 92f16f5ccf418fc9167a

BIOS Vendor: American Megatrends Inc.
Version: 080015
Release Date: Mon Dec 21 2009

Version 2.4.2-RELEASE (amd64)
built on Mon Nov 20 08:12:56 CST 2017
FreeBSD 11.1-RELEASE-p4

The system is on the latest version.
Version information updated at Sat Nov 25 13:29:23 -02 2017

Thank You for your Help

stephenw10

This appears to be in the FreeBSD 11 stable package now. Wonder if we can get it pulled into our repo….

Steve

andrew867

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

I've got an old IBM security appliance that will only run x86 and I had the same issue with libftdi1 not existing. The recompiled version works perfect, thanks!

stephenw10

The EZIO driver is now in the lcdproc package for 2.4.4 snapshots but not yet exposed by the GUI. Still easier to test though.

Steve

x2rl

would this work with pihole? my smoothwall box runs debian with pi-hole its the very same screen.

stephenw10

The driver is in lcdproc upstream so if you install lcdptoc it should be available.

Steve