Question about the different types of serial LCD's

I have a few questions I've been searching everywhere for in regards to the different serial LCD's.

  1. I have a couple projects that are designed to use the "sparkfun" 3 wire serial LCD. These however just seem way too expensive for what they are, about $32 shipped, compared to simply the regular LCD's for around $2.50 shipped. Are there any other LCD's compatible with the sparkfun ones for cheaper, or that can be made cheaper? I did find this one that says it uses UART, not sure if its compatible or not, and still expensive, but at least its only $25 shipped, any idea if it will work? http://www.ebay.com/itm/Serial-UART-SCI-Enabled-LCD-Adapter-1602-LCD-Disp-/120735812662?pt=LH_DefaultDomain_0&hash=item1c1c6a4c36

  2. Do serial LCD's, (either the regular 4 wire, or the sparkfun), solve the issue of LCD artifacting, or do you still need to manually workaround it? What I mean by this is, when I have used the regular 16x2 non-serial lcd's on projects before, say I have a variable on the screen, lets say the number 15 for example. Well if that 2 digit variable goes down to 1 digit, say 9 for example, the first digit does not clear, so even though the number is 9, it will appear on the screen as 19, since that 1 is an artifact. Only way I had found to solve is by adding extra code to monitor how many digits and clear the first ones if necessary, but its extra work, would be nice if you didn't have to.

  3. Are there any advantages to one serial lcd over the other, besides just that the sparkfun one has one less wire?

Thanks.

The product you linked to seems to be compatible with arduino. You may need to modify some minor things to take code that ran on sparkfun serial LCD to run on this one.

The serial LCD won't solve artifacts. The following frequently prescribed medicine cures the ailment:

char buffer[17];
int number=9;
sprintf(buffer,"%2d",number);
lcd.print(buffer);

To do zero padding such as 07 08 09, use "%02d".
Refer to cplusplus.com for sprintf, the fancy medicine that cures all.

I am certainly biased towards this serial LCD issue as I make and sell a family of serial LCDs and keypad panels myself but take whatever you consider as fair argument:

3 vs. 4 wires:
Some serial LCDs are just LCDs, i.e. an output device. So you don't need to read back from it. This saves one line, the RX on your arduino. Some have both RX and TX for possibly these reasons:
*Update firmware could require two-way communication for verifying the firmware at upload.
*Read back from the LCD to see what's on the display, don't know why that's important. Or read back type of serial LCD ie. serial number or model number so arduino knows there is a serial LCD connected.
*The serial LCD can connect to other things. Again, this is a link to my product: this phi-panel has either integrated or optional 16-key keypad. The user input on the keypad is processed then transmitted TO arduino RX while commands to control the LCD or keypad (say enable/disable multi-tap) or messages to display on the LCD are transmitted FROM the arduino to the LCD panel. This requires two-way communications.

Cost:
Some serial LCDs are cheap because they don't have a processor on board. They are the I2C serial interface, which arduino can connect to. These are simply I/O expanders that give you 8 additional I/O ports, enough to run the LCD. The backpack has no intelligence. The arduino spends all the resources and does all the work and needs to drive the display with special libraries provided by the makers. I know of two sources besides ebay, adafruit, and our forum member fm. Since there is no processor on the LCD backpack, the solution is cheap.

The more costly serial LCDs have on-board processors that controls the display and in the case of my LCD backpack, also possibly senses other inputs, process them, or even run multi-tap input or other fancy stuff on the on-board processor so your main arduino doesn't need to worry about those. Those are more expensive and frees up resources on arduino and are more or less swappable with other serial LCDs with on-board processors without ever needing special libraries. Among a few of the sellers, sparkfun, moderndevice, the one you linked to, mine, etc. All have the same level of intelligence except for mine, which is also the lowest cost with most functions. That might explain why both sparkfun and moderndevice are not interested in carrying my serial LCD. :wink:

So my logical conclusion is to buy the phi-panel family of serial LCD for the lowest price (except for fm's I2C backpack) and best functionality. The rest of them in terms of functionality are about 5,000 lines of firmware code behind.

I would avoid using serial lcds that have a UART interface because either this ties up your hardware UART, or else you have to use software serial in which case you can't do anything else while you are sending data to the lcd.

Some of the more modern lcd modules have a built-in SPI-type serial interface. I have used an ST7920 based 128x64 glcd like this one http://www.ebay.co.uk/itm/Graphic-LCD-Module-LCM-12864-128x64-ST7920-5V-Blue-C14-/280711859263. There are also oled-based displays which support a serial interface, e.g. http://www.rapidonline.com/Electronic-Components/16-x-2-OLED-Alphanumeric-Displays-500173. These cost more than LCD displays, but less than the $32 you mentoned.

dc42:
I would avoid using serial lcds that have a UART interface because either this ties up your hardware UART, or else you have to use software serial in which case you can't do anything else while you are sending data to the lcd.

How do you do anything while using LCD on any other interface? And why do you do anything while updating an LCD? Got any details to your argument? I know SPI is faster but serial is easiest to understand. Plus, you need more pins for SPI. I don't know this. Is interrupt enabled during SPI transfer?

liudr:
How do you do anything while using LCD on any other interface? And why do you do anything while updating an LCD? Got any details to your argument? I know SPI is faster but serial is easiest to understand. Plus, you need more pins for SPI. I don't know this. Is interrupt enabled during SPI transfer?

You might need to respond to inputs while updating the lcd. Although reading a push button can probably wait until the lcd commands have finished being sent, there are many situations in which you can't wait that long, e.g. when reading rotary encoders (which need to be interrupt-driven or polled every 1ms or so), or when measuring the interval between incoming pulses from an rpm sensor. Or you might need to generate output pulses at a regular rate, e.g. for a stepper motor. All of these can be done using interrupts. However, software serial has to disable interrupts in order to produce accurately-timed output.

Interrupts are not disabled during SPI transfers, whether you use hardware or software SPI.