- Fits in one half height 5.25″ drive bay.
- Back light 16 x 2 lines LCD (Hitachi Compatible) display.
- 4 Selection buttons, arranged so that it looks like an ATM machine.
- RS232 19,200 baud connection to PC with Hardware handshaking (CTS).
- Uses a subset of the standard VT-52 control codes to control the LCD.
- 3.6864MHz crystal make baud rate calculations easy.
- Should be easy to port to BSD, SCO OpenServer,
SCO Unixware, SUN Solaris or anything that has a serial port.
- Doesn’t use any fancy or hard to get parts, all available
off the shelf from Maplin Electronics (UK). However, some of the spacers
needed to be cut to fit.
If you have read the other pages on this site you’ll know that I’ve got a Linux machine on a shelf in my room that provides all sort of useful services. It’s got no monitor or keyboard, and sometimes this can be annoying. What I wanted was a small display that I could check on that state of the machine and perform some useful actions – like a controlled shutdown, mount or un-mount devices – that type of stuff.
I like electronics and a few years ago began experimenting with Microchip’s PIC16C84. I bought five of these devices for a knock down price and so I’m now putting them to use. The ’84 isn’t the best tool for the job as it lacks a UART, this is no big deal really – it just makes the software on the PIC more interesting.
Problems and Limitations
Reading RS232 is quite a CPU intensive operation for the ’84 as you must poll and sample the RS232 waveform in software in order to determine the whole byte. As soon as the PIC detects that a transmission is on its way it uses CTS to inform the host device not to send any more data until it is ready for more. This gives the PIC enough time to control the LCD or perform other in house tasks. Unfortunately there is a problem with this. 16550A PC serial port chipsets under Linux send 8 bytes then see if the remote device can handle any more. If you use this PIC on one of these serial ports only every 8th byte is correct, the rest are corrupt because they were sent while the PIC wasn’t ready. The solution to this problem is fortunately very easy to fix. You need to tell Linux to control the serial port like an old style 8250 that had no fancy buffers. So.
setserial /dev/ttyS1 uart 16450
will fix this problem on Linux, I’m not sure about other Unix’s.
Because of the polled serial reading it is possible for the start bit to arrive while the PIC is in the middle of the interrupt routine to poll the buttons. A corrupted byte (or two) is likely to be read. This doesn’t happen very often, if fact I’ve not seen it happen yet – but it’s statistically likely to happen. The solution to the is to use a real UART or a PIC with a UART. I’ve recently made some adjustment to the code to tighten the timing up, it’s now very unlikely to get corrupted characters.
What needs changing or fixing when you build the next version?
- Button repeat in the PIC code.
- Use round buttons to match the round holes!
- The display does not scroll, I’d need an extra control line to the LCD to do this which with the current PIC I don’t have. However, there are ways to get round this by multiplexing the LCD data lines with the buttons.
- Full duplex using a lower baud rate, and that should eliminate the need for hardware handshaking. 2400 baud might be OK…
ESC E Clear display and reset cursor to top left.
ESC T not a VT code. This is something I’ve put in that displays a test pattern, used to check the RS232 output serial code in the PIC.
ESC H Resets the cursor to the top left, but does not clear the display.
ESC Y Position the cursor, format of the command is ESC Y (32+Y) (32+X) so ESC Y !! sets the cursor to 1,1.
ESC e Cursor visible.
ESC f Cursor off.
That’s it, there isn’t very much point implementing the rest, some code are impossible to do with the LCD anyway – like inverse video and colours.
For more detail: PIC 16C84 VT-52 Emulator for Linux