But I can’t get the brightness all of the way down. A nice fade-in/out function would be grate on the Arduboy. Maybe switching the display on/off with a timer might do it?
I did some experiments with the set fade out and blinking (0x23) command to see if it might be useful to add a blink screen function to the Arduboy2 library. It turned out to have the same limited brightness range as the contrast command. (It likely uses the same hardware.) So, I didn’t bother doing it.
For the same reason, as you discovered, I didn’t feel it was useful to add a contrast control function to the library.
@Dreamer3 (aka yyyc514 on GitHub) did some work a while back on using a combination of contrast and charge pump control to extend the range of brightness control. I haven’t looked at how successful he was or how well it works.
Yeah it doesn’t seem the contrast has much effect. It may be that since we don’t use a proper power regulator on our voltage supply so that the voltage/current is allowed to fluctuate according to the current consumption?
It’s just the way the display works. Even my home made system, with the display running at a constant regulated 3.3V, has about the same range of contrast control.
I tinkered a little bit with this command. The key is to reduce the pre charge time to a minimum. I am not an expert for these displays but it works pretty well, so before you set the contrast (once after boot is enough) do this:
LCDCommandMode();
SPI.transfer(0xd9); /* pre charge period */
SPI.transfer(0x11); /* 1/1 DCLK for phase 1 and 2 */
A video how this looks is here however in reality is looks much more awesome. Probably I should have used more white
It should be noted that the skew rate usually drops as the loading goes up. The pre-charging loading of a row with a bright horizontal line on the display is very different from a row with only a few lit pixels. To determine the pre-charge period and the driving strength, the slowest skew rate has to be accommodated, otherwise some rows with more ON-pixels would not have enough pre- charge, and they would appear to be dimmer than other rows. The display brightness would become uneven.
Holy smokes this means you could theoretically fix the banding artifacts! You would have to precompute the value from the row and adjust on the fly but, it’s possible! Wow amazing work! I’ve got to admit I’ve always been a bit puzzled by some of the OLED commands. Great stuff!
Great work, although it still isn’t full-off to full-on. It’s a shame whoever made that youtube video vanished without even saying what controller was on the screen, or what it was being used with.
But that idea about fixing the banding sounds interesting, my fame suffers from it a lot as my backgrounsd are mostly big blocks of black or white.
When I set the contrast to 0 and the pre charge period to a minimum on my arduboy the logo (this is my test) is almost not visible. The brightness is very low. If you want less than that you need to turn the screen off. (sorry for the poor quality, too much coffee)
@JO3RI I did the experiment. Actually the two rectangles have a different colors (one is white the other grey, depends on the contrast) but the problem is the tearing. It is visible very much during this test. Till now I did not find any solution to reduce the tearing without the FR pin.
@JO3RI Did it but unfortunately it does not make a difference. I uploaded the test to github:
I think getting rid of the tearing without the FR is almost impossible as according to the datasheet the only way to be in sync with the controller when it writes to the display is the FR pin. Even if we would find a timing that looks like it fits there is still a drift either by the clocks or just by jitter on the AVR due to interrupts.
However I look forward that some smart people find creative solutions.
Thanks a lot for this! I implemented a screen fade-out into the ending of my game, it looks really cool for a device normally only capable of black or white