Async support?

[MabezDev]

I don't really have a concrete idea of how to implement this, but I'm just opening an issue to discuss thoughts on async support in this crate, and how it might work.

[dragonnn]

Hi! I am intested into it to, I think the first step would be to use embedded-hal-async? https://crates.io/crates/embedded-hal-async it does have an SPI and I2C traits. That should cover the bulk of what is need?

[dragonnn]

I did hack something together https://github.com/dragonnn/display-interface/commit/d96fad3b15efad55aef09032bd4c2f8705a0b871 with a SH1122 display https://github.com/dragonnn/sh1122 on a ESP32-C3 and it works. It is hacky and a huge copy and paste of the functions from blocking but it works really well. I can run a loop just constantly updating the display and when the display is flushing other tasks can do they job without any RTOS.

EDIT

Just thinking, maybe because they is an embeded-hal and embeded-hal-async we should just start a new create display-interface-async instead of putting async support into this one?

[bugadani]

I'm just guessing but extracting an async crate may not be ideal in terms of discoverability except if the crate is implemented here. Still, an async display interface (and embedded-graphics supporting it) wouldn't be a terrible idea IMO.

[therealprof]

I think a big part of the question is also where and how one would use that. Such an interface probably needs to be considered from the usage perspective. Is there any prototyping going on in embedded-graphics to provide an async interface?

Rendering asynchrously could be a very nice use case since currently it's completely up to the application to break up the work into useful work chunks to not hold up the main application for too long but finding a good interface is probably going to be a non-trivial job.

[bugadani]

Is there any prototyping going on in embedded-graphics to provide an async interface?

I'm beginning some exploration in this area in the coming weeks. My use case is simply to "asyncify" framebuffer flushes of an ssd1306 though so nothing really creative. I aim to use embedded-graphics in a device that runs embassy on an ESP32, and avoiding 100us or so flushes when the device can shovel data out using a DMA seems like a good idea.

Well, I guess this isn't exactly tied to embedded-graphics, but the device driver in my case.

[bugadani]

I don't expect embedded-graphics to start including async code without drivers supporting async operations. I don't expect async operations in drivers without a display interface that provides the basics. And I also don't expect drivers to require radically different functionality that is currently provided in display-interface, except maybe readback.

Currently, adding async draw operations to embedded-graphics would mean a lot of duplication that I don't expect anyone to do or maintain. On the other hand, there are a number of devices (ssd1306 for instance) whose drivers work with an internal framebuffer and where the user has to manually flush said framebuffer. These drivers could already benefit without changing e-g.

Where adding an async display-interface doesn't currently help is direct-to-display drawing. But I don't think this use case would be hindered, either.

All in all, changes to e-g seem to be an orthogonal problem, at least first.