Go Down

Topic: Cursor position after lcd.print() and lcd.scrollDisplayLeft() (Read 2 times) previous topic - next topic

floresta

#10
Feb 12, 2013, 05:06 am Last Edit: Feb 12, 2013, 05:09 am by floresta Reason: 1
Quote
That was very helpful in understanding the guts of things, although I had assumed (perhaps incorrectly) that the LiquidCrystal library would take care of the sausage making, so to speak.

Before I forget (again) I think that I may have something for you along these lines.  A while back one of our forum contributors was dealing with 40x4 displays which are essentially two 40x2 displays in the same package.  While he was developing his liquidcrystal440 library he also did some work on the timing (since he had some incredibly out-of-spec displays) and also on the line wrapping.  The library is not restricted to 40x4 displays, it works with the smaller ones as well.  That original library has evolved into LiquidCrystal1.0 and to get a copy start here:--> http://code.google.com/p/liquidcrystal440/ and follow the Downloads link to get to the latest version.

Quote
Don do you have any example sketches for LCD control that don't use the LiquidCrystal library?

I do almost all of my work in assembly language but I know have some LCD stuff written for the pre 1.0 versions of the Arduino IDE around here somewhere since that's what I sent John when he was working on his liquidcrystal440 library.  I'll look for it.

Quote
My only question is whether I will be able to loop through 40 positions (x2 lines) fast enough.

I hope you understand that the 2 lines will inherently shift at the same time.  You can get around this with programming so it's is not a deal killer.

You might want to experiment by writing a 'normal' string of about ten characters to the display and then send at least 100 shift left commands, with a pause between each so you can watch what is going on.  You may be surprised at the result.


Don

bperrybap


 My only question is whether I will be able to loop through 40 positions (x2 lines) fast enough.

"fast enough" is a relative term.
How fast do you need to update the display? How often? How many cycles are used by other stuff?

The supplied LiquidCrystal library can update a full 16x2 display around 87 times per second or in around 11.5ms
If you switch to fm's LiquidCrystal library replacement,
it can update a full 16x2 display around 300 times per second or in around 3.3ms

The key to keeping the display updates fast and avoiding flicker is to avoid using lcd.clear() and lcd.home()
Those commands are quite slow.
With fm's library you can update the entire 16x2 display faster than time it takes lcd.clear() to execute.

You may want to consider managing a shadow display buffer in RAM.
Fill it in the way you want the display to look. Then, slam out the buffer to the display.
You can manage the shadow buffer anyway you like.
Either creating a full shadow buffer of all the display ram that you index into to create the scrolling effect
or just have the local buffer represent what will be displayed on the lcd.
I would think that even the supplied LiquidCrystal display should be more than fast enough to
do what you need.

--- bill


rwiens

Quote

How fast do you need to update the display? How often? How many cycles are used by other stuff?


I haven't figured out the exact speed (and it will actually change depending on the content) of the scroll but I would say at the fastest I need to shift at about 60ms (i.e. a character goes all the way from col 15 to col 0 in 1s).  The question is whether I could read and re-write all 80 characters in that time.  Sounds like the fm LiquidCrystal library replacement will at least update the display quickly enough (where do I find it?).

Quote

I hope you understand that the 2 lines will inherently shift at the same time. 


This is exactly what I am trying to accomplish.

Quote

You might want to experiment by writing a 'normal' string of about ten characters to the display and then send at least 100 shift left commands, with a pause between each so you can watch what is going on.  You may be surprised at the result.


I did some experimentation along these lines and did get unexpected results.  One thing I thought about was trying to read the memory pointer from the display controller to see what was happening.

Quote

You may want to consider managing a shadow display buffer in RAM.


I assume you are talking about the Arduino RAM?  The more I think about it, the more that seems like the easiest solution, although now I am curious about understanding what is actually happening in the display controller.

Thanks again for all your help.

floresta

Quote
I did some experimentation along these lines and did get unexpected results.


Just so we are on the same page here ....
(1) what did you do (in terms of programming)?
(2) what results did you get?
(3) what results did you expect?


Don

bperrybap


Quote

How fast do you need to update the display? How often? How many cycles are used by other stuff?


I haven't figured out the exact speed (and it will actually change depending on the content) of the scroll but I would say at the fastest I need to shift at about 60ms (i.e. a character goes all the way from col 15 to col 0 in 1s).  The question is whether I could read and re-write all 80 characters in that time.  Sounds like the fm LiquidCrystal library replacement will at least update the display quickly enough (where do I find it?).


60ms is a LONG time to a micro-controller.
Keep in mind, the times I quoted are to update the entire 16x2 display.
Doing this:
lcd.setCursor(0,0);
lcd.write(char); // repeated 16 times
lcd.setCursor(0,1);
lcd.write(char); // repeated 16 times.

All that gets done in 11.5ms on the standard library or 3.4ms using fm's library

( https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home )
To write an individual character to the display or position the cursor takes:
338us with the standard LiduidCrystal library or 98us with fm's library.


You don't need to re-write 80 characters.
All you need to do is write the 32 characters visible on the display.

In looking at your timing and doing some math:
You are wanting to scroll characters from col 15 to col 0
that is 16 "moves" in 1 second that means each move needs to happen in
1/16 of second or 62.5ms.
The standard LiduidCrystal libraray can update all 32 characters on the display
in 11.5ms and fm's library can udpate all 32 in 3.5ms.

When using the standard library that means you use
11.5ms out of your 62.5ms budget. Which means that
updating the display uses about 18% of the CPU available in your timing interval
which means you still have 72% of the CPU left over to do all your other stuff
like reading information from the SD card etc.
While fm's library would reduce that budget to just under 6%
my gut feeling is that based on what you have said you want to do
the standard LiquidCrystal library should be capable of doing what you want
even when updating the full 16x2 display each time you need to do a move/animation.



Quote

You might want to experiment by writing a 'normal' string of about ten characters to the display and then send at least 100 shift left commands, with a pause between each so you can watch what is going on.  You may be surprised at the result.


I did some experimentation along these lines and did get unexpected results.
One thing I thought about was trying to read the memory pointer from the display controller to see what was happening.


The memory pointer increases (assuming left to right) each time a character is written.
The memory pointer is set to an absolute address when setCursor() is called.


Quote

You may want to consider managing a shadow display buffer in RAM.


I assume you are talking about the Arduino RAM? 

Yes, just fill in your buffer and then write it to the display.
You can update the entire display, which is every single character position on a 16x2 display
in 11.51ms (87 times per second) using the standard library or in 3.35ms (~300 times per second)
If you shadow the full LCD ram, you can make things shift by simply changing the index
of where you start grabbing characters from memory.
Also if you use a local RAM buffer you will be able to shift the two lines independently.



Go Up