0
\$\begingroup\$

I have a generic question about Graphic LCDs with built-in controllers and RAM. I observe that whenever I change a large portion of the screen with say a new image or a object (or just clear the whole screen with a new color), there is a noticeable flicker. Is there any way to avoid this? I am using the 8080 mode to update the display controller's RAM. The problem occurs because the refresh rate of the LCD is faster than the speed that I am writing into the diaplay's RAM.

I imagine that it should be easy to do if there were an option to update only the RAM of the controller (while the LCD panel retains the old display) until I set a bit to tell the controller that RAM update is complete. Once that's set the controller should output the contents of the RAM on the physical LCD. Is there any way to achieve something like this? The controllers I am referring to are of the class of HIMAX 8232 that come built-in to LCDs.

\$\endgroup\$
  • 2
    \$\begingroup\$ Please share a datasheet of the display and controller in question. Some controllers have double-buffering, display latching or refresh inhibit options. \$\endgroup\$ – Anindo Ghosh Nov 27 '12 at 9:28
  • \$\begingroup\$ displayfuture.com/Display/datasheet/controller/ILI9486.pdf \$\endgroup\$ – eGovind Nov 27 '12 at 9:33
  • \$\begingroup\$ Sorry, I couldn't find a category for "embedded systems", but I figured that electrical engineering ought to cover this. I don't think we should limit ourselves to "electronic design", whatever that is. \$\endgroup\$ – eGovind Nov 27 '12 at 9:37
  • 3
    \$\begingroup\$ @LeonHeller: Sounds like a low-level embedded-systems programming question to me, and more-hardware related than many other such questions. \$\endgroup\$ – supercat Nov 27 '12 at 17:44
  • \$\begingroup\$ Sounds like you might be looking for something which can page-flip between two display buffers - display one while you draw a new display in the other, then switch. \$\endgroup\$ – Chris Stratton Nov 27 '12 at 20:19
3
\$\begingroup\$

While some display controllers cause flicker any time they are written, this particular controller shouldn't have that problem. I would guess you are having flicker because on each update you are writing parts of the display with one value and then rewriting them with another. To avoid flicker, don't do that. Figure out what the correct value should be for each pixel before you write it. If your display consists of various non-overlapping rectangles that could move around, and if you're presently erasing the whole screen and then drawing your rectangular objects, you may be able to improve both performance and appearance by only erasing regions where no objects are supposed to appear; depending upon the application, you may be able to improve performance further by only erasing regions where objects used to exist but have just "disappeared".

Addendum Looking at the supplied picture, what is happening is that the display pixels are being written to in one direction (I would guess top-to-bottom), and the display is scanning in another direction (I would guess left to right). This has the effect that the amount of screen data that has been written when the hardware starts scanning a frame is much less than the amount which has been written by the time the hardware scan reaches the right edge. Consequently, the lines which are drawn near the right edge of the screen will have more data drawn on them than the lines near the left.

If you draw data onto the screen in a direction perpendicular to the display scan, you will get the type of diagonal lines you observe here. If you draw data linearly in a direction which is parallel to the display scan at a rate which is slower than the scan rate, there will be an observable "tear" each time the display scan overtakes your drawing. If you draw data at a rate which is faster than the scan rate, and do so in a fashion which is synchronized with the display scan, you can avoid having any kind of display artifacting, but I have not observed any color LCDs (and very few monochrome ones) with a CPU interface which would allow a connected CPU to synchronize updates with the display scanning. That's too bad, because such an ability would allow cleaner display updates than are possible otherwise. A nice easy technique which was used in many arcade games designed by Eugene Jarvis in the early 1980's was to have the display scanning process interrupt the processor when the scan hits the middle of the screen and again when it hits the bottom. When the scan hits the middle of the screen, everything above the current scan line may be safely updated without flicker provided the updates happen before the scan reaches the bottom. When the scan hits the bottom, everything below the middle may be updated without flicker, provided the updates happen before the scan reaches the middle. It looks as though this controller chip does provide a function to output a pulse when the scan reaches a specified point ("tearing effect line") but I would conjecture that the output is probably not wired to a pin on the display's connector.

I don't know exactly what you're trying to display, but I would suggest that you either work to ensure that any time a pixel is written at all it's written with its "final" color or, failing that, minimize the amount of time between the first and last write to each pixel. For example, if you don't have enough memory to buffer anything externally, you might clear 32 rows of pixels, and then draw everything which should appear in those 32 rows, then clear the next 32 rows, draw everything which should appear there, etc.

Addendum 2

If you have a 16-bit data bus which connects to both the display and the SRAM, and if you have at least one address bit coming out of the CPU that doesn't connect to the RAM (e.g. A18), a useful technique would be to connect that extra address bit with some logic so that any read or write access will be handled by the SRAM as normal, but if that bit is "1" it will also hit the "write data" strobe on the display. If you do that, reading a word of RAM at its normal address will behave as it normally would, but adding 0x00040000 (assuming you use A18) to the address and then performing the read would cause that word of data to be sent directly from RAM to the display (the processor would also read the data, but it wouldn't have to do anything with it). If you don't have an extra address bit available, there are other techniques you could use instead, but I'd have to know more about your hardware to know what to recommend.

\$\endgroup\$
  • \$\begingroup\$ i.imgur.com/86NKh.jpg . The original screen color was Green and I am filling it with a light blue. You can see two slanting lines in the frame. That is the "flicker" I am talking about. I get this whenever I re-write a large portion of the screen (or moving between two different screens). As for your other suggestions, you are right, I should only be writing only those pixels that need be modified.. I am trying that.. Thanks! \$\endgroup\$ – eGovind Nov 28 '12 at 4:17
  • \$\begingroup\$ Does the solution lie in directly driving the display, in which case I can control the display refresh rate? \$\endgroup\$ – eGovind Nov 28 '12 at 4:23
  • \$\begingroup\$ @Sredni: See addendum. \$\endgroup\$ – supercat Nov 28 '12 at 16:02
  • \$\begingroup\$ wow thanks for that detailed post! I will try this out tomorrow! I actually do have access to the Tear Enable line, though I didnt know how to use it \$\endgroup\$ – eGovind Nov 28 '12 at 16:09
  • \$\begingroup\$ @Sredni: The normal way to use "tear enable" is to wire it to a processor interrupt or other pin, and divide your screen updates into pieces that will confine updates to only half of the frame (by the look of it, either the right half or left half), and take less than half a frame scan time to complete. If your updates are too slow, you might not be able to do a whole lot with the signal, but even if you can't update everything on every frame you could take control over what appears when, and may be able to turn slow updates into "visual effects". \$\endgroup\$ – supercat Nov 28 '12 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.