Go Down

Topic: New Haven LCD accepts numbers not strings (Read 2 times) previous topic - next topic

wolverineairsoft

This is a continued topic from http://arduino.cc/forum/index.php/topic,121544.msg943204.html#new.

Since it has become more of a question regarding the display I thought it would be appropriate to start a thread here. Hopefully that doesn't give anyone heartburn.

Here's the situation:

UPDATE:

Progress! I finally got access to an xp computer. got ide installed and the libusb0.dll driver for the MKII. It did exactly the same thing as with AVR studio. I wrote a simple blink code and wha-do-ya-know...it worked!

At this point I have determined that there is a problem somehow with the lcd screen. I checked that all my pin assignments are correct. It will initialize with no problem and give me a cursor. I can even move that cursor anywhere I want. I can turn the back light on and off. However when I try to print to it, it does essentially nothing. If I tell it to print any single character (that I've tried) it prints a bunch of spaces followed by "45" followed by more spaces. It's late, I have to go to bed. but if anyone has ideas as to what the problem might be, please let me know, thanks! Goodnight world.



Interesting. It prints numbers correctly if I give it the correct base input. So somehow it's just not handling the strings I'm trying to feed it properly...hmmmm.....



newhaven COG character display. 2x16. I am using the doglcd libraries. print command is supposed to accept a variety of character inputs. strings, char*, etc. without sepecification. I am simply feeding it this:

lcd.print("hello world!");

and it is not dealing with it properly.

I do not know what you mean by "how is it connected". would you like a diagram? It is mounted on a custom pcb which essentially acts like a 3.3v arduino mini with atmega168. it uses pins: (8, 7, 5, 6, A3, A4) as I recall. initializes properly with those pins. If you are wondering if it's a connection issue, it is rather unlikely. possible that I crossed a wire on the board, but the population is professionally done by a lady that does custom boards for the military. Most likely the problem lies elsewhere. I can post schematic and brd layout if anyone is interested in looking at them.


Thanks!

wolverineairsoft

Going to try lcd.write instead of print to see what that does. seems like the write command at least is functioning since it's writing number. seems like it's just the print command that is causing problems. I did have issues with getting the libraries formatted correctly, so maybe it's a glitch from that.

wolverineairsoft

So, result of tonights experiment. using .write() and feeding that a hex value I can display any character that I want. Just like the datasheet diagram: http://www.newhavendisplay.com/specs/NHD-C0216CZ-NSW-BBW-3V3.pdf

so if I feed it: lcd.write(0x34) it displays a 4. so I've somehow got a software bug. it would seem that the print command is not working. I understand why.

wolverineairsoft

More progress!  I wrote a simple code that only controls the lcd and none of the other stuff on the board and it works! so apparently there's something in my code that is causing the lcd to malfunction. will rebuild code piece by piece at this point and try to determine what it is. this is superb news. :-D

wolverineairsoft

So I think I have found the culprit. I initialize a series of char* indices that will be used to display menu text on the lcd. That causes the lcd to not work properly when I feed it a string. The strange thing is it worked on my prototype with no problem. Any ideas why this might be/how to fix it? below is an example of the code that is causing problems.

Code: [Select]
char* Returntime[12] = {"      0 msec      ", "      1 msec      ", "      2 msec      ", "      3 msec      ",
"      4 msec      ", "      5 msec      ", "      6 msec      ", "      7 msec      ", "      8 msec      ",
"      9 msec      ", "      10 msec      "};

Go Up