Struggling with LCD.

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi there,

I'm struggling to a get a hitachi compatible LCD to work.
it initialises and now all I see are 32 black squares. I've tried adjusting the contrast but it doesn't seem to help.

The header files and background code comes from http://winavr.scienceprog.com/ex...

I've been over all the connects in the hope of finding a fault. So now I'm stuck and not sure where to look next.

The LCD is a topway LMB162ABC and the chip is a mega 324.
I've attached the entire project file if that will help. Thanks.

#define F_CPU 41943000
#include 
#include 
#include 
#include 
#include "LCD/lcd_lib.c"
#include "LCD/lcd_lib.h"

#define LEDGRNPIN PD5 //Green LED to Pin D 5
#define LEDREDPIN PD6 //Red LED to Pin D 6
#define LEDPORT PORTD //Set LED output port. 



/*---------------------------------------------------
LED Indicator Lights. 
Red == Fault
Green == OK
Red&Green == Busy
---------------------------------------------------*/
void LED(char colour)
	{	
		switch(colour)
		{
			case 'O':
			{ 
				//flash GREENLED
				LEDPORT |= (1 << LEDGRNPIN);    // switch on
    	    	_delay_ms(200);
	    		LEDPORT &= ~(1 << LEDGRNPIN);    // switch off
    			_delay_ms(200);
				break;
    		}

			case 'F':
			{ 
				//flash REDLED
				LEDPORT |= (1 << LEDREDPIN);    // switch on
    	    	_delay_ms(200);
	    		LEDPORT &= ~(1 << LEDREDPIN);    // switch off
    			_delay_ms(200);
				break;
    		}
			
			default:
			{
				//flash BOTH
				LEDPORT |= 1 << LEDREDPIN | 1 << LEDGRNPIN;    // switch on
    	    	_delay_ms(200);
	    		LEDPORT &= ~(1 << LEDREDPIN )& ~(1 << LEDGRNPIN);    // switch off
    			_delay_ms(200);
				break;
			}
		}
	}





	

int main(void)
{
	DDRD = 0b01100111; //Set port D0,1,2,5,6 to output
	DDRC = 0b11111111; //Set port C to output
	LCDinit();//init LCD 8 bit, dual line, cursor right
	_delay_ms(1);
	LCDclr(); //clr LCD
	_delay_ms(1);
	LCDhome(); //return cursor to 0

	while(1)
	{
	
	LED('F'); //Flash red LED
	LCDstring("Hello /n World", 11); //Send string to LCD; 
	_delay_ms(100); 
	LCDclr(); //Clr LCD

	}

	
	return 0;
}

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the '324 have jtag on portc? If so, you need to disable jtag. See the datasheet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
it initialises and now all I see are 32 black squares. I've tried adjusting the contrast but it doesn't seem to help.
The data sheet shows a 5K rheostat connected between pins 1 and 3. The more common recommendation is a potentiometer (anything between 5K and 20K) with the ends connected to pins 1 and 2 and the wiper connected to pin 3. You might want to try that connection.

Don't you need some more defines to let the library know how your LCD is connected to the processor?

Don

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

floresta1212 wrote:
Quote:
it initialises and now all I see are 32 black squares. I've tried adjusting the contrast but it doesn't seem to help.
The data sheet shows a 5K rheostat connected between pins 1 and 3. The more common recommendation is a potentiometer (anything between 5K and 20K) with the ends connected to pins 1 and 2 and the wiper connected to pin 3. You might want to try that connection.

Don't you need some more defines to let the library know how your LCD is connected to the processor?

Don

That set up in the header file. You edit 2 lines of code in the simple version :) (3 in the extended version)

And yes, I have the contrast set correctly, that was the first thing I tested. I built an LCD tester using the mega 8 and hex file included on that page when I thought I'd blown something last week.

I think I have a 20k pot and I have a 100 ohm on the VCC and ground connections. :)

Anyway, thanks all. :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The F_CPU is 41MHz? That must be a typo.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do you see as the advantage of using 8bit rather than 4bit mode anyway? And did you know your C compiler already came with this:

http://www.nongnu.org/avr-libc/u...

(if nothing else you could use that to prove the electronics but it's for 4 not 8 bit mode - though I guess the other 4 data lines still being connected doesn't matter?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
The F_CPU is 41MHz? That must be a typo.

:lol: Well Spotted. It should be 4.1Mhz. That's what the crystal is.

Which reminds me, I need to order a 16Mhz crystal.

clawson wrote:
What do you see as the advantage of using 8bit rather than 4bit mode anyway? And did you know your C compiler already came with this:

http://www.nongnu.org/avr-libc/u...

(if nothing else you could use that to prove the electronics but it's for 4 not 8 bit mode - though I guess the other 4 data lines still being connected doesn't matter?)

I don't know. 1 less cycle for each write? I know 8 bit uses more pins, but I can probably get away with it on this project. If not, I'll add in the line for 4bit mode.

I wasn't able to get the libc LCD library to work. In retrospect I probably could now, though I don't see any point to it on this project at this point.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I wasn't able to get the libc LCD library to work. In retrospect I probably could now, though I don't see any point to it on this project at this point.

Except it reduces the number of variables that you have to deal with as we know the "odedemo" works flawlessly.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is your LCD initialization code? All black squares issues result from initialization not done right. Usually it's a timing issue.

By the way, I have had good luck with all my LCDs putting a diode (1n914) on the contrast voltage pin instead of a pot. The cathode goes to ground and the anode goes to the contrast pin. That's it. This puts +0.7V on the contrast pin which seems to be a good visible contrast level.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ZAPrime wrote:
Quote:
What do you see as the advantage of using 8bit rather than 4bit mode anyway?

I don't know. 1 less cycle for each write?


Except that these LCDs are so....dang....slow that the saved cycle doesn't matter. Worst case timing between two writes is 50us, or 800 cycles at 16MHz.

I used to be afraid of 4-bit mode, but now it's all I ever use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
What is your LCD initialization code? All black squares issues result from initialization not done right. Usually it's a timing issue.
Not exactly. ALL black squares typically indicate an improper contrast setting. Only HALF the squares are black when it isn't initialized properly.

Don

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That lcd_lib.c in that zip file uses a 1ms delay in the E pulse. Sheesh. After all the grousing about how to save every usec down in the lo level routines, heres a chance to speed a routine up by 500 times.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
That lcd_lib.c in that zip file uses a 1ms delay in the E pulse.

I wonder if that was a typo, as 1 uS. is quite sufficient. A 1000 times improvement!

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Quote:
That lcd_lib.c in that zip file uses a 1ms delay in the E pulse.

The initialization routine is not correct either. Most of the delays are longer than necessary but at least two of them are too short.

Don

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Worst case timing between two writes is 50us, or 800 cycles at 16MHz.
If you mean by that the time necessary to write the second byte, then that is a gross over estimate. There needs to be at most 1µs between the first and the second nibble of a command. Any processing delay the LCD has is between commands, not between nibbles.
Quote:
That lcd_lib.c in that zip file uses a 1ms delay in the E pulse.
No it doesn't, it uses two 1ms delays :)

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
Quote:
Worst case timing between two writes is 50us, or 800 cycles at 16MHz.
If you mean by that the time necessary to write the second byte, then that is a gross over estimate. There needs to be at most 1µs between the first and the second nibble of a command. Any processing delay the LCD has is between commands, not between nibbles.

Yes, I was referring (clumsily) to the time between commands; in particular, between writing consecutive characters. The "save a cycle with 8-bit mode" is insignificant when it takes as much as 1600us (25,600 cycles @ 16MHz) to write a full 16x2 display screen.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I said, I don't know. I cited the only essential difference between the way they work.

I was made aware of how sluggish character displays are last night. You are right that it's insignificant in comparison.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ZAPrime wrote:
As I said, I don't know. I cited the only essential difference between the way they work.

I was made aware of how sluggish character displays are last night. You are right that it's insignificant in comparison.


What amazes me is that these displays are no faster than they were 30 years ago. 1.6ms to write 32 characters?! It just offends my sense of How The World Should Be.

I'm often tempted to program up a small AVR to do the spi-to-parallel so I can dump out a display in a few tens of microseconds. I know that spi displays can be had but they're quite a bit more expensive. Anyway, I'm often tempted, but I never actually do it, because I know that it doesn't _really_ matter, and if it did really matter it's because I'm running at 99% of uC capacity and I'd better rethink the entire product design right away.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What amazes me is that these displays are no faster than they were 30 years ago.

Becausse in the applications where they are used, no higher speeds are needed?

Other things with more or less unchanged speeds for 30 years: Cars, airliners, subway-trains...

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Becausse in the applications where they are used, no higher speeds are needed?

Also the pixels take 200ms to turn on and off so attempting to drive them any quicker is futile (in fact it will cause blur as you'll effectively be temporally performing PWM on some)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Quote:

What amazes me is that these displays are no faster than they were 30 years ago.

Becausse in the applications where they are used, no higher speeds are needed?

Other things with more or less unchanged speeds for 30 years: Cars, airliners, subway-trains...


Yep, in reality updating a display 5 times a second is 8-10ms/second or at most about 1% of total time (and it's a low-priority task to boot). Any system that can't take that hit has far bigger problems. It just grates on me that between every character write I have to waste as much as 1000 cycles (20MHz AVR) or 5000 cycles (100MHz ARM). Perhaps I could be helped by intensive therapy. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Develop an interrupt driven background task to update your display, then you won't be wasting cycle time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dksmall wrote:
Develop an interrupt driven background task to update your display, then you won't be wasting cycle time.

You're right, at some point with faster processors it makes sense to go that route, and I have done it. But then what could I complain about? Oh, I know, PWM modes that don't allow both full on and full off. :twisted:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The bigger question is what happens when cortex m3 becomes the norm. 70Mhz right now, maybe a few hundred in a years time. Can those displays handle that much speed and information. Or is the only way forward, colour LCD displays?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Can those displays handle that much speed and information.
They would never need to, the display will never need to do anything faster than the human brain can process.

Regards,
Steve A.

The Board helps those that help themselves.