EZIO Driver for LCDproc
-
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
-
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…
-
Pictures attached.
-
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.
.jpg)
.jpg_thumb)
.jpg)
.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!.jpg)
.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 WAt 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, 0x37should reset the state machine. In most places 0x00 will put you back to needing to do an init.
Init is
0xFE, 0x28Then 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 modeI'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.
