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
pythoncoder
Posts: 3060
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

I2C commands

Post by pythoncoder » Tue Aug 14, 2018 7:00 am

@dhylands Have you seen PR4020? This addresses the issue of efficiently prepending a command to a buffer such that an I2C stop does not occur between command and data.
Peter Hinch

User avatar
deshipu
Posts: 1333
Joined: Thu May 28, 2015 5:54 pm

Re: Seeking display with driver subclassed from framebuf

Post by deshipu » Tue Aug 14, 2018 7:57 am

mcauser wrote:
Tue Aug 14, 2018 3:11 am
My understanding is there are 2 problems here. How much memory is required to store the entire buffer (for a 1-1 copy) and how to efficiently send the buffer over the common buses I2C, SPI and UART.
The second problem is self-inflicted and can be easily solved by adding a bit of C code to the framebuf module that will send the data efficiently. There is absolutely no technical reason why all the data needs to be in a single continuous buffer in memory, it's just a weirdness of the python api.

User avatar
deshipu
Posts: 1333
Joined: Thu May 28, 2015 5:54 pm

Re: I2C commands

Post by deshipu » Tue Aug 14, 2018 8:11 am

pythoncoder wrote:
Tue Aug 14, 2018 7:00 am
@dhylands Have you seen PR4020? This addresses the issue of efficiently prepending a command to a buffer such that an I2C stop does not occur between command and data.
This is another workaround that only solves the visible problem, but doesn't even try to get into the actual issue. It still forces you to use the same representation internally in the framebuf as the display you are driving, making it necessary to have a zillion kinds of framebufs, each with its own optimized graphical functions and its own bugs. Instead, there should be a single framebuf format for each color resolution, and the conversion to the format appropriate for a particular display should be done on the fly by the function that sends the data to the display. This way you only need to deal with different modes in one place.

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

Re: I2C commands

Post by pythoncoder » Tue Aug 14, 2018 5:20 pm

deshipu wrote:
Tue Aug 14, 2018 8:11 am
... forces you to use the same representation internally in the framebuf as the display you are driving, making it necessary to have a zillion kinds of framebufs...
I take your point. But if the only supported device is the SSD1306 we're a long way from a zillion ;)
Peter Hinch

User avatar
deshipu
Posts: 1333
Joined: Thu May 28, 2015 5:54 pm

Re: Seeking display with driver subclassed from framebuf

Post by deshipu » Tue Aug 14, 2018 11:11 pm

Last time I checked we had at least 4 different monochrome modes in there.

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

Re: Seeking display with driver subclassed from framebuf

Post by mcauser » Tue Aug 14, 2018 11:34 pm

It's actually missing MVMSB - I guess no one has needed it yet.
1-bit: MVLSB, MHLSB, MHMSB
2-bit : GS2_HMSB
4-bit: GS4_HMSB
8-bit: GS8
16-bit: RGB565

User avatar
marfis
Posts: 166
Joined: Fri Oct 31, 2014 10:29 am
Location: Zurich / Switzerland

Re: Seeking display with driver subclassed from framebuf

Post by marfis » Wed Aug 15, 2018 5:41 am

The framebuf class is able to work with multiple colours and the official SSD1306 driver is subclassed from framebuf. Are any colour displays available with drivers written in this way?
i played around some time ago with the limifrog oled display which worked well
viewtopic.php?t=2736

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

Re: Seeking display with driver subclassed from framebuf

Post by mcauser » Sat Aug 18, 2018 6:53 pm

I updated my Nokia 5110 / PCD8544 driver with examples of both inheriting and extending the Framebuffer.

Inheriting / subclassed
https://github.com/mcauser/micropython- ... inherit.py
https://github.com/mcauser/micropython- ... 8544_fb.py

Extending / wrapper
https://github.com/mcauser/micropython- ... _extend.py
https://github.com/mcauser/micropython- ... pcd8544.py

User avatar
boochow
Posts: 14
Joined: Sat Dec 16, 2017 9:36 am

Re: Seeking display with driver subclassed from framebuf

Post by boochow » Wed Aug 22, 2018 2:03 pm

pythoncoder wrote:
Mon Aug 13, 2018 9:49 am
The framebuf class is able to work with multiple colours and the official SSD1306 driver is subclassed from framebuf. Are any colour displays available with drivers written in this way?
I am using 16bit color framebuf class in my bare metal Raspberry Pi port.

demo: https://youtu.be/aUXRWUTasrY?t=1m

Since the Pi's GPU and CPU both can access to the same RAM area, all the changes CPU made to the frame buffer will be shown on the display immediately.

Raspberry Pi screen class:

Code: Select all

import gpu
import framebuf

class RPiScreen(framebuf.FrameBuffer):
    def __init__(self, width, height):
        self.width = width
        self.height = height
        gpu.fb_init(width,height,screen_w=1920,screen_h=1080)
        super().__init__(gpu.fb_data(),width,height,framebuf.RGB565)
        self
gpu.fb_init returns the pointer to an allocated frame buffer memory as a bytearray object.
The data structure of GPU frame buffer is exactly same as the one framebuf class uses, so all methods of framebuf class can be used.

A simple text console using framebuf class: https://github.com/boochow/micropython- ... Console.py

the code to show REPL on the Pi's screen using dupterm() and above classes:

Code: Select all

def set_fb_console(on=True):
    global theScreen
    from FBConsole import FBConsole, RPiScreen
    import os
    if on:
        theScreen = FBConsole(RPiScreen(480,270))
        os.dupterm(theScreen)
    else:
        theScreen = os.dupterm(None)

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

Now solved

Post by pythoncoder » Thu Aug 23, 2018 6:24 am

Trying your baremetal Raspberry Pi port is on my (long) todo list.

In the absence of colour display drivers based on Framebuf I've written one, for this display. The chip supports an 8-bit colour mode so the frame buffer is 6144 bytes which is manageable on a Pyboard. You wouldn't want to display pictures in 8-bit colour but for information displays it's OK.

It demonstrates the simplicity of basing a display class on framebuf.FrameBuffer: the driver comprises a mere 52 lines of code yet supports the graphics primitives and (via my writer module) text rendering in arbitrary fonts. All in glorious (well, 8-bit) Technicolor.

I'll post some code soon.
Peter Hinch

Post Reply