Hey all,
whats the difference between serial lcd and parallel lcd ?
I'm going to do the lcd tutorial and curious what the diff are..
A serial LCD uses serial communications, a parallel LCD uses parallel communication.
ie: serial LCD uses a RX and TX line (allthough it likely doesn't use the TX), a parallel LCD uses 4 or 8 lines plus a 'clock' line (to make it accept the 4 or 8bits of data).
The serial ones I've seen are just a standard parallel LCD with a daughterboard strapped to the back that has the serial interface - often one of the smaller AVR chips such as this little guy:
Biggest advantage of the serial versions is they simply use less of your pins.
G.
Thanks for the info guys..
Now !
I can go order my project stuff, yeehaaa 
cheers, and thanks
:o
Biggest advantage of the serial versions is they simply use less of your pins.
The other view is that the biggest disadvantage of the serial versions is that they tie up a whole extra microprocessor for a relatively simple task.
You also have to deal with a protocol that is different for each serial implementation and which you cannot alter.
Don
Hi Don,
I did not know that..
I had a look at the spec sheets and it looked a bit complicated
I think I'll better stick with parallel,
thanks Don
Hi Don,
Don't know if this is any help...
Here's a great set of tutorials from Adafruit.
http://www.ladyada.net/learn/lcd/index.html
Cheers!
--
M.S.
O yep ,
I read these, theyre really good and helpful simple.
Thanks bud
What ever you do, stay away from the 117 series serial controllers such as the one sold by ModernDevice.com. It uses a PIC chip written by some guy. Its closed source and it does NOT understand standard Carriage Return and Line Feed, you have to send odd chars such as "?R" for a return and "?N" for line feed. Unfortunately there are MANY boards that use this cpu and it doesnt understand standard ASCII
Hi Mark,
yeah I saw this but the code got me spooked a bit.. >
http://www.phanderson.com/lcd106/lcd107.html
thanks for that, that eliminates another
What ever you do, stay away from the 117 series serial controllers such as the one sold by ModernDevice.com. It uses a PIC chip written by some guy.
The 'some guy' is Peter Anderson. Just to set the record straight this should probably be the board/chip of choice if you decide to use a serial LCD interface. His was the first of the serial LCD modules available, it's been around for more than a decade, and is the most widely available. That means that you are more likely to find code examples written for this chip than for any others.
Its closed source ...
That is about the only disadvantage.
.. and it does NOT understand standard Carriage Return and Line Feed, you have to send odd chars such as "?R" for a return and "?N" for line feed.
The LCD controller itself does not inherently understand 'carriage return', 'line feed' or any other ASCII control codes. All LCD implementations, serial, I2C, parallel, or tin cans with string, must convert some special code you send them into the appropriate cursor control codes.
Unfortunately there are MANY boards that use this cpu
I would call this fortunate for the reasons mentioned above.
...and it doesnt understand standard ASCII
Then how does it display any text strings that you send it.
All that having been said, there are other boards out there that may be better for a specific application. I myself would look for one that can also understand I2C, a protocol that probably didn't exist when Peter wrote his original code. The trade off is that you will be more or less on your own since it will be a lot harder to find code examples for these newer implementations.
Don
yeah I saw this but the code got me spooked a bit..
There's always a trade off between complexity and versatility. The more versatile the device the more complex the controls.
Don
I've got to agree, it's a great Serial LCD to get. I believe you can use them with LCDSmartie to display various information from your computer. (LCDSmartie hasn't been upgraded in years, but still works like a champ)
If you have an extra Atmega8/168/328, you can upload a sketch to turn it into a "Serial LCD Controller".
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1260399444
I used the code from Nuelectronics and added some commands to store data on the "Controller" EEPROM with a few simple commands.
http://www.nuelectronics.com/estore/index.php?main_page=project_lcdsmartie
/* Serial LCD, using Matrix Orbital command set*/
/* Original code found http://www.nuelectronics.com/estore/index.php?main_page=project_lcdsmartie*/
// These must be changed in LCD4Bit_mod.cpp, this is just for reference
// RS, RW and Enable can be set to whatever you like
// int RS = 4;
// int RW = 13; // not used, ground the RW pin
// int Enable = 3;
// DB should be an unseparated group of pins - because of lazy coding in pushNibble()
// int DB[] = {5, 6, 7, 8}; //wire these to DB4~7 on LCD.
#include "LCD4Bit_mod.h"
#include <EEPROM.h>
//#include <Streaming.h>
const byte backLight = 13; // backLight for LCD: 69 = on, 70 = off
//create object to control an LCD.
//number of lines in display=1
LCD4Bit_mod lcd = LCD4Bit_mod(2);
void setup() {
pinMode(backLight, OUTPUT); //we'll use the debug LED to output a heartbeat
digitalWrite(backLight,HIGH); //turn backLight on
Serial.begin(9600);
lcd.init();
lcd.clear();
lcd.printIn(" LCD Ready: "); // Let you know LCD is ready
}
byte serial_getch(){
int incoming;
while (Serial.available()==0){
}
// read the incoming byte:
incoming = Serial.read();
return (byte) (incoming &0xff);
}
void loop(){
byte rxbyte;
byte temp;
byte addr;
byte pin;
int myVal;
int val;
rxbyte = serial_getch();
if (rxbyte == 254) //Matrix Orbital uses 254 prefix for commands
{
switch (serial_getch())
{
case 50: // Read analog pin, then send value back
pin = serial_getch();
myVal = analogRead(pin)/4;
delay(10);
Serial.print(myVal, BYTE);
break;
case 64: // EEPROM Write (address, value)
addr = serial_getch();
delay(10);
val = serial_getch();
EEPROM.write(addr, val);
break;
case 65: // EEPROM Read (address)
addr = serial_getch(); // EEPROM address
val = EEPROM.read(addr); //
Serial.print(val, BYTE);
break;
case 69: //backlight on (at previously set brightness)
// not implemented
digitalWrite(backLight, HIGH);
break;
case 70: //backlight off
// not implemented
digitalWrite(backLight, LOW);
break;
case 71: //set cursor position
temp = (serial_getch() - 1); //get column byte
switch (serial_getch()) //get row byte
{
//line 1 is already set up
case 2:
temp += 0x40;
break;
case 3:
temp += 0x14;
break;
case 4:
temp += 0x54;
break;
default:
break;
}
lcd.commandWrite(0b10000000 + temp);
break;
case 72: //cursor home (reset display position)
lcd.commandWrite(2);
break;
case 74: //show underline cursor
lcd.commandWrite(0b00001110);
break;
case 75: //underline cursor off
case 84: //block cursor off
lcd.commandWrite(0b00001100);
break;
case 76: //move cursor left
lcd.commandWrite(16);
break;
case 77: //move cursor right
lcd.commandWrite(20);
break;
case 78: //define custom char
lcd.commandWrite(64 + (serial_getch() * 8)); //get+set char address
for (temp = 7; temp != 0; temp--)
{
lcd.print(serial_getch()); //get each pattern byte
}
break;
case 83: //show blinking block cursor
lcd.commandWrite(0b00001111);
break;
case 86: //GPO OFF
//implement later
break;
case 87: //GPO ON
/*temp = serial_getch();
if (temp == 1)
{
GPO1 = GPO_ON;
}*/
break;
case 88: //clear display, cursor home
lcd.commandWrite(1);
break;
/*###############################################################
case 152: //set and remember (doesn't save value, though)
case 153: //set backlight brightness
//not implemented
break;
//these commands ignored (no parameters)
//case 35: //read serial number //USING FOR EEPROM//
//case 36: //read version number
case 55: //read module type
case 59: //exit flow-control mode
//case 65: //auto transmit keypresses
case 96: //auto-repeat mode off (keypad)
case 67: //auto line-wrap on
case 68: //auto line-wrap off
case 81: //auto scroll on
case 82: //auto scroll off
case 104: //init horiz bar graph
case 109: //init med size digits
case 115: //init narrow vert bar graph
case 118: //init wide vert bar graph
break;
###############################################################*/
default:
//all other commands ignored and parameter byte discarded
temp = serial_getch(); //dump the command code
break;
}
return;
} //END OF COMMAND HANDLER
//change accented char to plain, detect and change descenders
//NB descenders only work on 5x10 displays. This lookup table works
// with my DEM-20845 (Display Elektronik GmbH) LCD using KS0066 chip.
switch (rxbyte)
{
//chars that have direct equivalent in LCD charmap
/* case 0x67: //g
rxbyte = 0xE7;
break;
case 0x6A: //j
rxbyte = 0xEA;
break;
case 0x70: //p
rxbyte = 0xF0;
break;
case 0x71: //q
rxbyte = 0xF1;
break;
case 0x79: //y
rxbyte = 0xF9;
break;
*/ case 0xE4: //ASCII "a" umlaut
rxbyte = 0xE1;
break;
case 0xF1: //ASCII "n" tilde
rxbyte = 0xEE;
break;
case 0xF6: //ASCII "o" umlaut
rxbyte = 0xEF; //was wrong in v0.86
break;
case 0xFC: //ASCII "u" umlaut
rxbyte = 0xF5;
break;
//accented -> plain equivalent
//and misc symbol translation
case 0xA3: //sterling (pounds)
rxbyte = 0xED;
break;
/* case 0xB0: //degrees symbol
rxbyte = 0xDF;
break;
*/ case 0xB5: //mu
rxbyte = 0xE4;
break;
case 0xC0: //"A" variants
case 0xC1:
case 0xC2:
case 0xC3:
case 0xC4:
case 0xC5:
rxbyte = 0x41;
break;
case 0xC8: //"E" variants
case 0xC9:
case 0xCA:
case 0xCB:
rxbyte = 0x45;
break;
case 0xCC: //"I" variants
case 0xCD:
case 0xCE:
case 0xCF:
rxbyte = 0x49;
break;
case 0xD1: //"N" tilde -> plain "N"
rxbyte = 0x43;
break;
case 0xD2: //"O" variants
case 0xD3:
case 0xD4:
case 0xD5:
case 0xD6:
case 0xD8:
rxbyte = 0x4F;
break;
case 0xD9: //"U" variants
case 0xDA:
case 0xDB:
case 0xDC:
rxbyte = 0x55;
break;
case 0xDD: //"Y" acute -> "Y"
rxbyte = 0x59;
break;
/* case 0xDF: //beta //mucks up LCDSmartie's degree symbol??
rxbyte = 0xE2;
break;
*/ case 0xE0: //"a" variants except umlaut
case 0xE1:
case 0xE2:
case 0xE3:
case 0xE5:
rxbyte = 0x61;
break;
case 0xE7: //"c" cedilla -> "c"
rxbyte = 0x63;
break;
case 0xE8: //"e" variants
case 0xE9:
case 0xEA:
case 0xEB:
rxbyte = 0x65;
break;
case 0xEC: //"i" variants
case 0xED:
case 0xEE:
case 0xEF:
rxbyte = 0x69;
break;
case 0xF2: //"o" variants except umlaut
case 0xF3:
case 0xF4:
case 0xF5:
case 0xF8:
rxbyte = 0x6F;
break;
case 0xF7: //division symbol
rxbyte = 0xFD;
break;
case 0xF9: //"u" variants except umlaut
case 0xFA:
case 0xFB:
rxbyte = 0x75;
break;
default:
break;
}
lcd.print(rxbyte); //otherwise a plain char so we print it to lcd
return;
}
(int DB[] = {5, 6, 7, 8}; //wire these to DB4~7 on LCD)
i like that
(There's always a trade off between complexity and versatility.)
yep :o
floresta
What I meant by not supporting standard ascii is it does NOT understand CR (0x0d) and LF (0x0A). the 2 MOST important control characters.
You have to send "?r" to get a return, how utterly stupid.
Other than that it is a very good board, but I feel that is enough of a flaw that it should NEVER be used.
my $0.02
You have to send "?r" to get a return, how utterly stupid.
There is a very good reason for this behavior and it relates to how the Hitachi controller works.
As you are probably aware, the controller has the ability to store 8 custom characters which are accessed with the codes 0x00 - 0x07. If you look at the character set you will see that the next eight hex codes (which include your desired and ) mirror the first eight codes.
This means that if you were to include a code of 0x0D in the ASCII string sent to the LCD controller by the serial backpack it would display the custom character #6 stored at 0x05.
Other than that it is a very good board, but I feel that is enough of a flaw that it should NEVER be used.
So what you are saying here is that the LCD controller itself has a flaw, since it does not 'properly' interpret and , and therefore it should never be used.
Actually you have to understand that these devices were never intended to be used in the way that a computer screen is used, to display large amounts of text spanning several lines or pages. They were designed to display short messages such as "Add more paper", "Your Pizza is ready", Your garage is on fire", etc.
Don
This means that if you were to include a code of 0x0D in the ASCII string sent to the LCD controller by the serial backpack it would display the custom character #6 stored at 0x05.
NO, CR should cause it go to the start of the line and LF should cause it to go to the NEXT line. Neither one should be displayed. This is the way ascii has worked since the days of the hard copy terminal. The special characters should be implemented with other means such as ESCape.
If you use one of the LCD controllers to monitor the output of a GPS without a CPU in the middle then you get totally unreadable data, all run together.
NO, CR should cause it go to the start of the line and LF should cause it to go to the NEXT line. Neither one should be displayed.
This can not be done using the resources of the Hitachi controller for the reasons I posted earlier. That controller can be used with displays ranging from 8 characters up to 80 characters in varying configurations and there is no way of letting the controller know which one is attached. You might want to follow the LCD Addressing link at http://web.alfredstate.edu/weimandn to get a better understanding of the problem.
If you use one of the LCD controllers to monitor the output of a GPS without a CPU in the middle then you get totally unreadable data, all run together.
Obviously you must put a CPU in the middle because the GPS device outputs serial data and the LCD module requires parallel data. All of the 'serial' LCD modules include such a CPU, typically a PIC because they have been around for a long time.
Most of those modules were probably designed to get the basic functions of the inherently parallel LCD to work in a serial environment but as you have found out the implementation is a compromise. In order to retain the display of the user defined characters with the lowest ASCII codes they had to implement the and differently and you just don't care for their decision on how to do that. That doesn't really make it 'stupid'.
For your implementation it looks like you have two choices depending on how much programming you want to do.
(1) You can go with one of the existing 'serial backpack' implementations and put another CPU (such as an Arduino) between it and the GPS. You would use that CPU to filter the GPS output and convert it's control codes into ones the serial backpack understands.
(2)You can create your own 'serial backpack' from scratch in which case you can choose any means you want to deal with the ASCII control codes and to differentiate between them and the LCD's custom characters. This would be more work than (1) but it would be a 'cleaner' answer and would result in one less CPU.
Don