Request for framebuffer access in Inky Frame 7.3

[dvankley]

I just got a shiny new Inky Frame 7.3! Whilst reading the docs, I was sad to discover it does not yet support the framebuffer shenanigans I've come to know and love.

This issue is my means of requesting the "hardfault handling sorcery" mentioned in that doc and keeping up to date on the status of it.

Thanks!

[qpincon]

I created a gist explaining how I did to circumvent the issue in case someone is interested

[Gadgetoid]

It's possible to read directly from the PSRAM without any special magic, but the larger problem is finding some way to express that in MicroPython since the memoryview interface PicoGraphics uses to make the buffer accessible expects ... memory... and doesn't facilitate - as far as I know - any way to fake memory by providing your own IO functions. The hardfault stuff is simply too weird to rely upon.

It's actually my preference, and this sounds bonkers but bear with me, to somehow provide filesystem access to the PSRAM. I don't think this really lets you do framebuffer tomfoolery nicely, but it would be amazing for the kind of temporary storage, cache or buffers you might need for network-related tasks. There's a whole 8Mbit of PSRAM just sitting around, of which we use a paltry 192k (1/5th if I'm not losing my mind).

I suppose in defence of hardfault, having an extra ~800k of even slow memory could be useful for the leisurely pace at which Inky updates, but getting it to work nicely in MicroPython is probably going to be an ordeal.

[Redsandro]

Is there an update in the prognosis for this? Still planned or impossible?

I recently got an Inky Frame 7.3 to replace my Inky 5 precisely because the memory is too tight. I have recently discovered this trick and find it hard to look back. :slightly_smiling_face:

[Skyler84]

Regarding the hardfault tomfoolery, I had a look at Yocto8 pico extmem hardfault and made an attempt to build this code independently but didn't have any success, so I thought I'd take a shot at writing a standalone library to handle the hardfaults and emulate the memory accesses (WIP) Skyler84/pico_extmem. The library is still in very early days and I don't expect it to be usable properly for a few weeks, however to give a vague idea of performance - reads/writes ~2-3MB/s best case (all reads/writes to same location using cached memory interface) , 400KB/s worst case (no caching, reading SPI 33.5Mbaud)

Using with uPython

in its current state, I'm not sure that there's a simple way for uPython to use the external memory directly. I do however like the idea of a tmpfs or similar that is backed by the PSRAM, or another class that allows creating buffers in it directly. This would avoid the need of a hardfault handler which is slow and a whacky way of doing things.

If the PSRAM was to be used by uPython, it would probably need a second allocator/GC and a port specifically for the PSRAM hardfault handler, as that would require changes to the linker script most likely. It would also need a way to decide whether to allocate objects in fast RAM or slow external PSRAM, which is not in the scope of uPython realistically.

Basically, I'm happy to contribute code to make this happen and take ideas, I just don't know what people think would work best at the moment!

[Gadgetoid]

The hardfault stuff is, indeed, a very weird way to accomplish what we want here.

I do wonder if MicroPython objects which accept a buffer would play nicely with a buffer backed by PSRAM. That is to say, rather than allocating RAM the standard way for PSRAM backed data, you would allocate a buffer via a special constructor, and that buffer interface would handle IO to PSRAM transparently.

The caveat being this would work only for methods and classes that support buffers. This might include stuff like file IO, network transfers and so on and - I think - you could pull slices of that buffer into "fast RAM* if you need to do anything particularly intensive with them. So it strikes me that it would still be useful in the general sense (IE: even beyond Inky Frame) and would also solve the specific case of getting at PicoGraphic's framebuffer from user code.

Fundamentally PicoGraphics, and thus InkyFrame, is incompatible with standard Python buffers, though, we really dug ourselves in chasing performance. I don't think this would really matter if the user is modifying the buffer behind its back, though.

I can ask if we have any of our PSRAM boards left floating about. We made a batch before realising they probably weren't going to be all that popular/useful since using them is hard.

[Skyler84]

I can ask if we have any of our PSRAM boards left floating about. We made a batch before realising they probably weren't going to be all that popular/useful since using them is hard.

One gripe i have with the Inky Frame 7.3 is how the PSRAM is connected. While the 4 spi pins are wired up, it looks virtually impossible to use them in QSPI mode due to them not being sequential. In a future version, if possible it would be amazing if they were sequential so we could use PIO to drive thi QSPI and that would 4x the throughput. Maybe these PSRAM boards you mention are connected like this instead?

[Redsandro]

Just a heads up, although not strictly relevant for this feature request:

1. In the last year, Inky has gotten PNG support.
2. The Inky 7.3" actually has enough memory to use it for big images.

It may help out some projects in the meanwhile.

[dvankley]

At the end of the day, the reason I adopted the "writing to the framebuffer directly" approach was because I wanted to do the dithering myself beforehand for increased quality and decreased power use. Are there any other workarounds to accomplish that at this point?

[Redsandro]

Same as before, except write to PNG file in stead of raw binary file in the case of Inky 7.3".