1

I have an LCD (the DOG-M 102x64, with a uc1701 controller) that I am driving (over SPI, but that's somewhat irrelevant) from an AVR (ATMega16 @ 8 MHz) - all in all, a fairly low spec'd screen with a low-spec'd system. The screen at hand is only capable of 1-bit display, but I would like to emulate some shades of grey with it (per-pixel).

Reading through the controller datasheet offers some ideas: there exists commands that will turn on all pixels, and another that will invert the display (not affecting the display ram).

I've searched around, and the information I came up with was in a question posted here, commenting mainly on biasing of the liquid crystal over time. I'm also aware of Binary Code Modulation, perhaps that could be applied to this problem?

Is this technique a viable method for emulating greyscale? Has anyone done it before?

Edit: Found this resource which illustrates that the concept might be somewhat viable.

Edit: Found this resource that makes me think rapidly switching between two framebuffers (2 bit planes) might not only be a viable approach in general, but might also have some long-term negative effects on the LCD if done incorrectly.

Community
  • 1
Lucas
  • 185
  • 1
  • 7
  • Depending on how fast you can send/execute the "invert the display" command. You can invert a blank screen to a black screen and back again. Doing this on different speeds/ less black-time will make it visible as grey scales. Same as when dimming a led. – Paul May 01 '15 at 09:22
  • Also some LCD's have adjustable backlight, you could use that driven by a PWM pin to create other greyscales. – Paul May 01 '15 at 09:25
  • 1
    @FuaZe Modifying the backlight brightness would obviously alter the entire display; he needs to be able to modify the brightness of individual pixels. Same for your first comment about inverting the display. – tcrosley May 01 '15 at 09:55
  • 1
    `I would like to emulate some shades of grey with it.` It actually does exactly that. His question should have stated something like "I want to emulate/show different shades of grey at the same time on different parts of the screen." or something like: "I want to make greyscale images"? He doesn't say why he wants this to be done. Maybe he wants to make the screen fade in/out. Than it's a valid solution... Maybe he want's a greyscale image... other answers will apply. – Paul May 01 '15 at 10:08
  • Good comment, I guess I should've clarified. I'm definitely after per-pixel greyscaling. I might implement some whole screen grey levels as well as general backlight dimming with PWM. Is there a recommended way to PWM such that it doesn't sync up with the display refresh rate and cause a ripple effect? Maybe some sort of spread-spectrum / phase noise introduced? – Lucas May 01 '15 at 10:48

1 Answers1

3

About the only way to simulate grayscale using a 1-bit display is to do pixel averaging, e.g. using a square of four pixels to represent one pixel in the original image,

0 pixels on (white) = 0%
1 pixel on (light gray) = 25%
2 pixels on (medium gray) = 50%
3 pixels on (dark gray) = 75%
4 pixels on  (black) = 100%

Unfortunately, you don't have enough pixels on your screen, and the ones that are there are too big to allow this technique.

tcrosley
  • 47,708
  • 5
  • 97
  • 161
  • Why wouldn't having a few different bit planes and displaying them for different amounts of time work? Trade spatial resolution for temporal? – Lucas May 01 '15 at 08:33
  • @Lucas First of all, that's not the display you said you were working with (102x64x1 bit). Secondly, you can't display pixels for different amounts of time, because you wouldn't be able to write to the display fast enough to turn them on and off. To avoid flicker, you would need to write to the display 30 times/second; 102x64*30 = about 200K pixels per second, or one pixel change every 5 µs. I don't think your microcontroller could keep up with that. (cont'd) – tcrosley May 01 '15 at 09:51
  • However, using a three plane display (where the top layer is on 25% gray, second layer 50% gray, and bottom layer 100%), by turning pixels on each layer on and off you could achieve the five levels of brightness in my answer (75% would be done by turning on pixels for both the first and second layers). This would not require any fast switching of pixels on and off. How well that would look, I don't know. – tcrosley May 01 '15 at 09:52
  • Sorry, I'm not sure what you meant by "First of all, that's not the display you said you were working with (102x64x1 bit)."? – Lucas May 01 '15 at 10:54
  • @Lucas In your question, first thing you say is "I have an LCD (the DOG-M 102x64" and then later "screen at hand is only capable of 1-bit display". – tcrosley May 01 '15 at 11:12
  • Correct me if I'm wrong, but i'm under the impression that the dogm 102x64 IS only capable of 1-bit depth. – Lucas May 01 '15 at 11:19
  • @Lucas Correct, that's the assumption I've been going on all along. That's what I said in my comment just above yours. When I said earlier, "that's not the display you said you were working with (102x64x1 bit)", I was referring to your first comment about a multiple bit plane display. – tcrosley May 01 '15 at 16:44
  • Oh, by multiple bit plane I meant having many frame buffers (one for each bit), and cycling through them rapidly, displaying each for a time weighted by their bit significance (LSB is displayed for one time period, the next bit is displayed for 2 time periods, the next 4 and so on...) – Lucas May 01 '15 at 20:26
  • @Lucas Well as I mentioned in an earlier comment, to avoid flicker you would have to update the display 30 times per second or faster (one pixel every 5 µs), unless the display controller has multiple frame buffers. Even in that case, you still need to keep them up to date. – tcrosley May 01 '15 at 21:20