Advice on designing a 'slave' LCD controller...

[Buriedcode]

Hi,

I've finished some projects, and now I'm thinking of new ones, to make prototyping easier and to use up some bits'n'bobs I've got laying around. A slave LCD controller. Basically, I'm thinking of a PIC micro on a board permenantly attached to a hitachi LCD module (with interchangable modules). This can use its serial port to accept SPI/I2c/Async, depending on a 'jumper setting' on start up. All it will do is, initialize the module on power up, control the contrast, via PWM, and the backlight. And of course pass commands from the serial port directly to the LCD module. I've got a few PIC16F819's about, and they've got a fair bit of memory, so I guess I could store menus, and possibly even subprograms for debugging, displaying HEX, binary or even decmial, from what's provided from the serial port.

I'm sure this is what those 'serial' LCDs are, just a hitachi module thats controlled by a micro, and I'd love to know if anyone has done this before. I haven't seen much info on building such a device, since its not for a specific application, just so I can rig it up to other projects that have a spare serial port and test/debug, without having to include all the commands for the LCD (and use valuable I/O's).

Maybe its pointless, I was just wondering what people's opinions are on the 'usefulness' of this. I just thought it would be nice to have more functions on the standard HD44780 via remote serial connection (or even IR!!) such as backlight and contrast control and 'modes' of operation (debug, display Hex, transparent). (I've already made a cheap shiftregister interface to save pins using the SPI port)

Hope to hear some suggestions, criticisms, comments....

BuriedCode.

 

[micropar]

Dear Buriedcode,

Visit Serial LCDs maker www.crystalfontz.com where you will find all types of serial LCDs you can think of.

Regards,

 

[davesaudio]

Basically a terminal emulator - lots of those projects on the web for
basic ascii serial.

If you want enhanced features stick to a "standard" serial protocols,
either crystalfontz (as mentioned )or matrixorbital or seetron.
added advantage-then you can test with a pc program lcdsmartie etc
I think its a good building block to have, the more of the CF or
matrix orb functions.commands you include the more popular it will be
D

 

[Buriedcode]

micropar, davesaudio, thanks for your replies

I've visited crystalfontz many times,, thats where I've seen 'serial LCDs'. However, their modules are actually hardwired onto the module, one board. I'm designing an attachment board, to go with a standard module. Of course, it'll pretty much be the same as a serial LCD, but with (I hope) greatly improved features. Theres some things I can't do, since they are down to the LCD module itself, like scroll individual lines, and have no gaps between characters.

Dave, cheers for the advice on protocols. I'm aiming for, not only rs232 and spi, but also I2C. All can be used. Rs232 for PC work, and the other two for embedded apps. The other reason I'm doing this, is to try and stretch the micro to its full capabilities. Using every resource, and nearly all its memory and EEPROM, since I don't think I've ever really got it working hard

Anyway, thanks again, I'll start on the 'protocol' for the device soon, since I'm not only sending data to the LCD module, but also, some data is meant for the PIC itself (programming characters into the eeprom, boot up screens, configuration, executing sub-programms for debugging and showing register contents). Hardware wise it shouldn't be too hard, and its only going to be as big as the LCD module. Software will be a nightmare though

If ever I finish this (probably end up in my 'never got off the ground' folder) I'll post the results here.

Regards,

BuriedCode

 

[Buriedcode]

Hey, just did another search on google, and found the apparently 'legendary' backpack for hitachi LCD modules. Typical, I come up with an idea and some guy is selling it for $29 S'all good though, since it gives me a benchmark to work with, and improve on. I'm currently compiling a bunch of utility programs that allows the slave controller to operate in different 'modes', which should cut down on sending two bytes for every thing I send to it. For example, say I'm sending a text string, I'll send some arbitrary number, say, 0x55, and that could mean that every byte after that is a ASCII character, to be displayed with a auto incrementing cursor. Or, since ASCII takes up nearly all 256 byte forms, I could have a single number, not used by the LCD to signify and instruction to the slave controller, and the byte directly after this contains setup information. I believe the 'LCD backpack' has this, except, as I keep saying, the number of options I want to have on this beast will be great. now I just need to assign numbers to each function, I've got 256 'slots' play with