Page 2 of 4

I2C commands

Posted: Tue Aug 14, 2018 7:00 am
by pythoncoder
@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.

Re: Seeking display with driver subclassed from framebuf

Posted: Tue Aug 14, 2018 7:57 am
by deshipu
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.

Re: I2C commands

Posted: Tue Aug 14, 2018 8:11 am
by deshipu
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.

Re: I2C commands

Posted: Tue Aug 14, 2018 5:20 pm
by pythoncoder
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 ;)

Re: Seeking display with driver subclassed from framebuf

Posted: Tue Aug 14, 2018 11:11 pm
by deshipu
Last time I checked we had at least 4 different monochrome modes in there.

Re: Seeking display with driver subclassed from framebuf

Posted: Tue Aug 14, 2018 11:34 pm
by mcauser
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

Re: Seeking display with driver subclassed from framebuf

Posted: Wed Aug 15, 2018 5:41 am
by marfis
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

Re: Seeking display with driver subclassed from framebuf

Posted: Sat Aug 18, 2018 6:53 pm
by mcauser
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

Re: Seeking display with driver subclassed from framebuf

Posted: Wed Aug 22, 2018 2:03 pm
by boochow
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)

Now solved

Posted: Thu Aug 23, 2018 6:24 am
by pythoncoder
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.