next topic »

[on:]

So I have an lcd display hooked up to my arduino (Pins 7-12)
When I first boot up the arduino, the LCD displays the first line as blocks at about 50% contrast. Once I hit reset on the arduino, it works as expected. I have no idea what is wrong, any ideas?

[Reply #1 on:]

I am replying partially because I eant this to appear on my updated posts list for easy track of this thread. I have seen several occasions of this problem lately and know no solutions yet.

could you post your code and pic of connection?

[Reply #2 on:]

I seem to recall that many LCD display/controllers take a pretty long time to perform their powerup/reset function. Maybe try a simple easy experiment and use a delay(5000); as the very first statement in the void setup() function to make sure the lcd is really ready to accept commands.

Lefty

[Reply #3 on:]

delay(5000);
at the beginning of void setup() worked like a charm. While it still displays the block for the first couple of seconds, once my text initializes, it works fine.

[Reply #4 on:]

Alright. I'll let the other guy know too.

[Reply #5 on:]

The LCD clock will be around 7Mhz, perhaps less, and needs half a dozen clocks to initialise. Asside from the power rail stabilizing at 5v (the arduino will probably run or spin up the oscillator from 3.3v already if you have a -V chip).
Basically means waiting about 50ms will get you into the clear unless you have access to the actual shipset datasheet in which case you can bring the delay down.
Alternative #2 is to use a R-C network of 100nf and a 10Kohm resistor to hold the LCD in reset for long enough. Option #3 is to tie your reset pin to the LCD, although not a bad plan, it will interfere with the downloader, hope these comments help.

[Reply #6 on:]

A little more information. When this happened, I had a button wired up to the reset pin. To have this work, you have to have the reset pin tied to a HIGH rail

[Reply #7 on:]

I am curious whether the LiquidCrystal routines I worked on (which have longer delays at startup than the one that is packaged with the standard Arduino package) will work for you without the 5 second delay.

If it does not work, it would be helpful to me to purchase an LCD exactly like the one you have to fix the code. Currently the most finnicky LCD I have is one I bought from the local Axman surplus store.

Anyway if you could try my code and see if it solves your problem without the 5 second delay I would appreciate it.
http://code.google.com/p/liquidcrystal440/

[Reply #8 on:]

I bet I have the same display (20X4 no back light) from Axeman store. I ended up not using it at all. It requires delay after every lcd command. I don't think the display is up to spec. There are still a box full of these displays in their main store.

[Reply #9 on:]

The axman display I have does work with the versions of LiquidCrystal I have. I actually have 2 of those LCDs and they both seemed to have identical timing characteristics. One thing I have puzzled over without success is if there is a way to explore exactly what is going on with them by comparing the time it takes to write characters when I wait for the busy flag vs what it takes as a timed delay between characters. There is a big difference in throughput with the two methods. Using the busy flag comes considerably closer to what my other displays do, but is still slower. It seems to me that there may be some specific situation that is slow on these displays and it would be interesting to figure out what it is. Anyway if laptopman has a display that is worse than the axman display I would like use one to make my code even more bulletproof.

One thing I did not mention in my previous post is that if you switch to my code and use the rw line, it will test the display's busy flag and that will likely be more reliable. You certainly won't need extra delays after each character. The busy flag cannot be used for the initialization sequence called either by LiquidCrystal lcd(rs,rw,en,...) or begin(), however. The initialization sequence requires timed delays.

If I remember correctly even the axman display works faster testing the busy flag than the standard LIquidCrystal routine (which never tests the busy flag) will work with a 'good' display. I might be misremembering that. If Don has any insight into how to understand just how I could structure  test or what to look for to understand what situation in a sequence of characters sent to the LCD is the slowest thing I would be interested. Maybe there is something that could be done to the non busy flag testing version of my code.

[Reply #10 on:]

still got the problem with mine, delay does not seem to help, I've even tried up too 10 seconds

[Reply #11 on:]

Where can I buy one just like it? model number etc.

[Reply #12 on:]

Where can I buy one just like it? model number etc.

I know that's not aimed for me, and I'm sorry to hijack but Id be happy to send you one of the screens that I'm having the same problem with if you cover say half the postage with me?

[Reply #13 on:]

well two of my screens are now on their way to mr Raines for testing.

I have also purchased 2 other screens and they act exactly the same

they are..

http://www.ebay.co.uk/itm/160633652459?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649#ht_3834wt_957
http://www.ebay.co.uk/itm/190345879489?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649#ht_3812wt_906

[Reply #14 on:]

Looking at the LiquidCrystal library source in Arduino-0022, I see that the LiquidCrystal constructor makes a call to begin(), which delays for 50ms and then sends commands to the LCD. So it is quite possible that the LCD is receiving commands before it is ready, if the supply voltage rises slowly at power up.

I suggest removing the begin() call from the LCD constructor. A call to begin() should be made in setup() anyway. If the LCD still doesn't work until the reset button is pressed, then Lefty's suggestion of inserting at delay in setup() before the begin() call should fix it.