Replies: 3 comments 2 replies
-
|
This sounds interesting for future drivers, but back-porting it to existing drivers sounds like a huge amount of work. Especially given that at least one driver was contributed by a user and I don't have the display hardware to test it. |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, I too am working with the Waveshare 3.52" and paired it with an STM32U07xx micro-controller. I currently have the setup up and running with full refresh taking < 1s (eyeballing it). Happy to help out here as needed! Also, I am curious about the ways to refresh the display. Currently I use the 0x17 followed by 0xA5. however, according to the datasheet UC8253C, it would appear that there is a faster refresh command (0x10 -> 0x11), but cant seem to get that to work. Also, I am quite interested in the partial refresh but I am not sure where to start. Any suggestions? Cheers, P.S. I am happy to test things out as well if it helps out! |
Beta Was this translation helpful? Give feedback.
-
|
Partial updates are something of a hornets' nest. Firstly the quality of display hardware varies. I have found only one display with really satisfactory partial updates - the Waveshare pico 4.2". Secondly the way to program partial updates can be difficult to establish. I tend to cheat by porting the vendor's C code to MP. I would very much like to find a display with good partial updates from another vendor. There is a limit to how may of these things I can buy so contributions are very welcome. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
There appears to be a great deal of commonality between the files for the various ePaper display drivers. I'm in the process of writing another one (for Waveshare's 3.52" 360x240 display) and it's largely a copy-paste-edit exercise. I've written some efficient Viper code to handle rotation by 90N degrees on the fly during sending of the image, but I only have it in my driver, not for the other displays. Having the drivers structured as individual monolithic files means that future fixes and enhancements that pertain to all displays are going to need to be replicated across half a dozen different drivers too.
So, once I've finished my new driver, would there be any interest in refactoring the code to move all the common parts into a superclass and making the individual drivers just hold information about the display dimensions and depth and the reset and LUT tables? If there's some compelling reason of which I'm unaware for keeping the driver to a single file then it would be good to know. Otherwise it seems that some refactoring is in order.
Beta Was this translation helpful? Give feedback.
All reactions