EZIO Driver for LCDproc
-
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.
-
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.
-
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) -
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 -
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.
-
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.
-
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 RightOf course this means we can use a modifier key and get 6 keys for the price of 4!
-
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. -
Ok, so that 0x5A version command is an undocumented feature…
0x40 is documented, it is the beginning code for downloading custom characters.
-
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.
-
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: 92f16f5ccf418fc9167aBIOS Vendor: American Megatrends Inc.
Version: 080015
Release Date: Mon Dec 21 2009Version 2.4.2-RELEASE (amd64)
built on Mon Nov 20 08:12:56 CST 2017
FreeBSD 11.1-RELEASE-p4The system is on the latest version.
Version information updated at Sat Nov 25 13:29:23 -02 2017Thank You for your Help
-
This appears to be in the FreeBSD 11 stable package now. Wonder if we can get it pulled into our repo….
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 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!
-
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
-
would this work with pihole? my smoothwall box runs debian with pi-hole its the very same screen.
-
The driver is in lcdproc upstream so if you install lcdptoc it should be available.
Steve
-
@stephenw10 ive put pfsense back on the box any ideas what settings is needed
Com port
Set the com port LCDproc should use.
Display size
Set the display size lcdproc should use.
Driver
Select the LCD driver LCDproc should use. Some drivers will show additional settings.
Connection type
Select the HD44780 connection type
Port speed
Set the port speed.
Caution: not all the driver or panels support all the speeds, leave "default" if unsure. -
The driver is not in the GUI yet so you can't set lcdd.conf using the package menu. You still need to manually edit it and start it as shown earlier in this thread. But you no longer need to install the driver.
Steve
-
Does anyone know if this comes built into LCDProc /w pfSense 2.4.4 ??
Thanks
-
The driver is now included in lcdproc but the pfSense gui parts are not there yet. So no need to copy the module across but you still need to start it manually.
Steve