LCD help needed

Hint for initialization - first parameter for DspPutc is the RS signal level:

         DspPutc(0, 0x38); /* FUNCTION_SET - 8-bit interface; 2-line display; 5x7 dots */
         DspPutc(0, 0x0C); /* DISPLAY_MODE - Display ON; Cursor OFF; Blinking OFF */
         DspPutc(0, 0x01); /* DSP_CLR_MODE - Clear display */
         LCD_Wait(1640);   /* wait 1.6 msecs */
         DspPutc(0, 0x06); /* ENTRY_MODE   - Cursor Increments; Display not shifted */

This came fram the display data sheet flow chart and operational table. Check the waveform timing for approxiate delays.

Why 'C'. Its portable. To port this code, only DspPutc needs to be modified for the I/O pins.

The above code is only small portion from an Ioctl function that I wrote.

Why 'C'. Its portable

in this case it is not
1) how does C 'port' to some processor with no p1, no quasi-bidirectionals.
2) you can not make a 'portable' delay routine in C
3) C is quite 'portable' in many respoects, but there is no way in hades you can make any I/O function 'portable' between processors whatever language you use.

Erik

There's always code that needs to be changed between processors. The I/O layer. In the Display case, the I/O is in the DspPutc function. In this function, the code can be changed to access the LCD using an 8 or 4 bit bus or by serial means if the LCD supports that mode.

you said: Why 'C'. Its portable.
now you say ... needs to be changed ... be changed to ... or by .. if ... supports

some portability.

this is NOT an argument aginst using C (I do it extensively) but the "portability" is very limited in small embedded. In small embedded the ease of coding is the important factor, the likelyhood that a project ever will be moved to another processor family is virtually zero. So, if it works in assembler, let sleeping dogs lie.

Erik

erik malund said: "this is NOT an argument aginst using C (I do it extensively) but the "portability" is very limited in small embedded."

I agree with erik. In C, often the compiler choices, memory layout and linker scripts are so different from a processor to the next, that major redesign is inevitable.

For example, writing precise timing loops in C is often a waste of time, because you simply can't control the machine code generated from the C source. A simple change in compiler optimization level can wreck you timings.

Especially when you need to push the performance, you tend to write a C style that matches the particular processor you target. There are always specific ways to write loops, logic sequences, expressions, function prototypes that match more closely a given processor.

An embedded programmer that is conscious of these styles will write faster and smaller C code, often deviant from ANSI. When you are struggling to fit a 80KB code in a 64KB processor flash, that's a go/no_go issue.

"So, if it works in assembler, let sleeping dogs lie"

Absolutely. I have seen C code that is virtually unrecognizable. As a matter of fact, the assembly portions of the large systems we work with are generally much better documented and maintainable, because they were usually written by a careful coder.

Almost all large systems we produce have the lower lib layer written in hand-optimized assembly for the target processor core.

"writing precise timing loops in C is often a waste of time"

Rather than "often", I'd say "always" - certainly for precise timing:

"because you simply can't control the machine code generated from the C source."

Absolutely - because you can never control it, it is always a waste of time!

"A simple change in compiler optimization level can wreck you timings"

Even without changing optimisation; eg, if the compiler happens to be using a register in your delay, then you add some "unrelated" code and the compiler happens to use the register for this and therefore something else in your loop...

An embedded programmer that is conscious of these styles

if he is not, he has no right to call himself an embedded programmer

Erik

Andy Neil wrote: "NEVER write precise timing loops in a HLL"

erik malund wrote: "... he has no right to call himself an embedded programmer"

To whom I fully agree. Maybe I should have made stronger remarks on my comments.

It is so tiresome the pointless ancient discussion of C versus ASM.

Real development in C always require you to implement base functions and critical portions using non-portable and/or low-level.

Even when using C++, I use to implement many methods of the base classes in assembly.

Hello EveryBody and specially to sir Erik who have given me courage to complete my task, well sir Erik i have finally shown the String on my LCD (HD44780 16x4) and sir i am really thank full for your critisice type talkings (because it was really very helpfull for me) and for all of the members who have contributed in my post.

Well sir i was facing only hardware problem and it was that i was using P1.0 AND P1.1 (IN AT89C2051) with 10k pull up resistor so i was not gainig the much voltages so i have simple changed them with 1k and the matter was solved just like it was nothing...

Warning: That changing of resistor worked for me but i have heard that we can only use pull-ups between 1k-10k but if we decrease the resistance then its most likely that our pins or even our MCu will be hurt BADLY. so do pricise changing.

Well at the End i would like to show you my Code which actually worked. (atleast for me)

This is the Code which worked for me, and also there is the pin configuration of My MCu (AT89C2051) with the LCD, Hoping that it will help the Noob Programmers (just like me) ;-)

VSS ----> GROUND (PIN-NO 1 ON LCD)
VCC ----> +5V (PIN-NO 2 ON LCD)
CONTRAST-> 10KPOT (PIN-NO 3 ON LCD) [ONE SIDE GROUND ONE SIDE +5V]
P3.4 ----> RS (PIN-NO 4 ON LCD)
P3.5 ----> RW (PIN-NO 5 ON LCD)
P3.7 ----> EN (PIN-NO 6 ON LCD)
P1.0 ----> DB0 (PIN-NO 7 ON LCD)
P1.1 ----> DB1 (PIN-NO 8 ON LCD)
P1.2 ----> DB2 (PIN-NO 9 ON LCD)
P1.3 ----> DB3 (PIN-NO 10 ON LCD)
P1.4 ----> DB4 (PIN-NO 11 ON LCD)
P1.5 ----> DB5 (PIN-NO 12 ON LCD)
P1.6 ----> DB6 (PIN-NO 13 ON LCD)
P1.7 ----> DB7 (PIN-NO 14 ON LCD)

CODE FOR 8-BIT HD44780 LCD FOR WRITING "DARE DEVIL" ON LCD

                ORG 0000H
                LJMP MAIN
                ORG 0030H
                RS EQU P3.5
                RW EQU P3.4
                EN EQU P3.7
                                        ;initialization
MAIN:           MOV A,#038H             ;8 bit mode ON, 2 lines, 5*8 font
                LCALL COM               ;first time
                MOV A,#038H             ;second time
                LCALL COM
                MOV A,#038H             ;third time
                LCALL COM
                MOV A,#038H             ;fourth time
                LCALL COM
                MOV A,#00CH             ;display ON, cursor OFF, blink OFF
                LCALL COM
                MOV A,#001H             ;clear screen
                LCALL COM
                MOV A,#006H             ;increase cursor position, scroll display OFF
                LCALL COM
                MOV A,#080H             ;Set DDRAM address to 0 (means to starting)
                LCALL COM               ;initialization End
                MOV A,#'D'              ;data to write on LCD
                LCALL DATAW
                MOV A,#'A'
                LCALL DATAW
                MOV A,#'R'
                LCALL DATAW
                MOV A,#'E'
                LCALL DATAW
                MOV A,#' '
                LCALL DATAW
                MOV A,#'D'
                LCALL DATAW
                MOV A,#'E'
                LCALL DATAW
                MOV A,#'V'
                LCALL DATAW
                MOV A,#'I'
                LCALL DATAW
                MOV A,#'L'
                LCALL DATAW             ;data end
AGAIN:          SJMP AGAIN              ;endless loop
COM:            MOV P1,A                ;command write sequence
                CLR RS
                CLR RW
                SETB EN
                ;LCALL TEST
                CLR EN
                LCALL DELAY
                RET
DATAW:          MOV P1,A                ;data write sequence
                SETB RS
                CLR RW
                SETB EN
                ;LCALL TEST
                CLR EN
                LCALL DELAY
                RET
DELAY:          MOV R6,#50              ;simple delay routine
HERE2:          MOV R7,#255             ;for 0.0124S or 124MS
HERE:           DJNZ R7,HERE
                DJNZ R6,HERE2
                RET
TEST:           JB P3.0,TEST
TEST2:          JNB P3.0,TEST2
                RET
                END

Congratulations. Now that you have it working in HW, you can try your original code, using DPTR and MOVC to write asciiz strings.

Thanks sir Jhonny i have tested my MOVC and DPTR code its working like dream .... :-)

Warning: That changing of resistor worked for me but i have heard that we can only use pull-ups between 1k-10k but if we decrease the resistance then its most likely that our pins or even our MCu will be hurt BADLY. so do pricise changing.

that is pure BALONEY. you can not discuss "pull-ups" without specifying the derivative.

This is simple math, you CAN (I am definiteley not saying you should) "decrease the resistance" till the chip draws Iol(max). Why use a lower resistance? simple: high capacity requires lower resistance. The much better solution is to reduce the capacitance and stay with a highre value resistor.

t changing of resistor worked for me makes me suspect that you have the LED on long wires. Do you?

Erik