Displays with driver subclassed from framebuf

Discuss development of drivers for external hardware and components, such as LCD screens, sensors, motor drivers, etc.
Target audience: Users and developers of drivers.
User avatar
mcauser
Posts: 326
Joined: Mon Jun 15, 2015 8:03 am

Re: Seeking display with driver subclassed from framebuf

Post by mcauser » Thu Aug 23, 2018 6:41 am

Have you seen @deshipu 's driver for the SSD1331 display?
It doesn't extend the framebuf, but may provide some inspiration.
https://bitbucket.org/thesheep/micropyt ... c/default/

User avatar
pythoncoder
Posts: 3053
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

SSD1331 driver: background

Post by pythoncoder » Thu Aug 23, 2018 8:04 am

I hadn't spotted that one. I based mine on Adafruit's driver. Porting it to MicroPython was straightforward.

My Writer class for displaying arbitrary fonts was originally a proof of concept for SSD1306 only, but sufficient people were using it as-is (and reporting its limitations) that I decided to make it a practical solution. One aim is that it should "just work" with any display driver, monochrome or colour, which is
  • Subclassed from framebuf.
  • Provides height and width bound variables.
Having done this, I wanted to test it. The following have tested fine:
  • Official SSD1306 monochrome driver.
  • Your PCD8544 (Nokia) monochrome driver pcd8544_fb.py.
  • My SSD1331 colour driver.
Peter Hinch

User avatar
mcauser
Posts: 326
Joined: Mon Jun 15, 2015 8:03 am

Re: Seeking display with driver subclassed from framebuf

Post by mcauser » Thu Aug 23, 2018 11:28 pm

Another set of display drivers in my collection are the Waveshare epaper displays.
https://github.com/mcauser/micropython- ... ld/test.py
https://github.com/mcauser/micropython- ... ld/test.py

I'm not subclassing the FrameBuffer, instead using one in the examples. I could add a Framebuf subclassed version, however, I only own 2 of the displays, so I can't test the other displays without help from others. Most of the panels feature 2 memory areas which you can write to, so would need extra logic in the show() method to know which to draw to.

The repo includes drivers for each of the 14 Waveshare displays, currently with a lot of code duplication as so far I've only simply ported the Waveshare Raspi Python examples to MicroPython so they could run on my STM32 boards. Later I'll restructure them with common ancestors and clean it all up.

User avatar
pythoncoder
Posts: 3053
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

A colour display driver in ~35 lines

Post by pythoncoder » Fri Aug 24, 2018 7:36 am

You've written a lot more MicroPython display drivers than me ;)

The recent ability to subclass framebuf strikes me as powerful, at least for small displays and for those which don't have their own frame buffer (like many EPD's). My SSD1331 driver provides graphics primitives courtesy of framebuf. It can render text in arbitrary fonts in colour via the CWriter class. It does this in ~35 lines of code. The fact that we can now do this strikes me as remarkable.

The SSD1331 has its own frame buffer so we could write a better driver than this one, which merely updates the framebuf then chucks the whole thing at the device. To save RAM it uses 8-bit colour. An improved driver would use less RAM, offer 16-bit colour and be much faster. However to provide the same functionality using the device's frame buffer would need considerably (10x?) more code, and for basic information displays I doubt the speed gain would be noticeable.
Peter Hinch

User avatar
pythoncoder
Posts: 3053
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Colour OLED display drivers

Post by pythoncoder » Fri Sep 07, 2018 9:46 am

I've posted drivers for SSD1331 displays (Adafruit 0.96 inch OLED) and SSD1351 (Adafruit 1.27 inch and 1.5 inch) colour OLED's). These are based on framebuf and use 8-bit colour to minimise the buffer size. Buffer sizes are 6144, 12288 and 16384 bytes respectively. These are large but manageable on a Pyboard. Display update time for the largest display is 41ms.

On SSD1351 units colours are mapped to 16-bit on the fly as the chip lacks native support for 8-bit colour. This is done in assembler. Using the standard bytecode emitter an update takes 270ms because of the overhead of this mapping. A portable driver is offered, but expect rather languid performance.

The drivers may be found in this repo.

If anyone has the 1.27 inch display and is interested in driver design there is a piece of code commented as "daft". I'd very much like to know how to set the RAM address rather than incrementing it, but all my attempts failed. It wouldn't improve performance much, but it would set my mind at rest. ;)
Peter Hinch

Post Reply