20x4 character LCD the next step

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

I am interested in getting my 20x4 character display to behave like a typical PC monitor in text mode. Typically, they can shift left or right but not up and down. Has anyone attempted to make a project that shifts the lines up after a left to write print line on the fourth line is complete?

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

All that you need to do is provide a verticalscroll()

 

e.g. read_LCD memory line#1 and copy to line#0.   Repeat for #2, #3.  Write 20 spaces into line#3.  set cursor to (0, 3) i.e. line#3

 

Not all hardware supports reading the DDRAM.   e.g. pcb with RW = GND

 

Not all libraries support line wrap.

 

Since a 20x4 only needs an 80 byte buffer in SRAM,   it is easier to handle your text in an AVR buffer.

 

David.

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

Hello David

 

Thanks for the quick reply. I've never used the read ability. So I am in the first stages of writing my managed '... AVR buffer ' :-) But was indeed hoping there is someone who's done the ground breaking already. The added complication is that I have to use the goto line function because the first line normally wraps to the third line, etc... as you probably already know.

 

Regards

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

Just keep a local "char screen[4][20]" and actually do your drawing into that then have a routine to then write the content from there to the actual hardware.

 

Vertical scrolling then simply becomes  screen[0]<-screen[1], screen[1]<-screen[2], screen[2]<-screen[3] at the time a write needs to be made beyond [3][19] and thus force everything to scroll up.

 

As you can access each line separately then there should be no issue with the actual line addressing in the display itself - just position to the right place before writing the whole of a line.

 

If you are keeping a buffered copy then you may want to consider exactly when you need to do a rewrite of it onto the hardware. (not necessarily writing the whole screen again just for the update of one character).

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

In one project many years ago I implemented two buffers in order to determine what had changed. A 1ms tick would determine what needed to be updated and do it in the background. The main line code would just write to the first buffer and everything else was taken care of.

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

I would follow Cliff's advice.   Maintain a copy in AVR memory.

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

I like Kartman's further advice too - if you "ping-pong" two copies you would be able to do timed updates and only draw when you know one buffer has advanced beyond the other.

 

However I'd start with the simple, one copy idea first though. Get that working - perhaps with just a regular (100ms?) refresh of the display - then add the optimisation of update management when you have the basic concept working.

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

This has been a project I've wanted to do for some time, but just have not got a round to it yet. I did find something that may be what your looking for, I hope to try it out today to see if it is what we want.

Sparkfun/OpenLCD project:  https://github.com/sparkfun/OpenLCD

Jim

edit: update

After looking at the code, it does not look like it will scroll the lines, but all of the basics are there so it may be modified to do so.....

I'll add it to my to do list.

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

Last Edited: Mon. Jan 20, 2020 - 02:20 PM