Reading Data from LCD

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Everyone.

 

I've spent the better part of the day trying to add a read data function to my LCD unit.  Everything connection wise is fine with data displaying correctly but due to factors in the environment i sometimes get interference that causes the screen to go ape and display garbage and you need to reset to get the display back.  I was hoping i could use the controller to read the data back and if a problem is found it could re initialize the display.  I haven't found much on the topic since most tutorials just recommend connecting RW to ground and keep it in write mode.  The test function i tried was to read the character back and compare with what should be there and if different to display the read character straight after it.  My basic approach was to just duplicate my send character function with it reading but since its in 4 bit mode i'm assuming i would need to read the 4 high bits and then the 4 low bits.  The result i get from every read is 0? I anyone has successfully done this could you perhaps spot the error in the code.  Ive gone through it over and over but still im missing something.angryIve confirmed the RW pin is in fact pulled high by using an LED. 

 

int LCD_PROOFREAD(uint8_t ch){

uint8_t backread=0;

LCDsendCommand(0b00010000);   //move cursor to the left

LCDR|=(1<<LCD_E) | (1<<LCD_RW) | (1<<LCD_RS);   //Set the DDR as outputs for control bits

               

LDDR&=~(1<<LCD_D7);

LDDR&=~(1<<LCD_D6);

 LDDR&=~(1<<LCD_D5);

LDDR&=~(1<<LCD_D4);          //Set the DDR for the data bits to 0 to act as inputs

               

LCP|=(1<<LCD_RS);     //Pull the RS pin high for reading Data not command

LCP|=(1<<LCD_RW);  //Pull the RW pin high to read data instead of writing

 

 LCP|=(1<<LCD_E);   //Pull the enable pin high

delay_ms(1);    //Wait 1ms for data to settle

 

backread|=(LDP&0b11110000);  //Read the port with bit masking  bits 4,5,6 and 7 because they are the 4 high bits.

delay_ms(1);

LCP&=~(1<<LCD_E);   //Pull the enable bit low again      

delay_ms(1);

 

LCP|=(1<<LCD_RS);  //Pull the RS pin high because we are working with data

LCP|=(1<<LCD_RW); //Pull the RW pin high because we are reading not writing

               

LCP|=(1<<LCD_E);   //Pull the enable pin high                   

_delay_ms(1);  //Wait for the data to settle

backread|=((LDP&0b11110000)>>4);  //We read the Port with a bitmask just to read pin 4-7.  We bit shift  the bits 4 to the right to get the 4 low bits.

_delay_ms(1);

 

LCP&=~(1<<LCD_E);  //We now pull the enable pin low

               

                     if (ch!=backread) {  //Check if the character is the same

                    LCDsendChar(backread,0);  //If no match then display the character read next to the one it read

                   }

                                                               

return(0);

}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not refresh (re-write) the display at regular intervals ?


From backread|=(LDP&0b11110000); I am guessing that the LCD datalines are connected to bits 7,6,5 and 4 of the LDP port.
Is that correct ?

Last Edited: Tue. Mar 21, 2017 - 12:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The data sheet HERE might help. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It does refresh at regular intervals. The problem is that once interference discombobylates it, there is no recovering as far as i can see. For example calling clear screen has no effect from time of scrambling.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for wasting everyone's time. The LDP is defined as PORTB which i use to write to the screen. As per a previous problem with calling bit is clear on portB,1. Its not PORTB that i should read from. Its PINB that i should be reading from. The unit now works.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If your lcd is being upset by outside disturbances then i suggest you address that problem as software can't fix that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We had it happen regularly in the past and weve made a lot of changes that has reduced occurences significantly but there is still that once a week/once every secomd week problem. The idea behind the reading is to shut the screen down and then restart and reinitialize the display.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you need to reinitialise the display when it becomes corrupted, then why not brute-force re-initialise the display at regular intervals, (once per day, or even once per hour, depending on often people look at it).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ClintonB wrote:
The idea behind the reading is to shut the screen down and then restart and reinitialize the display.

You mean the idea is to identify when the display has become corrupted from the data that you read back?

 

Rather than just leave the display on - with the possibility of corruption - is it an option to just have the display active "on demand" ... ?

 

(although that is still just masking the symptom rather than curing the fault).

 

Last Edited: Tue. Mar 21, 2017 - 10:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lol. That was my original idea but then i get asked questions like "why do i have to push a button to be ablento read the screen?". Im not sure i can solve the real cause much better than i have unless i put a emi shield over the entire controller or move it to another location which again comes with a string of questions. Given its just a means to a greater end im going to have to settle for the time being.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you actually identified what/where the problem actually is or are you just throwing a solution to a problem without a known cause?

 

If it's a means to an end, then I would agree most with #8, re-initialize the display at a regular interval and see if that gets ya. However, that most likely wouldn't fix your root problem if it's a software problem like stack corruption, overflow, null pointer, or whatever other thousands of problems could occur. And throwing a software fix to a potential hardware problem would be even worse.

 

However, I stick to my original point. Try to find exactly where and what the problem is. It will be worth the effort put into it.

 

[Edit] Added "potential" after "software fix to a potential "

My digital portfolio: www.jamisonjerving.com

My game company: www.polygonbyte.com

Last Edited: Tue. Mar 21, 2017 - 08:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

discombobylates it

 And what does that mean in the English language?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The correct spelling is "discombobulates"

 

http://www.thefreedictionary.com...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No wonder I was discombobulated!

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:

No wonder I was discombobulated!

At least you were not disassembled...

Quotes for
Number 5 (Character)
from Short Circuit (1986)

...

Stephanie Speck: [they're heading for the cliff] Oh, no - Jeez! Number Five, we're gonna be killed!
Number 5: Disassemble?
Stephanie Speck: Yes, disassemble ALL OVER THE PLACE!

Number 5: No disassemble Number Five!

...

======================

I've used character LCD read-back in a few apps over the years. [has OP really specified what "LCD" means?]

 

Background:  I started with the CodeVision character LCD library as my driver.  That driver is of the "busy flag" type.  So failing operations will hang.  I modified it to be "soft" and to time out and note/log/report the failure.  (I put essentially a dummy counter in the wait loop and abort the operation if too many passes.)

 

With that in hand, some apps will do the init and put out the welcome message.  I then read back one or two bytes out of the display's memory and compare to what I put out.  Actions on failure vary according to the app.

 

I use CodeVision's lcd_read_byte() routine.  I could post for examination if really needed. 

 

I agree that discombobulation shouldn't happen in normal operation or bench testing, and the root cause should be determined.  However, I also cannot disagree with a mechanism to indicate a "live" display, whether part of POST (Power-On Self-Test) or periodically during operation.

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. Mar 22, 2017 - 01:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

NB:  IME the number one cause of character LCD problems is a ratty signal on the E line.  Especially e.g. in a lashup with fly wires.  (the small 'scope probe capacitance often clears it up, when probing E on the display.  so simply ship a 'scope with each unit)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.