LCD issue

[VEGETA]

Hi,

I have a qapass 16x2a lcd. I've tried many time using many libraries to get it to write something, but I couldn't. I am using PIC16F877A with MPLAB X 3 (XC8 free)... I am good with PICs and done stuff with it, but this LCD thing is different!

I followed this tutorial here: https://electrosome.com/lcd-pic-mplab-xc8/   

but no use! it shows white blocks on the bottom line, and sometimes on both (as I try a lot). I am using a 20MHz crystal so I modified the code in that tutorial to suite it.

Can you help me with a tried code? some working lib?

thanks

[electr_peter]

Check LCD schematic got pin outs few times and recheck all connections - some LCD modules are slightly different.

[pkplex]

I was mincing around not an hour ago leaning about C on PIC's and the very same kind of LCD. Attached is a project file, which is using an ICD3, A PIC16F627a, but the LCD is using 4 bit mode ( only need to wire in d4 to d7 instead of all 8 data pins ). Pins are wired to PORTB.

The code is not cleaned up or optimized or anything, as I only just got it working an hour ago, but perhaps it is of some use. It prints out stuff in a loop.

[VEGETA]

pkplex,

I used your code and modified it to suit me, but it didn't work. i use portd, can you show me your circuit as i didn't find in the code where you have connected the lcd pins.

and, i didn't understand this #define lcd_busy port....

there is no pin in the lcd called lcd_busy but you connected it to the PIC. please explain.

I started to think that my own connections are bad! i've tried nearly all available lcd example online but the same issue is still there: it shows while boxes in the bottom line only!

[linux-works]

are you sure you have the contrast setup so that you can SEE letters in the blocks?

if the contrast pot is set wrong or not even installed, you'll only see 'blocks'.

[VEGETA]

are you sure you have the contrast setup so that you can SEE letters in the blocks?

if the contrast pot is set wrong or not even installed, you'll only see 'blocks'.

I have used many POTs and modified contrast, but still the same. what is the best resistance value?

[linux-works]

with no data sent to the screen, power it on and adjust the contrast so that the dark blocks JUST fade.  that's usually a good starting point.

I have lcd libs for arduino that work (everyone does, lol) but I have no pic experience so can't help there.

the busy line is often ignored and most apps just write 4bit hitachi codes and do software delays to let the screen finish writing.

be sure you are in 4 wire mode instead of 8 wire mode, for lcd.  i assume its a regular hitachi and it should support both.

[pkplex]

pkplex,

I used your code and modified it to suit me, but it didn't work. i use portd, can you show me your circuit as i didn't find in the code where you have connected the lcd pins.

and, i didn't understand this #define lcd_busy port....

there is no pin in the lcd called lcd_busy but you connected it to the PIC. please explain.

I started to think that my own connections are bad! i've tried nearly all available lcd example online but the same issue is still there: it shows while boxes in the bottom line only!

Gidday

#define LCD_BUSY         PORTBbits.RB3

So the pin D7 can be used to signal when the LCD is still busy or not. LCD_BUSY is just a convenient label to use, and it is used in the LCDWait() routine.

You might also want to check you have the pins wired to the right places. So D4 should be on the first pin of a port, D5 the second, D6 the third, and D7 the fourth. Then the other pins (enable, register select, read/write) can be in whatever order so long as your code knows which pin is what.

So PORTBbits.RBX is a macro or something which MPLAB X / XC3 provides, so you can easily refer to the bits of a port.

You said you use PORTD. I could be wrong here, but a quick look at the datasheet for your pic does not seem to show a portd??

Cheers

[VEGETA]

my PIC is PIC16F877A, it has a PORTD.

I've put D4 on PORTD bit 2 I guess, and the others are after. I will re-wire the whole thing tomorrow. However, can you tell me the resistance of your current value of POT? < I don't have a multimeter to measure mine right now, so it will be easier to put a resistance of the value.

Also, what happens when the bottom line shows the blocks and the first line shows nothing? did this happened to you?

[pkplex]

my PIC is PIC16F877A, it has a PORTD.

I've put D4 on PORTD bit 2 I guess, and the others are after. I will re-wire the whole thing tomorrow. However, can you tell me the resistance of your current value of POT? < I don't have a multimeter to measure mine right now, so it will be easier to put a resistance of the value.

Also, what happens when the bottom line shows the blocks and the first line shows nothing? did this happened to you?

That sounds wrong to me. You want the first 4 bits of the PORTD ( RD0, RD1, RD2, RD3 ) wired to the pins d4, d5, d6, and d7 on the lcd respectively. If you do not wire this stuff right, it wont work, so don't just guess. From there you can use RD4, RD5, RD6 for the other functions ( enable, rw, rs ), you just need to make sure you tell the code where those pins are mapped to.

As for the resistance of the pot, I am not sure, not in front of it to measure it. But just adjust it as described earlier in this thread.

[kolbep]

Also, what happens when the bottom line shows the blocks and the first line shows nothing? did this happened to you?

Normally if it does not initialize properly, then the Top row is squares and the bottom row is off.
Once the pic initializes it properly, then Both rows will be squares if your contrast is wrong.


I had it with blocks on the bottom row once, and blank on the top. and it refused to work. Took me an hour to figure out I had plugged the lcd into the demo board upside down. Like that It was powering up the display using the power pins for the backlight, of course all the other pins were wrong way.

[Howardlong]

I just breadboarded this up and it does work.

Before any code is run, at switch on, the LCD contrast should be adjusted so the top line of blocks only faintly appear. For my LCD it was at about 5-10% from the ground end.

I had one operator error, I wired up the RD ports wrongly. They are not consecutive, RD2 and RD3 are on pins 21 & 22, with RD4-7 on pins 27-30. As you can see, I got the logic analyser out for that one!

Edit: I did get the following warnings during the build, but it did still work. I didn't affect the running of the program.

Code: [Select]

Warning [359] D:\myprojects\Pic16\p16f877a lcd\main.c; 33.35 illegal conversion between pointer types
pointer to const unsigned char -> pointer to unsigned char
Warning [359] D:\myprojects\Pic16\p16f877a lcd\main.c; 35.29 illegal conversion between pointer types
pointer to const unsigned char -> pointer to unsigned char
Warning [359] D:\myprojects\Pic16\p16f877a lcd\main.c; 39.32 illegal conversion between pointer types
pointer to const unsigned char -> pointer to unsigned char
Warning [359] D:\myprojects\Pic16\p16f877a lcd\main.c; 41.31 illegal conversion between pointer types
pointer to const unsigned char -> pointer to unsigned char
Warning [359] D:\myprojects\Pic16\p16f877a lcd\main.c; 45.39 illegal conversion between pointer types
pointer to const unsigned char -> pointer to unsigned char

To get rid of the warning, add "const" to the Lcd_Write_String declaration in lcd.h:

Code: [Select]

void Lcd_Write_String(const char *a)


[VEGETA]

so you think i should power it up using VDD and VSS pins. then adjust the contrast using the VD pin... before hooking it up to anything? so it can show the TOP line blocks not the bottom ones?

then do what? using the same layout as described in that post?

can you post your schematic and code please?

thanks

[Howardlong]

The schematic and code is exactly as the original except for the addition of "const" as mentioned which made no difference to the functionality, I just don't like compiler warnings without knowing why. "Const" in this case and implementation just says that the function is expecting the text to be in ROM.

You can wire everything up, just don't program or run anything while you check the contrast.

What voltage are you running at, and can you confirm your LCD's voltage requirements?

[pkplex]

I ran into a random problem.

I chucked my breadboard into a drawer to make space for something else I wanted to do. Bring it back out a week later.. and no go.

I discovered when waiting for the busy flag to go low ( pin D7 on the LCD ) that a pull down resistor was required. I found this by probing the pin with a multimeter and seeing that the display started working, same as when probed with a scope. So then I tried a 1M resistor, which works too.

I have tried swapping out the LCD for another identical one, swapping out the pic, checking all the wiring, cap across vdd and vss on both lcd and pic, checked over code to see if it was for sure an input, it was.

While using a pull down resistor makes it work, I cannot seem to find any documentation anywhere which actually states I should need one, and it is bothering me that I don't know why its suddenly requiring one where a week ago it was fine without.

Any ideas on what's going on here?

[macboy]

I ran into a random problem.

I chucked my breadboard into a drawer to make space for something else I wanted to do. Bring it back out a week later.. and no go.

I discovered when waiting for the busy flag to go low ( pin D7 on the LCD ) that a pull down resistor was required. I found this by probing the pin with a multimeter and seeing that the display started working, same as when probed with a scope. So then I tried a 1M resistor, which works too.

I have tried swapping out the LCD for another identical one, swapping out the pic, checking all the wiring, cap across vdd and vss on both lcd and pic, checked over code to see if it was for sure an input, it was.

While using a pull down resistor makes it work, I cannot seem to find any documentation anywhere which actually states I should need one, and it is bothering me that I don't know why its suddenly requiring one where a week ago it was fine without.

Any ideas on what's going on here?

It is possible that the driver for that I/O pin on the controller IC has failed and can't drive the line low (but can drive it high). If that was the case, then a pull-down would make it work. I wouldn't think that both LCDs would have the same problem but then again, if you have used both of them with your code before, you may have "abused" both also. (Driven the line high while it was driving it low... that can damage one IC, probably not the PIC).

1 Meg is a little high and will incur some extra delay due to a slow transition. I'd go with 100 k or less. That is still a relatively weak pull but will give a better edge.

It is also possible that your I/O levels don't match: micro expecting TTL levels (< 0.8 V for low) and LCD driving to CMOS levels (< 2.5 V for low). Of course, most of the time, things drive a low signal to well below the threshold for both and have no issues inter-operating. And I would hardly think that a 1 Meg pull-down (5 uA) would make a difference.

Measure for a difference between the ground/Vss pin of the PIC and the ground pin of the LCD. Maybe you have a voltage drop (due to I*R) in your wiring that is shifting the logic levels and causing confusion.

What is your power supply voltage? 5 V? 3.3 V? Is that in spec for the LCD? Many require 5 V.

[pkplex]

Hmmm, So the second LCD was a fresh one, right out of the bubbly wrap thing.

The voltage between Vss pins of micro and lcd is around 20mV, and the actual supply voltage is 5v, provided to both the micro and the lcd.

I will need to try find some more datasheets about the LCD and see how it drives the output though.

More investigation required!

Cheers

[pkplex]

Fixed.

It turned out to be my busy flag waiting routine.. Im still not sure why it worked a week ago, perhaps it was by fluke, but for reference, this was the non-working code:

Code: [Select]

while (1) {
LCD_ENABLE = 1;
LCD_ENABLE = 0;
if (LCD_BUSY) {
LCD_ENABLE = 1;
LCD_ENABLE = 0;
continue;
}
LCD_ENABLE = 1;
LCD_ENABLE = 0;
break;
}

And this is the working code:

Code: [Select]

while (1) {
LCD_ENABLE = 1;
if (LCD_BUSY) {
LCD_ENABLE = 0;
LCD_ENABLE = 1;
LCD_ENABLE = 0;
continue;
}
LCD_ENABLE = 0;
LCD_ENABLE = 1;
LCD_ENABLE = 0;
break;
}

So the problem was I was strobing the enable pin high and low, and then reading the busy flag. But what is supposed to happen is that the busy flag is to be read while the enable pin is high.

Whoops

Cheers for the help and suggestions

[VEGETA]

@pkplex:

where did you get that library code? can you give me a working one? or is it by using the example library and project i posted?

also, I am using 4-bit mode, hence pins D4-D7. how to deal with this busy flag thing? can you find it in my example code?

thanks

[pkplex]

I wrote it.

Attached should be the project which is working as of a few moments ago ( just programmed a 16f627a and it works ).

The code assumes a 4Mhz internal clock on a PIC16F627a, and that the lcd has been wired for 4 bit mode, where pins d4-d7 of the LCD are wired to the first 4 bits of the pic's pins ( eg, RA0 - RA 3 )

Pay attention to the lcd.h file though, and adjust the #defines in there to suit your own pin wiring.

For example currently i have mine using the PORTA pins... From lcd.h:

Code: [Select]

#define LCD_PORT PORTA
#define LCD_TRIS TRISA
#define LCD_RS PORTAbits.RA4
#define LCD_ENABLE PORTAbits.RA6
#define LCD_BUSY PORTAbits.RA3
#define LCD_RW PORTAbits.RA7

Cheers

[pkplex]

I should mention that it is in a rather urgent loop of displaying things, which can be adjusted in main.c