Hi all.. Im quite new to 8051. Im doing a project that requires me to display value of a peak voltage on a LCD.
Anyway, Im stuck in testing the LCD. I have connected the LCD(Powertip PC 0802-A), otherwise known as 214-3288, to my 8051 development kit. The kit that im using is C8051F206-TB. I connected databus 0-7 to port 3 and RS to P2.4, R/W to P2.5, and EN to P2.6
I also have gone online to source for programs to display "Hello World" on the LCD. I have found a few in C or asm, but i have learnt the basic of assembly language, so i don't really understand C language.
Below is a program i found in 8052.com
$include (c8051f200.inc) CSEG AT 0000H LJMP MAIN CSEG AT 0100H MAIN:LCALL CONFIG LCALL INIT_LCD LCALL CLEAR_LCD LCALL HELLO CONFIG:MOV PRT0MX, #000H ; PRT0MX: Initial Reset Value MOV PRT1MX, #000H ; PRT1MX: Initial Reset Value MOV PRT2MX, #000H ; PRT2MX: Initial Reset Value MOV P2MODE, #0FFH ; Input Configuration for P2 MOV PRT3CF, #0FFH ; Output configuration for P3 INIT_LCD: CLR P2.4 MOV P3,#38H SETB P2.6 CLR P2.6 LCALL WAIT_LCD CLR P2.4 MOV P3,#0EH SETB P2.6 CLR P2.6 LCALL WAIT_LCD CLR P2.4 MOV P3,#06H SETB P2.6 CLR P2.6 LCALL WAIT_LCD RET HELLO: LCALL INIT_LCD LCALL CLEAR_LCD MOV A,#48H LCALL WRITE_TEXT MOV A,#45H LCALL WRITE_TEXT MOV A,#4CH LCALL WRITE_TEXT MOV A,#4CH LCALL WRITE_TEXT MOV A,#4FH LCALL WRITE_TEXT CLR P2.4 MOV P3,#0CAH SETB P2.6 CLR P2.6 LCALL WRITE_TEXT MOV A,#57H LCALL WRITE_TEXT MOV A,#4FH LCALL WRITE_TEXT MOV A,#52H LCALL WRITE_TEXT MOV A,#4CH LCALL WRITE_TEXT MOV A,#44H LCALL WRITE_TEXT WAIT_LCD: CLR P2.6 ;Start LCD command CLR P2.4 ;It's a command SETB P2.5 ;It's a read command MOV P3,#0FFH ;Set all pins to FF initially SETB P2.6 ;Clock out command to LCD MOV A,P3 ;Read the return value JB ACC.7,WAIT_LCD CLR P2.6 ;Finish the command CLR P2.5 ;Turn off RW for future commands RET CLEAR_LCD:CLR P2.4 MOV P3,#01H SETB P2.6 CLR P2.6 LCALL WAIT_LCD RET WRITE_TEXT:SETB P2.4 MOV P3,A SETB P2.6 CLR P2.6 LCALL WAIT_LCD RET END
Erm.. i forgot to say what help i needed... lol...
Can anyone help me to check where the program is wrong or whether i have connected the pins wrong.
By the way, the input voltage of the LCD is connected to a 5V supply and the contrast pin is connected to a 10k variable resistor. I have tried using stepping to find out the problem. I found out that the program keep looping here after the 1st LCALL WAIT_LCD
WAIT_LCD: CLR P2.6 ;Start LCD command CLR P2.4 ;It's a command SETB P2.5 ;It's a read command MOV P3,#0FFH ;Set all pins to FF initially SETB P2.6 ;Clock out command to LCD MOV A,P3 ;Read the return value JB ACC.7,WAIT_LCD
Does EN's timing satisfy the specified timing requirements?
You meant i have to calculate the clock cycles for each routine and make sure that they have enuff delay?
Not quite. You will have to determine the timing of those signals. Calculating is only one of many ways of determining it, and hardly ever the best one to choose.
The best method would be to use an oscilloscope or logic analyzer on the actual hardware. If you really can't get your hands on a 'scope, the next best thing is the logic analyzer built into the uVision simulator debugger. Using that, you can generate almost exactly the same kind of diagram as you'll find in the datasheet(s) of devices you're trying to control. That can make things a whole lot easier to check.
"in my datasheet, there is 2 diagrams, one for write operation and one for read operation. But i do not understand these diagrams"
The Write diagram is showing:
1. The first thing that must happen is that R/W must either already be low, or be taken low, and RS must have reached its steady state for the operation
2. A time tAS must then elapse before E reaches its high-level threshold, VIH1
3. The time that it takes E to rise from its low-level threshold, VIL1, to VIH1 is called its rise-time and is specified by tEr
4. E must remain high for a time tDSW after the Data lines DB0~DB7 stabilise to valid levels
5. The Data line must remain valid for a time tH after E falls below VIL1
etc
Looking closer at your code, it appears that the display uses the ubiquitous Hitachi HD44780 controller or similar. It also appears that the code is designed to pace display writes by checking the controller's busy flag and it does so after writing the very first display instruction. Relying on proper busy flag operation right from the start like that require using the display with internal reset. When using the internal reset, the electrical characteristics in the controller data sheet's "Power Supply Conditions Using Internal Reset Circuit" table must be satisfied; otherwise, an "initialization by instruction" sequence must be used. It isn't until after the third step in the "initialization by instruction" sequence that the busy flag can be used reliably.
So, there is another aspect of timing for you to check before using that code you found on the Internet, and that is the power supply rise time. Does your circuit satisfy the rise time requirements to use the display without employing the "initialization by instruction" sequence?
So i have to check the signals by using either an oscilloscope or a logic analyzer in order to make make sure that it is about the same diagram as the write diagram? So where do i get the signals from? From the LCD or the development kit?
Also, how can i check whether my circuit satisfy the rise time to use the display?
Yes, that is the ideal way to do it. You certainly couldn't check EN rise/fall times without a scope, or the power supply rise time for that matter. I think a lesser that ideal way to do it was commented on above; calculating the time to execute the instructions that control various signals. A simple calculation would tell you if you are close to not satisfying timing. I mean if EN must be high for at least 450ns and you're running a 40MHz 1-clocker, back-to-back SET/CLR instructions are going to be way shorter than 450ns.
As for the power supply rise time being fast enough to qualify for relying on the internal reset circuit, one could simply avoid the issue entirely and execute the "initialization by instruction" even if it wasn't necessary. It's merely a slower, safer way to initialize the display.
Oh.. I see. But where do i get signals from? Isit for EN, I have to probe the signal only from the EN pin on the LCD and the same for RS and RW?
Well signals have two ends, right? And sometimes intermediate access points in between. It is usually best to measure the signals at the device whose timing requirements you are trying to satisfy, so in your case, probably near the display connector.
So i have to probe one end to the pin that i want to see the signal and the other end to gnd?
Right.
I see. Thanks alot for your help guys!!! If i run into some other problems, i'll post again =P For now, Im going to enjoy my weekend!!!
Regards natur3
Erm.. Guys.. I probed the pin as you told me, but i get no waveform. Do i have to power up the 8051 board when measuring the LCD's EN rise/fall time. Also how do i write the "initialization by instruction"? I have seen the diagram but i do not understand. This is where i downloaded the initialization file.
docs-asia.electrocomponents.com/.../0900766b800b9873.pdf
I forgot to give the link for the instruction set. It is as follow:
docs-asia.electrocomponents.com/.../0900766b800b9869.pdf
The waveform will only come when i send a signal to the LCD?
And for the "initialization by instruction", do i have to put a delay routine for those "waiting 15ms,4.1ms,etc"?
Theres also 3 instructions of function set. Do i have to run the instruction 3 times?
Lastly, after the 3rd sequence, is there no delay between "display off", "display clear" and "entry mode set"?
"...i get no waveform. Do i have to power up the 8051 board when measuring the LCD's EN rise/fall time?"
Errr... rather definitely yes!!
EN is an input to the LCD, so it must be generated by the 8051 - obviously, the 8051 will not be generating anything at all if it isn't powered-up!!
You need to go back to basics to understand how the LCD actually works - see: www.8052.com/tutlcd.phtml and: www.8052.com/tutlcd2.phtml
One important note. You should not power up the LCD without powering up the 8051. And in reverse, you should not power up the 8051 without powering up the LCD.
Most integrated circuits does not support voltages received on any signal pins, without already having the supply voltage turned on.
If you look at data sheets, there is normally a note how many volt a signal pin may be forced above VCC (or below GND). This value is normally somewhere between 0.2V and 0.7V.
If the signal pin is held outside this value, you may get latchup problems (the pin locks at the forced value for minutes or hours) or you may permanently kill the signal or the whole chip! Note that the chip can also gradually deteriorate, i.e. it can seem that it survives the abuse for a couple of times, before the signal or chip permanently fails!
Always make sure that all VCC pins of all chips in a circuit always gets their power at the same time. If a circuit is using more than one voltage, there is often need for diodes between the different supplies, to make sure that the fastest rising supply voltage helps a slower supply to rise.
When interfacing electronics with external signals (where you don't have control over when signals are applied with relation to availability of supply voltages) you normally need special buffer chips - or high-impedive serial resistors with optional protection diodes from the signal to VCC and GND.
If you are working with a prototype and are not 100% sure if your program is correct - or if your prototype is correctly wired - it is extra important to make sure that you doesn't also have to worry about some signal pins being broken on a chip...
You mean i have to power up my board and LCD at the same time?
"If a circuit is using more than one voltage, there is often need for diodes between the different supplies"
Does the above sentence mean that i have to add a diode to the circuit? Because the board and the LCD uses different supply. If needed, how do i connect?
I have read and understand most part of the tutorial.
What happens when the EN's timing does not satisfy the spcified timing requirements? What do i have to do?
Also, what does NOP mean? The tutorial said if my crystal is too fast, i have to create an number of NOP delay so that it meet the datasheet timing.
I have also probe when sending a signal to the LCD. I saw a sawtooth waveform. It does not show the waveform on the datasheet.
"What happens when the EN's timing does not satisfy the spcified timing requirements?"
The behaviour is undefined.
"What do i have to do?"
You have to comply with the specifications specified in the Datasheet
"Also, what does NOP mean?"
NOP is the 8051 "No-Operation" instruction.
The full set of 8051 instructions is described in Chapter 2 of the so-called "bible" for the 8051:
Chapter 1 - 80C51 Family Architecture: www.nxp.com/.../80C51_FAM_ARCH_1.pdf
Chapter 2 - 80C51 Family Programmer's Guide and Instruction Set: www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf
Chapter 3 - 80C51 Family Hardware Description: www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf
Sounds like you also need to read the basic Tutorial on the 8051:
www.8052.com/tut8051.phtml
And maybe get yourself a good book: http://www.keil.com/books/8051books.asp www.8052.com/books.phtml
ok... In order to use NOP, i will have to check my crystal and calculate the number of NOPs to be inserted into the program? I have a problem here. My board only have internal oscillator which have a freq of 2-16Mhz.
Although i managed to make the cursor blink sometimes, but whenever i run the program, the LCD seems to go into chaos mode. I can see lines moving very fast.
Also, when i stop the program, theres an error which says:
"Target did not halt! Some circumstances cause a slow hardware response. Do you want to retry?"
and when i click "ok", it goes back to before i download the program into the LCD.
but when i click "Cancel", another pop-up says: "Target failed to respond. System is being disconnected"
What does this error means?
I have a problem here. My board only have internal oscillator which have a freq of 2-16Mhz.
Why is this a problem?
It doesn't matter what kind of oscillator you are using, it's how fast you run the processor that matters. The only thing to note is that if you run a processor with a RC oscillator, the frequency error of the oscillator may be very high, so the safety margins must be correspondingly higher.
The other thing to note about RC oscillators is that their frequency is usually not accurate.
It may well be stable (ie, it doesn't change), but not accurate (ie, you don't know exactly what fequency it is).
Clearly, to use it as the basis for timing, you need to know precisely what the frequency is!
The chip manufacturer may well have some instructions on how to calibrate the frequency...
I see. But what about the symptoms above and the error?
Ok... How do i configure the device? I have an example program from my friend. But he configured the timers, watchdog timer, UART,oscillator, interuppts and ports... I haved checked the datasheet, but i do not understand why he need to configure so many things instead of just the ports.
Andy: The other thing to note about RC oscillators is that their frequency is usually not accurate.
It was because your normally don't know what the actual frequency is, that I noted that the timing safety margins must be set higher when using an RC oscillator.
The really bad part with RC oscillators is that it isn't so easy to just measure their frequency, since they tend to vary very much with temperature.
This shouldn't normally represent a problem when it comes to making sure that handshake signals aren't run too fast. A 100% safety margin is quite often ok, without getting too low "bandwidth" to connected equipment.
The need to know the real frequency - or to use the ability to trim the oscillator - is more important if trying to use it for baudrate generation or similar.
I see. I managed to print "HELLO" on the 1st line of the LCD. It only works when i use stepping. It does not work when i just let it run by itself, does this means that the processor is too fast? But i cannot get the cursor to move to the 2nd line.
I use this instruction to move the cursor, but it won't move:
CLR RS MOV DATA,#0C0H SETB EN NOP NOP NOP NOP CLR EN NOP NOP NOP NOP
Ok. My bad. I mean the cursor does move to the 2nd line, after i send "CLR EN" when sending "W", the LCD does not show anything, not even the cursor.
I mean after this instruction
the cursor moves to the 2nd(sometimes cannot) line, but after the following instruction which comes after the above instruction, nothing shows.
MOV A,#'W' LCALL WRITE_TEXT WRITE_TEXT:SETB RS MOV DAT,A SETB EN NOP NOP NOP NOP CLR EN NOP NOP NOP NOP RET
Why is this so?
What do i have to do in order to make it print at the 2nd line? Is it printing too fast at the 2nd line? Or do i have to configure something?
In addition to satisfying low-level signal timing requirements, you have the LCD controller's execution timing requirements to deal with. Characters take some time to display. Instructions (e.g., CLEAR, HOME, etc.) take even more time to execute.
So I have to put in more delay in the "Move the cursor to the 2nd line" instruction? Because when i run the program, i can see "Hello" being printed out on the 1st line and the cursor moved to the 2nd line but no words are printed on the 2nd line.
However when i try this:
Hello: CLR EN CLR RS MOV DAT,#0FH SETB EN LCALL DELAY CLR EN CLR RS MOV DAT,#0C2H SETB EN LCALL DELAY CLR EN MOV A,#'H' LCALL WRITE_TEXT
It works, it can print on the 2nd line, 3rd position but not on the 1st and 2nd. Also, when i just let the program keep running, eventually the "Hello" will be printed out on the 2nd line.
View all questions in Keil forum