16x2 LCD display - issue ? 1

[DTSFA]

I am using a 16f877 PIC to drive a 16x2 LCD,

if I run the code to where the lift checks if between floors , all is good, if I run code to end , at the start, I get what looks like a 'y' in the display,
and rest of code seems to output weird characters, behave illogically

sbit LCD_RS at RB4_bit;
sbit LCD_EN at RB5_bit;
sbit LCD_D7 at RB3_bit;
sbit LCD_D6 at RB2_bit;
sbit LCD_D5 at RB1_bit;
sbit LCD_D4 at RB0_bit;

sbit LCD_RS_Direction at TRISB4_bit;
sbit LCD_EN_Direction at TRISB5_bit;
sbit LCD_D7_Direction at TRISB3_bit;
sbit LCD_D6_Direction at TRISB2_bit;
sbit LCD_D5_Direction at TRISB1_bit;
sbit LCD_D4_Direction at TRISB0_bit;
int i=0;

void main() {

ADCON1 = 0x0F;
TRISB = 0;
PORTB = 0xFF;
TRISC = 1;
PORTC = 0x00;
Lcd_Init();

while(1){

for (i=0;i<3;i++){
if (PORTC.F0==0){
Lcd_Out(1,1,"Door fault");
Lcd_Out(2,1,"Check interlocks");
}
else {
Lcd_Out(1,1,"Door closed");
}
Delay_ms(1000);
Lcd_Cmd(_LCD_CLEAR);
}

for (i=0;i<3;i++){
if (PORTC.F1==0){
Lcd_Out(1,1,"No up safety");
Lcd_Out(2,1,"Platf./Carriage?");
}
else {
Lcd_Out(1,1,"Safety Edge Ok");
}
Delay_ms(1000);
Lcd_Cmd(_LCD_CLEAR);
}

for (i=0;i<3;i++){
if (PORTC.F2==1){
Lcd_Out(1,1,"Lift at upper");
Lcd_Out(2,1,"Level");
}
else {
Lcd_Out(1,1,"Checking..");
}
Delay_ms(1000);
Lcd_Cmd(_LCD_CLEAR);
}


for (i=0;i<3;i++){
if (PORTC.F3==1){
Lcd_Out(1,1,"Lift at lower");
Lcd_Out(2,1,"Level");
}
else {
Lcd_Out(1,1,"Between floors");
}
Delay_ms(1000);
Lcd_Cmd(_LCD_CLEAR);
}


for (i=0;i<3;i++){
if (PORTC.F4==1){
Lcd_Out(1,1,"Lift going up");
}
else {
Lcd_Out(1,1,"Checking..");
}
Delay_ms(1000);
Lcd_Cmd(_LCD_CLEAR);
}

for (i=0;i<3;i++){
if (PORTC.F5==1){
Lcd_Out(1,1,"Lift going dn");
}
else {
Lcd_Out(1,1,"Checking..");
}
Delay_ms(1000);
Lcd_Cmd(_LCD_CLEAR);
}
}
}

is this a timing issue ?

or something else, all advice welcome,

( I am rusty on c code at mo, so please go easy)

code is written, compiled using MikroC Pro

thanks

 

[MikeHalloran]

It's been two decades since I worked with two-line LCDs, so forgive any rust, or obsolete info.

ISTR that the initialization sequence was odd, and critical, and if you got it wrong, the display was looking for four-bit words while you were sending eight-bit words, and then the display's internal uP got really confused.

It appears that you are doing the init() exactly once, ever, so even if the init() works correctly, the display may not recover from a glitch.

It's not clear if your display commands are checking the status of the LCD before sending new data. I think there was a wire or a memory location to read to say that the display had finished displaying the last message and was ready to accept a new message. Or I could be hallucinating.

Your description of the system's behavior suggests that it's somehow running off the end of what should be a 'do forever' loop, and executing garbage, but I can't quite see how that's happening in what you've provided.


Note and disclaimer:
Every time I have tried to use C, I have eventually discovered yet another hoary old bug in the C preprocessor that 'everyone knows about', except me, because I didn't start with C; I started with FORTH. Eventually in this context means that I disassembled the binaries and stepped through the generated assembly source to see if that made sense, and when it didn't, sure enough, there was something I had done 'wrong', so the C preprocessor had done something bizarre.

Considering debug time, I am much faster writing in assembler, and much faster than that writing in FORTH. I am thus still inexpert in C, and doomed to hate it forever, as I have yet to discover a single redeeming quality that is not also present to a greater degree in FORTH.







Mike Halloran
Pembroke Pines, FL, USA

 

[xwb]

The character you are seeing is ÿ. If you use charmap, you will find that its character code is 0xFF. So basically you have a load of memory set to FF.

 

[varun123kan]

Make sure that in configuration HS Oscillation bit is set.

 

[MikeHalloran]

This would be a good time to re-read the LCD data sheet, and especially the errata, slowly, again, while reviewing the code. I'd go farther and review a disassembly of the generated binaries.

If you have the tools, step through the code starting a little before it goes off the rails. I'd go farther and, at least once, step through the code from cold boot to after where it gets wonky.





Mike Halloran
Pembroke Pines, FL, USA

 

[DTSFA]

thanks for reply guys, was in fact a memory issue with the PIC,

 

[RobHen]

Hi DTSFA,

Search the data sheet of the 16x2 LCD, most of those display outputs are described in there.
I see you already solved the problem, but that is my tip.