Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements to prevent corruption with OLED scrolling #497

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jake-b
Copy link
Contributor

@jake-b jake-b commented Mar 9, 2019

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 writeCWInt and clearCWInt functions 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.

@g4klx
Copy link
Owner

g4klx commented Mar 11, 2019

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?

@jake-b
Copy link
Contributor Author

jake-b commented Mar 11, 2019

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.

@phl0
Copy link
Collaborator

phl0 commented Mar 11, 2019

I could give it a try in all DV modes. Which OLED is needed?

@jake-b
Copy link
Contributor Author

jake-b commented Mar 11, 2019

This is the 0.96" OLED code. I'm using a cheap one from AliExpress.

@phl0
Copy link
Collaborator

phl0 commented Mar 11, 2019

Ok, have one of those here. Will take some days though :(

@jake-b
Copy link
Contributor Author

jake-b commented Mar 11, 2019

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:

mmdvmhost_oled

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.

@EA5SW
Copy link

EA5SW commented Mar 11, 2019

The OLED code needs a new library because ArduIPI OLED are a little bit obsolete.
I just buy a 128x128 SSD1327 OLED and don't have a good support and I think that OLED screen have already a lot of improvement... under my POV.

@shawnchain
Copy link
Contributor

It's true that we should stop scrolling before update the screen to avoid glitch. I will try this patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants