Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] LCD 162A interfacing with Atmega32L

Status
Not open for further replies.

raj.elec

Newbie level 4
Newbie level 4
Joined
Mar 23, 2010
Messages
7
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Location
Kharagpur (W.B.)
Activity points
1,333
Hi !
I am facing a problem interfacing "LCD 162A" with ATmega32L with frequency 6.144_MHz. However in Proteus software, it works. But in hardware, 1st it shows series of black squares in 1st line as expected but after that screen clears. I used ImageCraft for programming. I tried with different delays from µs to ms but there is no effect. I have used 8+3 communication mode with LCD. For 8 bit comm. with LCD, I used PORTC for "data & command" and PORTD-Pin5, Pin6, Pin7 as control Pins. I already disabled 'JTAGEN' fuse & set 'JTD' in 'MCUCSR', but it didn't work. Later on, I checked with another crystal, LCD, microcontroller, but same result occurs.

Can any one help me in this problem.
I attached my code files and diagram.

Immediate responce would be appreciated.
 

However in Proteus software, it works.

can you show us how it worked in Proteus?

if you show us that it works in Proteus, I will help you write out the rest of the code.
 
Mr. Millwood,
I am sending the proteus file and images of the working of the circuit in attachment. Proteus version - 7.1 SP2
Please look at these.
 

I cannot simulate it.

does it actually work in simulation?
 
raj.elec said:
Yes, it did work...
can you manage a pull up for the Reset line of ATMEGA, and adjust the contrast pot to get approximately 0.7V at pin3 off display. not that you don't know !!
 
Hi

If you have used the code as it is from hitachi or other datasheet, then I think you have not turned on the display (last or second last line in the datasheet).

please understand see this line again in the datasheet.

0 0 0 0 0 0 1 0 0 0

If you have squares and then clean display then you have initialised the lCD from default one line to two line. ms delay during init is enough to start with.

This is a fast one from me. If this is not the case then do let me know.

Hope it works. In any case from my experience you are very close.

Thanks
 
AVM_NOIDA said:
please understand see this line again in the datasheet.

0 0 0 0 0 0 1 0 0 0

I understood your point but I already wrote that line in my code as "LCD_WriteCommand (0x0f); // display ON". Please check in my code which I have uploaded named as LCD.rar that if there any problem in that.



millwood said:
if you send me the .hex file, I am happy to try on my simulator.

I am attaching the .hex file with this message.
 

Hi

0x0F is ok and yes it should have also shown in Proteus as blank LCD. I am going through your schematic and code. The first thing I noticed is your RESET does not have pull-up. If true please add a 10k to VCC.

Let me know the progress. I will revert back if I find something in the code.

Thanks
 
white blocks suggest incorrect initialization, which can be caused by

1) wrong initialization: your code has no explicit initialization for the lcd. it may have happened that the default setting in the simulation works for your model but not for the actual device. you should always consult the datasheet of your lcd for the correct initialization sequence.

2) the mcu not running. I usually flip an indicator LED in the main() loop as a way to test that the mcu is running. you should think about something like that as well.

hope it helps.
 
True Millwood the initialisation is not correct in the C code.


Hi Raj
Please see page 45 of Hitachi Datasheet. the first instruction 0x38 (000011****) must stay for significant time (use delay between instructions) for the LCD to enter into initialisation mode and start accepting your subsequent commands.

Just a properly written init routine with sufficient delays.

Thanks
 
millwood said:
I usually flip an indicator LED in the main() loop as a way to test that the mcu is running. you should think about something like that as well.

I checked the PORTC and PORTD pins after connecting some LEDs. It showed me the proper signals.

I adjust CKSEL 3..0 fuses, Now it works.

Many-many thanks to all of you for your precious time and support.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top