Go Down

Topic: New Haven LCD accepts numbers not strings (Read 2414 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      "};

wolverineairsoft

I found the exact offending piece of code. all the other char*'s do not cause a problem, just this one. no clue why. Any thoughts?

char* sps[44]={"       8        ", "       9        ", "       10       ",
"       11       ", "       12       ", "       13       ", "       14       ",
"       15       ", "       16       ", "       17       ", "       18       ",
"       19       ", "       20       ", "       21       ", "       22       ",
"       23       ", "       24       ", "       25       ", "       26       ",
"       27       ", "       28       ", "       29       ", "       30       ",
"       31       ", "       32       ", "       33       ", "       34       ",
"       35       ", "       36       ", "       37       ", "       38       ",
"       39       ", "       40       ", "       41       ", "       42       ",
"       43       ", "       44       ", "       45       ", "       46       ",
"       47       ", "       48       ", "       49       ", "       50       "};

wolverineairsoft

More strange problems the timer appears to not be working correctly. it is moving far to slow. In fact as best I can estimate it, delay(1000) actually produces a delay of 7.8 seconds. That would seem to indicate the clock is running at 1MHz. do not understand that. I am using an 8MHz crystal resonator and programmed it as 8MHz. Tried programming it as 16MHz and it now takes just under 16 seconds. So clock is definitely running at 1MHz

Perhaps these issues are related, if the clock is messed up perhaps that's somehow messing with serial communication with the lcd screen.

floresta

#7
Oct 05, 2012, 05:08 am Last Edit: Oct 05, 2012, 05:14 am by floresta Reason: 1
I went back to the original thread to find out that you are using a custom board and an AVR ISP MKII programmer.  That leads me to suspect that you may not have set the fuses properly.  So - how are your fuses set?

8.2.1 Default Clock Source
The device is shipped with internal RC oscillator at 8.0MHz and with the fuse CKDIV8 programmed, resulting in 1.0MHz system clock
.


Don


wolverineairsoft

Thank you! I had just discovered that. I do not know how to set the fuses, or what they should be set to work with the ceramic resonator I'm using. I'm quite sure that is the issue. I'm programming the board directly not bootloading it. The data sheet has different settings:

Device clocking option CKSEL3..0
Low power crystal oscillator 1111 - 1000
Full swing crystal oscillator 0111 - 0110
Low frequency crystal oscillator 0101 - 0100
Internal 128kHz RC oscillator 0011
Calibrated internal RC oscillator 0010
External clock 0000
Reserved 0001

It's still all greek to me as I don't know how to set the fuses. never had to mess with it before.

wolverineairsoft

Google produced results on how to set fuses with AVR Studio but not with Arduino without bootloading it. I saw a couple things that mentioned it but the explainations were much to high level for my very elementary understanding of the subject.

From the data sheet I got the list of fuse settings I posted above. Which of those settings corresponds to an external ceramic resonator?

floresta

Quote
I do not know how to set the fuses ...

There is more than one way to interpret this statement.
(1) I know what the settings should be but I don't know how to actually program the fuses.
(2) I know how to program the fuses but I don't know what the settings should be.
(3) I don't know what the settings should be but even if I did I don't know how to set them.

I think we are dealing with # 2 so I will proceed on that basis.


Quote
Google produced results on how to set fuses with AVR Studio but not with Arduino without bootloading it.

I think you are concerned with the fact that the published (http://www.codingwithcody.com/2011/04/arduino-default-fuse-settings/) Arduino fuse settings assume that there is a bootloader present and set the reset vector appropriately.  When you program with the AVR ISP you wipe out the bootloader but the reset vector still assumes that the bootloader is there.

This is a valid concern and theoretically you should change the appropriate fuses which then makes the values from the aforementioned link invalid.  What I have found is that currently this is not a problem.  Apparently the hex codes in the unprogrammed bootloader area are treated as NOPs and the processor just proceeds through that area and falls into the program code area.  In in other words I don't bother resetting the fuses when I switch from using the Arduino IDE with the bootloader to using the AVR ISP without one.  I use the fuse values appropriate for the Arduino and just leave them set that way.  Note that this operation could possibly change in the future.


Don


wolverineairsoft


I do not know how to set the fuses, or what they should be set to work.


We are actually dealing with situation 3.

I'm afraid you are giving me a little more credit than I deserve. This is my first project with a microcontroller, so it is best to assume that I know very little. To be exact, this is a custom board that is running a Atmega168a with an external 8MHz ceramic resonator. It is basically all the components of an arduino pro mini on a custom board with a 4 bit newhaven LCD COG 2x16 display. The chip is running at 3.3V.

Do you have a reference for the process of setting the fuses through IDE or is it best to do another proceedure for setting the fuses? (say AVR Studio) Thank you for the reference for the correct fuse settings. Why are the settings different from the Mini to the Pro mini? I believe that the correct settings for me would be the "Pro Mini" settings:

Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega168
Low Fuse 0xC6
High Fuse 0xDD
Extended Fuse 0×00

floresta

Quote
Do you have a reference for the process of setting the fuses through IDE or is it best to do another proceedure for setting the fuses? (say AVR Studio)

I don't know about the IDE, I have always used AVR Studio 4.  When you invoke the programmer there are several tabs.  Select the 'Fuses' Tab and then put your Hex values in using the lower section of the window.

Be absolutely sure that you put the correct value in the correct place.  If you get them mixed up you can make your chip appear bricked requiring the use of programming techniques not provided by the AVR ISP to undo.  Don't ask how I know this.


Quote
Why are the settings different from the Mini to the Pro mini?

I am not familiar with either.

Don

Go Up