Improvements to prevent corruption with OLED scrolling #497
Conversation
|
I can't test OLED displays, I don't have one. Therefore I need you to completely debug this yourself then I'll add it to the repository OR close this pull request. I then create an OLED branch which you can do pull requests against and others can test also. What do you think? |
|
I understand. I don't expect any bugs, but I'm not going to buy several more radios just to test the various paths of the OLED code, and I wouldn't merge completely untested code. I'm not sure how many other people would really test a branch either. Most people, I'm sure, are getting the MMDVMHost as part of a distribution and probably wouldn't install a custom-compiled version anyway. |
|
I could give it a try in all DV modes. Which OLED is needed? |
|
This is the 0.96" OLED code. I'm using a cheap one from AliExpress. |
|
Ok, have one of those here. Will take some days though :( |
|
I don't think there is any hurry. I have been using the new code on mine for a few days and it is significantly more stable, especially with scrolling enabled. I can only test the DMR mode though. The problem with the old code was it would enable scrolling and then attempt to write new pixels to the OLED and/or re-enable scrolling without disabling scrolling first from a previous transaction. This caused memory corruption in the area with scrolling enabled. Here's how it looks before the fix:
I suppose the issue could be specific to a variant of the OLED. I'm sure the cheap ones on AliExpress are not exactly all to specification... but it behaves significantly better in my experience. |
|
The OLED code needs a new library because ArduIPI OLED are a little bit obsolete. |
|
It's true that we should stop scrolling before update the screen to avoid glitch. I will try this patch. |
Okay, so don't accept this one without a little bit of testing. I only have a DMR radio so I can't test the other modes (P25, DSTAR, etc.)
In my research I have found that the SSD1306 has limited RAM and when the scrolling modes are used you kind of need to do things in a specific order -- Stop scrolling, draw, start scrolling again. Otherwise you get display memory corruption.
This pull request tries to centralize the draw/scroll method in a single place, and keep display transactions standardized in this manner.
The
writeCWIntandclearCWIntfunctions use a different kind of scrolling than the StatusBar and Idle scrolling, so that should probably be tested too.In my use with DMR radio, the display is much more stable with this code.