LCD read purpose?

Discussion in 'Embedded Systems and Microcontrollers' started by tracecom, Jan 24, 2014.

  1. tracecom

    Thread Starter AAC Fanatic!

    Apr 16, 2010
    3,869
    1,393
    Many LCD's can be read from, but I can't think of a purpose for that capability. What do you use it for?
     
  2. MaxHeadRoom

    Expert

    Jul 18, 2013
    10,550
    2,374
    One is to read the Busy flag, rather than using arbitrary wait delay routines.
    Less used in the eprom data & cursor address can be read if needed.
    Max.
     
  3. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,392
    1,605
    Say you have something like a 20 character by 4 line display, and you want to remember what's on it. Either you can keep a copy of the text data in an 80 byte buffer, or you can read it back off your device.

    Then there's also reading back the busy flag.
     
  4. takao21203

    Distinguished Member

    Apr 28, 2012
    3,577
    463
    that's no longer relevant with today's controllers.
    Early one's only had small RAM, let's say, 128 bytes, or even less than that.

    On the other hand, due to the timing and strobing, you need additional ROM space if you use these RAM areas for reading.

    In the 1980s when these LCDs were introduced, it was common to program controllers in assembler.
     
  5. MaxHeadRoom

    Expert

    Jul 18, 2013
    10,550
    2,374
    I still do;)

    I just use the 'read busy' signal to avoid wait loops.
    Max.
     
  6. takao21203

    Distinguished Member

    Apr 28, 2012
    3,577
    463
    i still have all my assembler sources but even looking at the larger one's makes me a headache.

    For LCD, I first write to a RAM buffer with LCD commands, and then I send them to the LCD via timer interrupt scheduler.

    Depends on the circuit, sometimes I only send a slice each time (or the main program becomes too much disrupted from the delays).
     
  7. JohnInTX

    Moderator

    Jun 26, 2012
    2,347
    1,029
    I once used the unused character space as auxiliary RAM after a tussle with creeping featureism on a 16C5x system. The Hitachi 44780 has 80 bytes of character RAM but only the physical number of displayed chars have to be used as such (that's why you have to reset the address pointer when changing lines on a shorter than 40ch display). Any display RAM that is 'off the screen' is available.

    Just watch how you use Clear Display..

    EDIT: you probably could use the CG RAM as well, another 64 (partial) bytes, but I didn't need to..
     
    Last edited: Jan 24, 2014
    ErnieM likes this.
  8. THE_RB

    AAC Fanatic!

    Feb 11, 2008
    5,435
    1,305
    Reading from LCDs is pretty much obsolete these days.

    Most of the newer generation LCDs/TFTs etc don't have read capability at all.

    It's not necessary to read the busy flag, LCDs are very fast in normal operations apart from the slow "clear display" command mentioned above by JohnInTX.
     
  9. AfdhalAtiffTan

    Active Member

    Nov 20, 2010
    117
    11
    I use it mainly for extracting the cursor-position just before the MCU goes into ISR;

    I'm not skilled enough with ISR that most of the routine ended up messes with LCD writing process. i.e. after ISR, the characters randomly placed on the screen.
     
  10. Brownout

    Well-Known Member

    Jan 10, 2012
    2,375
    998
    Without reading the busy flag, one of every 3rd character was being displayed on the 2x16 LCD in my current project.
     
  11. spinnaker

    AAC Fanatic!

    Oct 29, 2009
    4,887
    1,014
    You are doing something wrong. Are you certain all characters are being sent?

    What happens when you step through your code and send a character at a time?

    Where is your code that writes to the lcd?
     
  12. Brownout

    Well-Known Member

    Jan 10, 2012
    2,375
    998
    Yes, all the characters are sent. I changed my code to read the busy flag before sending the characters, and it works.

    Code ( (Unknown Language)):
    1.  
    2. //Copy second line to top line
    3. for(i=0; i<16; i++) {
    4. while(BusyXLCD() );
    5. WriteDataXLCD_local(topline[i]);
    6. }
    7. [/i]
     
  13. THE_RB

    AAC Fanatic!

    Feb 11, 2008
    5,435
    1,305
    Did you exceed the timing spec as shown in the Hitachi 44780 datasheet?

    Most likely you were sending the characters too fast and ignoring the required timing.
     
  14. MaxHeadRoom

    Expert

    Jul 18, 2013
    10,550
    2,374
    If you use the simple read of the LCD busy flag, there is no need for time delays.
    Max.
     
  15. Brownout

    Well-Known Member

    Jan 10, 2012
    2,375
    998
    That's why I read the busy flag in my code.
     
  16. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,392
    1,605
    Obviously people are responding to your post without taking the time to actually read your post where you quite correctly point out the use of the busy flag to give the display time to process your character data.

    You correctly point out why and where reading an LCD is useful and/or necessary, but those who have already concluded the opposite will never admit your point.

    Aside@Brownout: Is that the Microchip XLCD library you are using? I've been using that for years now, it works well but I've made several tweeks to it, such as placing the BusyXLCD() routine inside every other LCD function that should call it first. That way it never gets forgotten.

    While I always use the read function I've been meaning to go back and do a conditional compile to add a delay when you don't use that line.
     
  17. Brownout

    Well-Known Member

    Jan 10, 2012
    2,375
    998
    I use a hacked up version of it. I used the libs as examples, along with other code, to create my own version. When I was trying to get my LCD to work, I had long delays so I could see the data change and verify it is what I expected. I never went back to using the standard libraries yet.


    That's a great idea. I'm gonna look into that.
     
  18. spinnaker

    AAC Fanatic!

    Oct 29, 2009
    4,887
    1,014
    BrownOut tried doing without the flag and and mentioned it was not working. People are just trying to get his code to work without reading the busy flag. It can be done. While it might be necessary in some applications like sleep as was pointed out above, it certainly isn't necessary in a typical application if proper timing is done. And no one is saying the feature is not useful in certain situations.

    Stepping through the code and sending one character at a time would have revealed a timing issue.
     
  19. Brownout

    Well-Known Member

    Jan 10, 2012
    2,375
    998
    I only forgot to put in the line that reads the busy flag and observed it doesn't work without it. Then I read a comment that said LCD's are fast and don't need the busy flag read.

    Why? It works great, and if I change the clock frequency, I don't need to adjust the dealys in the code. This is the prefered method, IMO.

    In the beginning,when I first attempted to get the LCD to work ( and I was brand new to PIC programming ) I connected 8 LED's and stepped through the code to make sure correct data was sent to the LCD. I also wrote in long delays so I could observe the data wihtout needed single step. But in my real code, I read the busy flag because that eliminates the need for delay timing.
     
  20. spinnaker

    AAC Fanatic!

    Oct 29, 2009
    4,887
    1,014

    Sorry meant to say there are other useful features of the LCD that you don't need in typical situations. The cursor position for example could be used to remember the cursor position during sleep.

    Busy is useful too if you want to output as fast as the LCD can handle data.

    But the typical application (at least from the hobbyist) don't usually need to implement them.
     
Loading...