SparkFun Forums

[xflipperx03]

I purchased a Serial enabled LCD from sparkfun, I am having trouble with it... lots..

I am using an OOPIC to interface, the main problem I am having is that after clearning the lcd by using

lcd.value = 254
lcd.value = 1

all is good, but when I write to the lcd

lcd.string = "blah"

it doesn't always start at pos 1, after sending string, then clearing, i may end up with

lah

or lahb

its like its scrambled.

I recieved very little if any documentation with this lcd, can someone please tell me how to home the cursor ? also, how do i enable the backlight ? My order # was EB-1732, order date was 2-9-04

PLEASE HELP

you can see a video of what the lcd is dong briefly, at http://myweb.cableone.net/bolwire at the video 2 link

[transcendentnb2]

Ya know, i've run into that problem on my own (I have my own LCD from another project... not from Spark Fun, and I used the parallel interface).

If I recall correctly, it's simply a timing issue from when you issue the clear command and when you try to start entering text again (the clear command for the LCD will reset the cursor to the home position by itself). Try waiting a few miliseconds before sending more text.

Looking at an old project I did for school, I waited 10ms after clearing it. You probably don't have to wait that long, but that should work for you.

As for the other commands, it seems, going from the serial interface data sheet, that you can simply send the actual command to do whatever you want (direct pass to the LCD whether it be ascii character or special command... or anything). For the first row just send 0x80+cursor offset. For second row, 0xC0+cursor offset (after sending 0xFE first to designate the next character as a command, as you already know). So to set the cursor to the "home" position, just send the character 0x80.

You can find more info in the actual hd44780 datasheet (for more commands and such). Try looking for it here on sparkfun, datasheetcatalog.com, or I can put it somewhere for you to grab online if need be. I got to know that LCD pretty well last year...
http://www.sparkfun.com/datasheets/LCD/SerLCD-v2_1.pdf

[riden]

I agree with transcendentnb2 and think it is a timing problem. Oh, the many hours I spent when first working with these devices trying to figure out what I was doing wrong.

The clear and home commands require more time to process. Somewhere around 500us or maybe 2ms, I can't recall at the moment. I know that's vague, you could check the Hitachi manual. Try adding a few milliseconds of delay after sending those commands and I think you will find that things will look better.

Another thing to consider is to allow sufficient time for the LCD display to initialize upon powerup before trying to send commands to it. I wait at least 50ms after powerup before hitting the LCD. If you you start sending commands too soon, you may find that the display is blank or your data that is supposed to start at row 1, col 1 starts somewhere else.

[xflipperx03]

Well, ive put in a short delay, ive used up to 150ms before thinking that was it. Ive setup a short program to get rid of the extras.

Here's the code:

Dim LCD as new oSerial


sub main()
LCD.Baud = cv9600
LCD.Operate = cvTrue

oopic.delay = 50 'wait for everything to init

do
lcd.value = 254 'tell lcd we are sending cmd
lcd.value = 1 'clear lcd

oopic.delay = 100 'wait for the lcd to finish

lcd.string = "LCD CLEAR"
oopic.delay = 150
loop
end sub

I get these in this order, but not 100% the same each time i run it

LCD CLEAR

CLEAR

CD CLEAR

LCD
CLEAR

LEAR

CD CLEARL

also, i dont think this is v2, but when I ordered it, it was advertised, and my order slip, says w/backlight

[xflipperx03]

wow, i knew i wouldn't get a response from sparkfun, they have ignored me on this issue for about 2 years. But i figured someone in the forum would be willing to help. Save your money folks, and check out the guarentee/warrenty.

Your promised a good product. but there is no warrenty because sparkfun is a 3rd party "profit maker"

fucking fags'

[busonerd]

Yeesh man - chill pill time.

Have you checked:

- Noise on the TX / RX lines
- Noise on the power supply

If not - check them.

--David Carne

[Philba]

hard problems are easy to ignore. especially when the guy asking for help is rude and abusive....

do you have bypass caps for each IC? I'd put one on pwr and gnd at the lcd connection. I agree that this is probably noise. make sure your LCD wires don't run across the processor clock circuts and power supply. What is your power supply like? big enough filter caps? (ripple might cause this sort of problem). are you using a solderless breadboard? the unused rails can capacitively coulpe and help create a noise rich environment.

it wouldn't hurt to put up a schematic even though it probably is pretty minimal.

Not for the faint of heart - SFE provides source code for the onboard PIC. You might want to crawl through that. it seems like there were some timing issues early on. I don't think you can just recompile the code since they changed some pin assignments. If you do tweak the code, make sure you save a copy of the existing code in a hex file.

and remember to say please and thank you. it really does work.

[Vraz]

I have not used the SFE SerLcd though had similar problems in my early days of interfacing LCDs to microcontrollers without using the busy pin (which lets you detect when the LCD is unable to process a command). Because the problem seems to primarily happen during screen clear, it looks like a timing issue (though the other suggestions of circuit noise are certainly worth investigating).

A couple of things to try:

1-Try sending a 254/12 after the 254/1. This is essentially a NOP as it just enables the display (which is already). If by chance the display is behind by one character, that could force an update without the command taking more time (versus sending a second clear which would certainly do no good).

2-Try putting a delay between each charcter send. I believe oopic.delay is in 10ms units so a delay of 1 would be fine.

Even in my old designs I was able to get the display to work once I nailed the timing though it was a pain and required a bunch of experimentation.

[xflipperx03]

The serlcd is connected to an OOPIC II+ though a pair of non-twisted and non-shielded wire. The supply to the lcd is from the 5v that the oopic II provides though the on-board regulator. althought thats only 20ma, may not be enough.... the supply for the oopic is a 9v battery. can post more details if needed. time issue sounds more the problem because the first thing sent to the lcd is always correct.

[busonerd]

the 20ma sounds dodgy to me - you probably are getting dropouts when it starts doing stuff.

Try driving it with a 7805 instead /w proper filter caps on it.

--David Carne

[Philba]

the 20ma sounds dodgy to me - you probably are getting dropouts when it starts doing stuff.

Try driving it with a 7805 instead /w proper filter caps on it.

--David Carne

I agree that 20mA might as well be nothing but the datasheet says 3 mA without backlight, 60 mA with BL. BL on or off? It might not be a bad idea to measure it before building a seperate PS. Use a DVM on current setting in series with the power.

Given what he posted earlier, I don't believe its a timing problem. First, he put lots of delay in his code but, more importantly, the serial controller (a PIC) handles all the timing issue. at least the code make me think that.

Phil

[Vraz]

Given what he posted earlier, I don't believe its a timing problem. First, he put lots of delay in his code but, more importantly, the serial controller (a PIC) handles all the timing issue. at least the code make me think that.

Looked at the source code. There are multiple versions of the firmware and multiple versions of the PCB (which don't correspond). According to the comments:

01-16-04: PCB version 1.0 (PIC 16F630 based, software UART)
02-16-04: PCB version 1.1 (PIC 16F630 based, software UART)
02-03-04: PCB version 1.1a (PIC 16F630 based, software UART)
12-15-04: PCB version 1.2 (PIC 16F688 based, hardware UART)

01-16-04: Firmware version 1.0
01-30-04: Firmware version 1.1
02-10-04: Firmware version 1.2 (added backlight control)
02-17-04: Firmware version 1.3

In fact there are other references to board/firmware revisions that don't even have version numbers. In any case, given the OP purchase date of 2-9-04 that would indicate PCB version 1.1 and Firmware version 1.2.

All versions prior to PCB 1.2 use a PIC 16F630 which bit-banged the serial port (no hardware UART). I suspect the pre-1.2 versions did no buffering (as the 1.2 comment lists buffering as a new feature). As a result, while the old firmware may have looked at the busy flag, it was pointless because while busy waiting on the LCD, the software UART was not running and would lose characters.

Also if you look at his video, it sure didn't look like the BL was on though I will let the OP comment on that. Note the following comment indicating a fix in the v1.3 firmware to address certain timing issues:

2-17-04 v1.3 Timing has now been nearly reduced to within one stop bit. In the past, wrapping characters were some times lost because of the time required to relocate the cursor. Now almost all characters are seen, every time, every location. There are stuff certain combinations that cause a character miss.

[sparky]

wow, i knew i wouldn't get a response from sparkfun, they have ignored me on this issue for about 2 years. But i figured someone in the forum would be willing to help. Save your money folks, and check out the guarentee/warrenty.

Your promised a good product. but there is no warrenty because sparkfun is a 3rd party "profit maker"

It's the profit maker here. EB-1732 indicates you were an *ebay* customer roughly 11,000 orders and 2 years ago. Thanks for taking a jab about tech support I may or may not have provided.

Looks like Phil, David, Vraz and a few others have taken the time to help you out. Please thank them if you get the chance.

Please send me an email spark @ sparkfun.com. I would be happy to have you return the unit and I will send you the $20 you paid on ebay. I'll give the unit to my 5-year old nephew to play with. He likes to play robots too.

If you're done calling me names here's a couple suggestions:

1) I dunno what version of the SerLCD you've got. It should say the PCB rev on the board and the firmware rev when you power-up the LCD. Quite potentially it's our fault. We went through a lot of revision as the code and Vraz point out. If you can't get it working, we'll get you one of the newer versions.

2) Send a series of characters to the LCD, with a 1 second delay between characters. Something like 'A', 'B', 'C', etc. Continue for A to Z. You should see the characters correctly wrap from end of line 2 to beginning of line 1. If it wraps funny (like not at all), there's probably something screwy going on with the firmware. If certain characters don't show up or spaces start appearing, then your OOPIC is sending something other than the serial streams you are asking it to.

3) I'm totally confused by your OOPIC onboard regulator statement. I've never seen a board with a 20mA regulator. Here are the OOPIC schematics : http://www.oopic.com/schem.htm Looks like a 7805 but not in their pictures. I can't see a regulator on their board and their schematics have no part numbers.

Do you mean the OOPIC is powering the LCD directly with an I/O pin? This is a common trick with PICs but is limited to 20mA of current.

Either way - you'll need to power the SerLCD with a clean 5V source that can handle atleast 100mA of current.

-Nathan

[xflipperx03]

I was brushed off so many time by tech support I came here as a last option. Thanks to all those who have replied. The regulator on the oopic is a 7805 as shown here http://www.oopic.com/morepower.htm, it is good for 100ma, the lcd is being powered by that, not an I/O Pin. When powering on the LCD it shows

SparkFun.Com
ServLCD V1.0


I have been operating this with the backlight off, I am not able to get that to come on at all, never have been able to.

Ok, using your suggestion, here we go:

Dim LCD as new oSerial

Sub Main()

LCD.Baud = cv9600
LCD.Operate = cvTrue

LCD.Value = 254
LCD.Value = 1

oopic.delay=100
LCD.String = "A"
oopic.delay=100
LCD.String = "B"
oopic.delay=100
LCD.String = "C"
oopic.delay=100
LCD.String = "D"
oopic.delay=100
LCD.String = "E"
oopic.delay=100
LCD.String = "F"
oopic.delay=100
LCD.String = "G"
oopic.delay=100
LCD.String = "H"
oopic.delay=100
LCD.String = "I"
oopic.delay=100
LCD.String = "J"
oopic.delay=100
LCD.String = "K"
oopic.delay=100
LCD.String = "L"
oopic.delay=100
LCD.String = "M"
oopic.delay=100
LCD.String = "N"
oopic.delay=100
LCD.String = "O"
oopic.delay=100
LCD.String = "P"
oopic.delay=100
LCD.String = "Q"
oopic.delay=100
LCD.String = "R"
oopic.delay=100
LCD.String = "S"
oopic.delay=100
LCD.String = "T"
oopic.delay=100
LCD.String = "U"
oopic.delay=100
LCD.String = "V"
oopic.delay=100
LCD.String = "W"
oopic.delay=100
LCD.String = "X"
oopic.delay=100
LCD.String = "Y"
oopic.delay=100
LCD.String = "Z"
oopic.delay=100

End Sub

Heres the results:

Try 1
http://myweb.cableone.net/bolwire/video/lcd_1.wmv
Try 2
http://myweb.cableone.net/bolwire/video/lcd_2.wmv

the 2nd one you have to pay attention to, after K it wraps back to first line pos 1

thanks

[Vraz]

This is bizarre. Its clear that no data is being lost (all the letters show up). However, the cursor gets repositioned. The LCD controller would not do that on its own and it seems unlikely to be damaged in such a way to otherwise work fine.

In looking at the PIC code for the SerLCD, it has line wrap functionality built into it (at least in V2). I wonder if the line wrap code is being triggered incorrectly. That would cause this kind of problem.

Questions:
1- Were the two runs made one after another without powering off the display?
2- If you power off the display and then make both runs again, are the results consistent (that is, does power off return the sequence to its starting state)?
3- What command did you use to try and turn on the backlight (unrelated, but might help understand the version).

Suggestion:
After the 254/1 and before the letters send a 254/128. That forces the cursor position to the start of the display. The current SerLcd code looks for that and resets its internal cursor position based upon it. Don't know if it was in the older code or not.