Hello, i have played around with the pic16f887 for years and now i got a new toy. It is an old 8051 study board with a phillips p89c664 chip.
It has a HD44780 LCD that i am trying to get to work. I have worked with LCDs in the past and never had problems, but this damn board writes instructions and data through buses what is pretty new to me. I initialized it successfully(i think) because i got the cursor blinking.
When i am trying to write a character onto the display things go wrong tho, and i am not quite sure why because i think i am doing "stuff right".


void lcd_test(void)
{
delay();
*instruction=0b10;
*data = 0b01001000;
*led=*read_instruction;
}
This function should write onto the display.
the instruction pins are on address 8001h and data is 8000h.
If required i can post a schematic of it.
Any tips or tricks are very welcome since i have been at it for hours now...

 

Interfacing to HD44780 via a bus should be no different than interfacing via a port. Make sure the data setup and hold times, and clock times are valid.

 

I used a code where i can see button presses printing on lcd to initzialize, and all i am trying to do is print the char H on the screen.
What do you mean by clock times.

*data would be the character H
and *instruction would this case be RS = 1

 

There are some subtle timing requirements on the individual pins. These are usually a "gimmy" when doing port access control as changes are spaced in time by seperate instructions. Such may not be true when using a bus with very tight timings. My first concern is how you apply RS before the E line. While RS is low during the init sequency it needs to change to set the data address (or where the letters go).

So yeah, got a schematic of your interface?

 

The attached datasheet from Optrex shows how to hook a 44780 type LCD controller to a variety of MPUs. Unfortunately the 8051 is shown as IO driven but hopefully some help. The 8085A and 8051 buses are similar in operation.
Enjoy.

 

What is this for "*led=*read_instruction;"
...shouldn't you be writing an instruction to the lcd!?
Sorry, I'm just interested but find that code a little confusing. I interface with LCDs using a PIC quite a lot.

 

How normal people do it: http://www.8051projects.net/lcd-interfacing/lcd-programming.php

 

I think most "normal" people do it in 4-bit mode, because then you only need one 8bit bus... but ok.

 

I think most "normal" people do it in 4-bit mode, because then you only need one 8bit bus... but ok.

Definitely not.
In 4 bit mode you have to send everything twice. First the high 4 bits, then the low 4 bits.

When I took uC class, we learned 8 bit mode first, then we were taught 4 bit mode. Like many others I see only one reason to use 4 bit mode, that is to use 4 pins on uC for commands/data. But if I have 8 pins, I will use 8 bit mode every time.

 

The biggest advantage with using 4 bit mode (other than being able to reduce the lines used on a uC) is actually that you can very easily solder a basic I2C based 8-bit I/O expander onto it, then communicate using only 2 lines, and that also includes things like toggling the backlight on/off.

Sure, you're using more writes, but then it can be offloaded to hardware (via a buffer and interrupt) and dealt with simply via a library/API, and LCD controllers are painfully slow devices anyway. By using 4bit mode and communicating via hardware I2C, I free up my main program quicker, so I can actually do more rather than less.

 

The biggest advantage with using 4 bit mode (other than being able to reduce the lines used on a uC) is actually that you can very easily solder a basic I2C based 8-bit I/O expander onto it, then communicate using only 2 lines, and that also includes things like toggling the backlight on/off.

Sure, you're using more writes, but then it can be offloaded to hardware (via a buffer and interrupt) and dealt with simply via a library/API, and LCD controllers are painfully slow devices anyway. By using 4bit mode and communicating via hardware I2C, I free up my main program quicker, so I can actually do more rather than less.

Bit banging i2c? We had it as assignment in my uC class.

 

Also to add, the addresses for the pins are like this. Ins

What is this for "*led=*read_instruction;"
...shouldn't you be writing an instruction to the lcd!?
Sorry, I'm just interested but find that code a little confusing. I interface with LCDs using a PIC quite a lot.

Yea me too, that just just a test line. Since i have addresses to read instructions and data, so i tried if it could be that simple. It wasnt .

Bit banging i2c? We had it as assignment in my uC class.

*
Im gonna do some banging on a 1-wire device soon, and i might return here with that

The biggest advantage with using 4 bit mode (other than being able to reduce the lines used on a uC) is actually that you can very easily solder a basic I2C based 8-bit I/O expander onto it, then communicate using only 2 lines, and that also includes things like toggling the backlight on/off.

Sure, you're using more writes, but then it can be offloaded to hardware (via a buffer and interrupt) and dealt with simply via a library/API, and LCD controllers are painfully slow devices anyway. By using 4bit mode and communicating via hardware I2C, I free up my main program quicker, so I can actually do more rather than less.

I can load up the hardware schematic for you if you are interested, i can not change it tho.

 

How normal people do it: http://www.8051projects.net/lcd-interfacing/lcd-programming.php

More or less, that is the way i am trying to do, but instead of ports, i have addresses that i assign. And when you read my original post, that is where my problem comes from. I can not write a character, even tho i am sure i am pulling the right addresses because i managed to initialize it, and it would not work if RS or R/W were at the wrong state.
Also to test the display i just want to try and write a character onto it simply, with a binary value, and not write some extra functions. That all is easy once i figure out what the damn thing needs.

The attached datasheet from Optrex shows how to hook a 44780 type LCD controller to a variety of MPUs. Unfortunately the 8051 is shown as IO driven but hopefully some help. The 8085A and 8051 buses are similar in operation.
Enjoy.

Thank you, i will read it.

 

There are some subtle timing requirements on the individual pins. These are usually a "gimmy" when doing port access control as changes are spaced in time by seperate instructions. Such may not be true when using a bus with very tight timings. My first concern is how you apply RS before the E line. While RS is low during the init sequency it needs to change to set the data address (or where the letters go).

So yeah, got a schematic of your interface?

http://i.imgur.com/FWcJRvP.png

From my understanding the E pin will toggle every time when one of the addresses that can be seen in the picture is used.

 

just to update a bit, i played around with the 8000H Write instruction address and i can do everything what i should be able to do with it, but as soon as i try to use the 8001H address to pull RS high everything just goes to hell, so the problem is definitely me not using the ADDRESSBUS or that address right, and from all my reading, i am stuck, i have no idea what i should change.

 

just to update a bit, i played around with the 8000H Write instruction address and i can do everything what i should be able to do with it, but as soon as i try to use the 8001H address to pull RS high everything just goes to hell, so the problem is definitely me not using the ADDRESSBUS or that address right, and from all my reading, i am stuck, i have no idea what i should change.

Update 2
I figured everything out, damn buses actually make it so convenient i could not even think that simple.
The way i wanted to do it was the old pic way, you know, initzialize and write through the same ports, but this is already done automatically in here. I initialize through the 8000h address and write onto it simply through 8001, by only sending the bits i want. It is that simple. I feel really really dumb now...
Thanks to you guys for making me think tho.

 

Funny, I was making the same mistake thinking how it worked. Of course it's running in the default 8 bit mode when connected to an 8 bit bus.

Congratulations. You solved this in under 24 hours. I've seen people go for weeks with no joy.

 

Connecting RS to A0 is the sensible way to do this.

 

Funny, I was making the same mistake thinking how it worked. Of course it's running in the default 8 bit mode when connected to an 8 bit bus.

Congratulations. You solved this in under 24 hours. I've seen people go for weeks with no joy.

Thanks, after understanding this everything became so clear.
Thus far, loving this forum. Score is looking good, 1 problem 1 solution.

Connecting RS to A0 is the sensible way to do this.

Yea, but i tried controlling RS manually, which is not the way.

 

Seems like you solved it... but yeah, on your schematic it actually says to write instructions to 8000h and data to 8001h ... so you really were over-complicating things!

Bit banging i2c? We had it as assignment in my uC class.

Yeah, I started out that way... then I got a PIC with hardware MSSP so it can do all the main I2C work for me... in which case I just wrote a small LCD class in XC8 that contains most of the main commands I'll use for quick access {eg LCD_Init, LCD_Clear, LCD_Goto(x,y), LCD_WriteData(string), LCD_WriteCommand(bytes) } and then off I go...