Go Down

Topic: ST7920 Interface Question (Read 13 times) previous topic - next topic

bperrybap


Good idea. The display size should be mentioned. Maybe the FPS should be scaled to a virtual 64x64 display:
If mFPS is the measured FPS rate and w and h are the display dimensions, then a comparable, size independent iFPS might be

iFPS = mFPS * 64 * 64 / (w * h)

Oliver


ooooo. I really like that.
But I think the math is flipped?
Shouldn't it be
iFPS = mFPS * (w*h) / 64*64

I think  the "virtual" 64x64 display FPS rate should be double the measured rate with a 128x64 display right?

This would be useful even for some of the sed1520 displays the glcd library supports
that are 120x32 or 122x32

While things don't scale exactly linearly for different sizes,
it is about as good as it gets for comparisons of dissimilar displays.

--- bill


olikraus

Oh, yes, thanks for the correction.

Oliver

bperrybap

Ok, so the FPS and iFPS (64x64) got me really curious.
I went and tested the glcd library on a ks0108 just to see how it compared
to the ST7920.
(I wrote a nifty little iFPS sketch that does the calculations)

With glcd on a 128x64 ks0108 using a clearscreen FPS test:
FPS = 79.08
iFPS = 158.16

glcd was using 8 bit direct port i/o driving all the glcd lines
(using nibbles on two ports vs 8 bits on single port slowed it down by 8 FPS)
glcd also uses delays with more accurate timing to match glcd spec timing
like Tas and Tdsw rather than using longer delays using <util/delay.h>
<util/delay.h> has many issues in its delay cycle calculations.
If you don't have the very latest AVRlibC you can get delays
that are many times longer or shorter than you ask for depending
on what you ask for and the F_CPU value.
This effect is worst at the low end like sub 3-5us which is where
these kinds of delays often are.

glcd uses Hans Hendriech's delay_x delay package instead.

So I think getting an FPS of 25.6 using much longer than needed timing delays
for control line setup, data hold times and strobe widths is actually quite good.

If the delays in WriteData() and WriteCommand() were
cut down closer to the spec, the fame rate would go up.

--- bill


smultron

#38
Jan 25, 2012, 09:47 am Last Edit: Jan 25, 2012, 09:52 am by smultron Reason: 1

glcd also uses delays with more accurate timing to match glcd spec timing
like Tas and Tdsw rather than using longer delays using <util/delay.h>
<util/delay.h> has many issues in its delay cycle calculations.
...
If the delays in WriteData() and WriteCommand() were
cut down closer to the spec, the fame rate would go up.


Oops. I was looking at the datasheet a bit better this morning. The delays were indeed ns not us... oh well, that's a bit embarrassing. But its nice to know there is still easy room for improvement.

The purpose of the test was to see quickly whether this display is a completed dud. Now I'm confident something can be made of it, and getting rid of the crude delay is the next thing to do.

pYro_65

Can one of you please post a picture of it refreshing at or above 15 - 20 fps?
From 10 frames to 40 frames per second on my screen ( slowed with delays ), a 64x64 block is pretty much invisible as it scrolls across or down the screen.
Is anyone intending to use it for animation. I ask as I'm not sure weather it is my screen that is really slow or if all st7920 models are ( not the st7920 driver but actual display ).
Please see my post above...

Maybe I just need to purchase a green-black one as they might be faster ( mine is blue bg & white px ).

Go Up