Go Down

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


You're right, the liquid crystal in the display doesn't react fast enough for animation. I refresh the data on mine (while on blue) at 2 fps, because it takes around 0.5 sec for the display contrast to settle when the pixels change.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.


Bill, can you publish your code for the FPS measurement?
I would like to know how to calculate the overall FPS rate.



Here are some results from u8glib:

  ST7920_192X32, SPI:    FPS: Box=7.6   @=9.8                iFPS: Box=11.4  @=14.7
  ST7920_192X32, 8Bit:   FPS: Box=6.2   @=7.5                iFPS: Box=9.3 @=11.2
  DOGM128 SW SPI:         FPS: Box=5.1   @=5.9               iFPS: Box=10.2 @=11.8
  DOGM128 HW SPI:         FPS: Box=5.5   @=6.3               iFPS: Box=11.0 @=12.6

The "Box" mode is what Bill has measured. I also added the @-draw test.
Not a surprise: U8glib is much slower. But it also supports write-only devices without the need of a full frame buffer.



One of the things that glcd lib does, which is what makes the rendering code, especially for text
so complex is that it will avoid reads of display memory whenever possible.

For example, when rendering, it renders or paints pixels into a local 1 byte register
that is used as a 1 byte page buffer and then writes that byte to page memory.
Whenever the size of what is to be rendered is a multiple of the page size (8 pixels)
and aligns on a page boundary (8 pixels) then there will be no reads.

When clearing the screen, there are no reads from memory just writes to the glcd memory.
There will also be no reads from glcd/frame-buffer memory if rendering text that is 8, 16, 24, 32, ...
pixels in height that land on a vertical modulo 8 pixel boundary.
Nor would there be any reads from memory to render a bitmap that is a multiple of 8 pixels in height
and lands on a vertical module 8 pixel boundary.

While this is very fast and works great to eliminate reads, this rendering method only works
well for devices that use 8 pixel vertical pages. It also doesn't allow doing things like changing the x,y origin,
rotating the display orientation, or rotating the actual text.

In the big picture, once you get much beyond 4-5 FPS, it's pretty much ok since
the liquid crystal in the display often takes a while to change anyway.
The biggest thing is does the user notice any lag in the display being updated
or does it slow down the CPU to prevent it from getting its other tasks done.

--- bill


Bumping this topic.

Has anybody suffered this same fate ( need faster screen, to keep up with arduino ) or is it due to contrast. I have a POT connected to 5v and GND with the wiper going to backlight anode. What is the proper way to do contrast on these displays as this just dims the backlight. Pixels to backlight contrast is still equal.

The only Identifiying marks my screen has is 'HJ12864ZW' and the datasheet is entirely in chinese, So I have had to use the generic ST7920 datasheet.

I have the same screen and the same problem. Pot wiper to v0 won't do anything, in fact, I haven't been able to change contrast at all.

The datasheet says "VLCD (V0 to VSS): max 7V". Also, under "DC characteristics": VLCD (LCD Voltage) Test condition:V0-VSS 3.0-7V .

Can anybody give me a clue?


Go Up