jjjjcol Posted March 3 Report Posted March 3 I took the ssd1306 code and modified it to work with the ssd1351. I don't know what FPS it can hit, looks like its well over 30fps. Feel free to use it: https://github.com/jamesoncollins/gauge_driver/blob/master/cubeide_proj/ugfx/drivers/gdisp/SSD1351/gdisp_lld_SSD1351.c
inmarket Posted March 4 Report Posted March 4 Thank-you. Nice work. We will add to the standard driver collection as soon as possible.
jjjjcol Posted March 9 Author Report Posted March 9 I've noticed a number of drivers use the "stream" methods. These seem very easy to implement, but also it seems they'd always be very slow. Is there a benefit to those methods? Is there a reason so many drivers use this method? Was the other option added later?
inmarket Posted March 10 Report Posted March 10 It all depends on the display controller. Some display controllers - that is just how they operate. In terms of speed, they can be just as fast as any other mechanism. It really all comes down to bus speed and the type of bus. For some bus types and speeds streaming controllers can be faster than any other type. Try doing framebuffer pixels writes over a slow I2C bus would be terribly slow, a streaming controller and driver can however perform really well. uGFX is pretty unique amongst graphics libraries because it doesn't require direct access to the framebuffer in RAM. It was with this basic tenant that the first version of uGFX was written, and its first hardware controller was a streaming driver.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now