My lcd isn't displaying properly using ac adapter

My lcd works fine through usb, but when i switch over using the ac it shows nothing. The blacklight is on, but it seems dimmer than before.

???

Sounds like your AC supply isn't putting out enough power. What's it rated for?

Ran

5v.... the guy at the store said that is what i needed.

How much current is it supposed to supply? It's probably enough, but might not be.

Also, which flavor of Arduino do you have? The boards I use almost all have an on-board voltage regulator, so they're supposed to be fed about 7-12V. But some versions don't have a regulator, and need a 5V supply.

If your board has a 5V regulator, feeding it 5V won't work, and may produce the kind of symptoms you're seeing.

Ran

sorry im new to all of this.

the adapter i have is DC+5.0V @ 1200mA
100-240VAC, 50/60Hz.

I have a red duemilanove.
errr basically im connecting the pins from the lcd to the "5v" on the arduino.

ok i think your right... this is from the description ". If supplied with less than 7V, however, the 5V pin may supply less than five volts and the board may be unstable."

Oops :wink:

You may want to hold on to that 5V supply: remember that the Arduino is limited in how much 5V it can provide to things you attach to it. If you want to experiment with, e.g., servos, a 1200mA supply is a nice size to run a couple.

The good news is that the supply for the Arduino doesn't need to be a more-expensive regulated one. You may already have a wall wart lying around for some other purpose that you can connect to it. If it's not regulated, I'd stick to about the 7-9V range, because unregulated supplies can swing much higher than their nominal voltage rating if you're not drawing near the rated amount of current. E.g., a 12V supply may well put out 17-18V if it's supplying little or no current.

Ran

geestring:

Some programmers, including the anonymous one who wrote the LiquidCrystal library, use an LCD initialization technique that will not work reliably with some power supplies. I have an explanation and a fix which you can access at http://web.alfredstate.edu/weimandn. Follow the link to LCD Initialization for the explanation and follow the link to LiquidCrystal library for the fix. This is on the list of things to be fixed but didn't make it into Arduino-0016.

Don

Some programmers, including the anonymous one who wrote the LiquidCrystal library, use an LCD initialization technique that will not work reliably with some power supplies... This is on the list of things to be fixed but didn't make it into Arduino-0016.

Don,
Has updating the LiquidCrystal library been discussed in the developers forum? (I did notice anything on this topic)

I was looking at your latest code and was wondering why you replaced the commands in the init sequence with explicit loops that do the same thing as command. Perhaps I missed something but it seems the only functional difference with the new code over your previous version is the delay times, is that the case?

This is my four bit constructor, does it do anything different from the code you posted ?

LiquidCrystal::LiquidCrystal(uint8_t rs, uint8_t rw, uint8_t enable,
  uint8_t d0, uint8_t d1, uint8_t d2, uint8_t d3) :
  _four_bit_mode(1), _rs_pin(rs), _rw_pin(rw), _enable_pin(enable)
{
  _data_pins[0] = d0;
  _data_pins[1] = d1;
  _data_pins[2] = d2;
  _data_pins[3] = d3; 
  
  pinMode(_rs_pin, OUTPUT);
  pinMode(_rw_pin, OUTPUT);
  pinMode(_enable_pin, OUTPUT);
  
  for (int i = 0; i < 4; i++)
    pinMode(_data_pins[i], OUTPUT);

  command(30);
  delayMicroseconds(5000);
  command(30);
  delayMicroseconds(100);
  command(30);
  delayMicroseconds(100);
  command(20);
  delayMicroseconds(100);
  
  command(0x28);        //Function Set, D=0, N=1, F=0 (4 bits, 2 line, 5x8 dots)
  delayMicroseconds(80);
  command(0x08);        //Display ON/OFF Control', D=0, C=0, B=0 (display off, cursor off, blink off)
  delayMicroseconds(80);
  command(0x01);            //Clear Display
  delayMicroseconds(5000); 
  command(0x06);            //Entry Mode Set, I/D=1, S=0 (increment addresses, do not shift display)
  delayMicroseconds(80);  
  command(0x0C);            //Display ON/OFF Control, D=1, C=0, B=0 (display on, cursor off, blink off)
  delayMicroseconds(80); 
}

p.s. your send function adds a one microsecond delay after setting the enable pin high. Note that digitalWrite on a 16mhz arduino has a minimum pulse width of more then 2 microseconds, so the added delay is not really necessary, although it does have the advantage that if some future arduino version improves the performance of digitalWrite, your version will still respect the LCD specs.

I appreciate your efforts in resolving the compatibility some users have experienced, perhaps we can make a effort to get this addressed by the Arduino team.

Mem:

Has updating the LiquidCrystal library been discussed in the developers forum? ...

The Arduino home page has a link to the Arduino page on Google Code which in turn has a link to todo.txt. Item 40 on that list refers to my LiquidCrystal suggestions.

I sent an Email to the developers mailing list link on the Arduino home page and received a nastygram in return stating that my input was being held for consideration since it was a post by a non-member to a members-only list. There's no mention of that distinction at the linked location. The moderator did however ultimately post my Email, it's in the May 2009 archives.

I haven't seen any other references, but I haven't looked too hard either.

... why you replaced the commands in the init sequence with explicit loops that do the same thing as command.

In my first implementation I temporarily cleared the '_four_bit_mode' flag so that the send() function would use the 8-bit mode. I did not consider the fact that the 4-bit constructor, in addition to setting the '_four_bit_mode' flag, only created a four bit '_data_pins' array, into which I was trying to stuff 8 bits. I understand that this misuse of arrays will not cause compiler errors but will cause run time errors.

This is my four bit constructor, does it do anything different from the code you posted ?

This is a little long because it attempts to explain the most confusing part of the LCD initialization process:

When power is first applied to the LCD controller it comes up in the 8-bit mode. It doesn't matter whether the internal reset sequence has been successful or not it is still in the 8-bit mode. It doesn't matter how many data wires you have connected to it or how many you intend to use, it is still in the 8-bit mode.

Since it is in the 8-bit mode it expects a complete instruction (or data) byte to be on its 8 data pins each time the enable pin is strobed. Also, since the designers knew that some implementations would not have all 8 data lines implemented they set things up so that the four lower bits were insignificant during the start of the software reset and initialization sequence.

If and when the software initialization succeeds in switching the LCD controller to it's 4-bit mode the controller will then expect each data byte to come in two 4 bit nibbles. After the first enable pulse it temporarily stashes away the 4 bit nibble it has received. After the second enable pulse it takes the latest 4 bit nibble, tacks on the saved 4 bits and deals with the reassembled 8-bit instruction (or data).

The problem with the LiquidCrystal library is that the constructor immediately sets the '_four_bit_mode' flag so the send() function breaks the initial instructions into two 4 bit nibbles even though the LCD controller is still in the 8-bit mode. This means that when you send a command(30) the library breaks it up and sends it as two nibbles, 0011 and 0000. The LCD controller, still in the 8-bit mode, interprets this as two successive 8-bit bytes, 00110000 and 00000000.

Your first four initialization commands, 00110000, 00110000, 00110000, 00100000 are seen by the LCD controller as 00110000, 00000000, 00110000, 00000000, 00110000, 00000000, 00100000, and 00000000. My guess is that your routine works because the LCD controller ignores the 00000000 instructions, but you really can't count on this behavior.

your send function adds a one microsecond delay after setting the enable pin high

Other than when writing time delay routines I usually consider all instructions to take zero time, and put in delays where called for by the data sheet. That way, when I reuse the routine 10 or 15 years later, when the processors run 10 or 15 times faster, I don't have to fix anything. Anyone worried about the extra 1 microsecond should probably be using assembly language, and should also be using the busy-flag!

These LCD initialization problems seem to recur periodically in the forums. One solution would be a real 'FAQ' section. The current section with that title should really be renamed since it is being (correctly) utilized for the purpose in it's subtitle: "For issues that don't fit in any other board".

Don

Mem:

UPDATE -- From my earlier post:

My guess is that your routine works because the LCD controller ignores the 00000000 instructions, but you really can't count on this behavior.

It seems that you may actually be able to count on this behavior, which would make your solution legitimate. I found an "Extended Concise LCD Data Sheet" at www.electronic-engineering.ch/microchip/datasheets/lcd/the_lcd_data_sheet.pdf which does show the 00h instruction as a NOP. Unfortunately the author does not credit it's source and I have been unable to find confirmation anywhere else (so far).

Don