extmod/modframebuf: Additional colour modes and endianness handling
There have been some PRs for additional modes for modframebuf (XRGB, RGB, VMSB), as well as clarifying the way the framebuf interacts with the host and target-display endianness (which means adding additional BE/LE modes).
#3536 -- Endianness handling for RGB565 framebuf mode.
#3551 -- extmod/modframebuf: add 24bit RGB support (RGB888)
#4880 -- extmod/modframebuf: add XRGB8888 format
#4887 -- Add support for MSB vertical mode
It's worth noting that although most MicroPython boards are unlikely to have enough RAM for an XRGB/RGB framebuffer for all but the smallest LCD/OLED displays, they are potentially very useful for things like APA102 and WS2812 LED strips,
Each new mode adds code size, and this code size affects all ports/boards that include modframebuf (most of them!). Rather than splitting this across four PRs, it would be good to consolidate (and possibly consider alternative approaches).
Some ideas for areas to investigate:
- Implement modes more (code-size) efficiently (possibly at a speed tradeoff)
- Making modes dynamic (i.e. via the dynamic native module mechanism) or even make framebuf not part of the core firmware and always used as a dynamic module (need a way to run .mpy files out of flash though).
- Other colour-related improvements to framebuf (i.e. blit to a framebuf with a different colour mode, possibly supplying a palette - see #2973).
Endianness handling for RGB565 framebuf mode.
The current behavior uses the CPU endianness, which I found surprising:
b = bytearray(2)
f = framebuf.FrameBuffer(b, 1, 1, framebuf.RGB565)
f.fill(0xabcd)
print(b) # bytearray(b'\xcd\xab')
I would expect that to result in bytearray(b'\xab\xcd'). The RGB565
OLED that I'm using needs the bytes arranged big-endian, so currently
this means pushing the endianness-handling to the user of FrameBuffer.
This commits retains the existing behavior for backwards-compatibility
but adds two new modes RGB565_BE and RGB565_LE to allow the user
to explicitly set the behavior. The existing RGB565 will use
whatever the CPU endianness is.