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
CD5220 driver very blinky #105
Comments
Hi! Thanks for reporting this issue. I did write the CD5220 driver recently, and this behaviour is really a compromise to function on as many displays as possible. I presume you're running a build straight off the master branch?
The redraw here is implemented using the atomic display line update commands, and they seem to enable the display to update without having to observe the sequential update of the screen from left to right when sending characters directly. The problem here is that multiple displays emulate the CD5220 protocol and do it in many different ways. Some are slower, and drop characters when you perform delta updates, while some can keep up. Also, remember that this a serial link with no error detection and correction, for the most part. (Unless your display is actually USB driven, with no USB to serial converter built-in to the display) - you're bound to get data corruption sometime. Sending a whole line helps ensure that no data is lost. Even in the event that some characters are dropped, they may get sent again when another update comes around for the same line. Some logic to fully redraw the screen every few delta updates can deal with data loss / dropped characters in the event that we're doing delta updates on the single character level - but your display would flash during the full screen update anyway, so I'm not really sure of the benefits. I'm not really keen about increasing the complexity of the driver to calculate and perform single character delta updates - you need some cost evaluation there, and it can get quite messy - Unless this is indeed implemented in some generic way that can be shared among all the serialPOS drivers and toggled on and off. Otherwise we'd have some bloat in the CD5220 driver even though this concept is something that can be applied to most displays capable of it. Now, you could do a few things to mitigate the issue:
Let me know if this helps. Shenghao |
I guess working on issue #75 would help with this issue a lot too. |
The title says it all. The CD5220 driver seems to redraw the whole screen every frame, so the display is very stuttery. Possibly it's needed to calculate the difference between frames and upload just that.
I have written a Mac driver for my CD7220 display back in the day which doesn't have the issue: https://bitbucket.org/vladkorotnev/vfd-osx/src/master/
However, I'm not sure if it's possible to backport that into lcdproc?
The text was updated successfully, but these errors were encountered: