RRITESH KAKKAR!! Can we PLEASE get back to the original HI-Tech C example and do some minor modifications to that. Instead working with the current code. That code is useless, and even if you get it working now. It will only give you (and us) grief later on. And yes I see what is wrong with your current code. We are genuine trying to help you out here. But you do not hardly listen to any of our advice. THAT IS IN FACT INCREDIBLE RUDE

 

My code is taken from a fully working circuit. No comment if OP has tried it or not.

EN=1;
__delay_ms(M);
DATA='A';    //The problem is here i want to write A so, i do this 'A' for ascii value of it
__delay_ms(M);
EN=0;
__delay_ms(M);

can never work.

FLOWCHART.

1. set the DATA.
2. set E to 1.
3. set E to 0.

IN GENERAL.

Use a very low frequency, until it is worked out.
Then add delays.

 

Stop the code at the instruction next to the instruction - DATA=0B10100001, and check D7 to D0 on the LCD terminals. It should be the data that you had output. This should clear your problem.
For the kind of large delays that you are using, you are unlikely to have timing issues.

Excellent suggestion. I believe you do not have an in circuit debugger, so instead put a "while(1);" statement after the "DATA =" line to halt the program there. Do test all the bits (8 tests, right?) to see they all work and go to the correct pins.

As the data you set and the characters you get makes no sense to me (see my post #18) this would be a very important test to do.

1. set the DATA.
2. set E to 1.
3. set E to 0.

Not a bad suggestion. It is also how my LCD code is written, though the spec of the LCD I use suggests RRITESH's code is correct. I would try that.

 

My code is taken from a fully working circuit. No comment if OP has tried it or not.

EN=1;
__delay_ms(M);
DATA='A';    //The problem is here i want to write A so, i do this 'A' for ascii value of it
__delay_ms(M);
EN=0;
__delay_ms(M);

can never work.

I see what you mean, but Not really.

I checked that one up with the timing details of HD44780, the 'standard' IC or its compatibles on all these LCD modules are normally built, before actually suggesting checking the connections.

The data setup time and hold time are referenced to the negative edge of E, with a 195ns and 10ns respectively. The data can change when E is high and it does not matter so long as the setup and hold times are met.

But I agree with your code, and I had written it that way too, that this eliminates any ambiguity.

 

The first problem is the LCD initialization. If the OP had done as I suggest. This had been flawless. The Hi-Tech C original example is attached. This example is for 4 bit data transfer using the lower 4 bits of a port. The OP must sort the _XTAL_FREQ and the defines for data and control. And also analog input functions has be turned off
From main.c the lcd_init() function we have

init_value = 0x3;
TRISA=0;//must be checked to fit the setting
TRISD=0;//must be checked to fit the setting
LCD_RS = 0;
LCD_EN = 0;
LCD_RW = 0;
 
__delay_ms(15); // wait 15mSec after power applied,
LCD_DATA = init_value;
LCD_STROBE();
__delay_ms(5);
LCD_STROBE();
__delay_us(200);
LCD_STROBE();
__delay_us(200);
LCD_DATA = 2; // Four bit mode
LCD_STROBE();

During the first initialization only the upper nibble of the data input are read hence some changes are needed.

init_value = 0x30;// changed from init_value = 0x3;
TRISA=0;//must be checked to fit the setting
TRISD=0;//must be checked to fit the setting
LCD_RS = 0;
LCD_EN = 0;
LCD_RW = 0;
 
__delay_ms(15); // wait 15mSec after power applied,
LCD_DATA = init_value;
LCD_STROBE();
__delay_ms(5);
LCD_STROBE();
__delay_us(200);
LCD_STROBE();
__delay_us(200);
LCD_DATA = 0x30; // 8 bit mode
LCD_STROBE();

This is the original lcd_write function

lcd_write(unsigned char c)
{
__delay_us(40);
LCD_DATA = ( ( c >> 4 ) & 0x0F );
LCD_STROBE();
LCD_DATA = ( c & 0x0F );
LCD_STROBE();
}

This can be modified to

lcd_write(unsigned char c)
{
__delay_us(40);
LCD_DATA = c ;
LCD_STROBE();
}

 

I see what you mean, but Not really.

I checked that one up with the timing details of HD44780, the 'standard' IC or its compatibles on all these LCD modules are normally built, before actually suggesting checking the connections.

The data setup time and hold time are referenced to the negative edge of E, with a 195ns and 10ns respectively. The data can change when E is high and it does not matter so long as the setup and hold times are met.

But I agree with your code, and I had written it that way too, that this eliminates any ambiguity.

I was thinking, the data is latched when E goes high. Why change the data after E was made high? In the best case, nothing happens. But it is not the proper sequence.

 

I was thinking, the data is latched when E goes high. Why change the data after E was made high? In the best case, nothing happens. But it is not the proper sequence.

In one of my LCD datasheet. The min Enable pulse width "High" level PWEH is 220ns. Even using the compiler in lite mode. The compiler produce this. And with a 20MHz crystal we will only have 200ns strobe puls

113:                LCD_STROBE();
   7D8    1283     BCF 0x3, 0x5
   7D9    1303     BCF 0x3, 0x6
   7DA    1587     BSF 0x7, 0x3
   7DB    1187     BCF 0x7, 0x3

By using this define
#define LCD_STROBE() ((LCD_EN = 1),(NOP()),(LCD_EN=0))
We will have this result in lite mode. And that will for sure give a proper strobe puls

114:                LCD_STROBE();
   7CF    1283     BCF 0x3, 0x5
   7D0    1303     BCF 0x3, 0x6
   7D1    1587     BSF 0x7, 0x3
   7D2    0000     NOP
   7D3    1283     BCF 0x3, 0x5
   7D4    1303     BCF 0x3, 0x6
   7D5    1187     BCF 0x7, 0x3

 

Or set to 1 two times.

 

The first problem is the LCD initialization. If the OP had done as I suggest. This had been flawless. The Hi-Tech C original example is attached. This example is for 4 bit data transfer using the lower 4 bits of a port.

I beg your pardon, but if you've read the previous posts you would have noted that Rritesh is using the device in 8 bit mode, which needs no initialization to work in 8 bit mode.

Writing DATA=0B00001100; multiple times is probably not necessary as the first time will set the display on, the cursor off, and blink of cursor position character also off.

As I have never used the display in 8 bit mode I have no experience and just have to go by the data sheet, which contains no init sequence for 8 bit mode.

 

This is only partially correct. These displays may need initialization in some cases, and it is recommended.

Also only power them up when pins have defined level, and main power is stabilized. For insance through digital I/O.

Using them directly, these displays are anything but foolproof. It takes a number of precautions so they always start up relieably.

 

I beg your pardon, but if you've read the previous posts you would have noted that Rritesh is using the device in 8 bit mode, which needs no initialization to work in 8 bit mode.

Writing DATA=0B00001100; multiple times is probably not necessary as the first time will set the display on, the cursor off, and blink of cursor position character also off.

As I have never used the display in 8 bit mode I have no experience and just have to go by the data sheet, which contains no init sequence for 8 bit mode.

I beg you pardon. Well that is nice of you. But let us not make this into a peeing contest. Take a look at the PDF file. Yes the LCD may do an "automatic initialization" IF a special power supply conditions are satisfied. Shown in the figure on the first page of the PDF file. Can you with 100% be sure that this is met by the wall wart or whatever the power the OP use.
Then we must look result of this automatic initialization. The controller will configured for a 1-line display when in fact the majority of LCD modules should be configured for a 2-line display like the one the OP use. It also leaves the display off. That means two of the four steps that were automatically performed are going to have to be redone. Given all this would you not say that Initialization by Instruction. Is the best thing for the OP. Not to mention the rest of us trying to help the OP