8 Jan 2025 |
| badrb changed their profile picture. | 23:58:26 |
11 Jan 2025 |
almindor | are there/what are plans for async and embedded-graphics? | 20:37:11 |
jamwaffles | There were some murmurings but IIRC the conclusion was something along the lines of it not making much sense for e-g itself to be async because the bottleneck is in data transfer to the display | 20:44:41 |
almindor | hmm, so how do people who use say embassy go around this? they just use blocking version of display drivers ? | 20:57:35 |
Starfighter | Most executors have ways to call blocking code.
On my project I am using core 0 of the rp2040 to run the executor and core 1 is running normal blocking code to render to the screen, effectively splitting the load between a system core (async) and an application/rendering core (sync). | 21:03:47 |
almindor | hmm, so this would imply then that implementing async display drivers is a waste of time then | 21:06:08 |
almindor | I mean you gain async SPI calls for example, but you lose e-g so why bother | 21:06:22 |
jamwaffles | Most display drivers use a buffer so you can have both async and sync, like
let mut disp = SomeDisplay::new();
Rectangle::new().draw(&mut disp);
disp.write_spi().await;
| 21:08:19 |
jamwaffles | Which gives the best of both worlds (whilst paying some RAM for the buffer) no? | 21:08:37 |
almindor | ah, most MCUs I had didn't have enough RAM for a full screen buffer :D | 21:08:58 |
jamwaffles | Ah yeah then things get weird and difficult lol | 21:11:20 |
jamwaffles | You could iterate over the points produced by an e-g shape and write them in chunks/one by one to the display but there are difficulties in doing that as opposed to just having a framebuffer | 21:12:08 |
almindor | I guess the easiest implementation really is to just make the user provide a buffer and implement e-g by writing to the buffer in a sync manner | 21:19:35 |
almindor | how do you differentiate between "needs flush" and "direct rendering once e-g calls are made" though? | 21:19:53 |
almindor | I mean it seems to me then that the driver decides this and the user might not even know what the behavior is? | 21:20:09 |
dngrs | I just published easing-fixed for no-std fixed-point easing animations | 22:19:21 |
dngrs | (or anything that needs easing, really) | 22:19:42 |
jamwaffles | That's bloody brilliant, nice work! | 22:53:31 |
dngrs | thank you! | 22:53:51 |
birdistheword99 | In reply to @almindor:matrix.org hmm, so how do people who use say embassy go around this? they just use blocking version of display drivers ? I don't know if it's any help to you, but I wrote an async driver for the ssd1322, which when combined with something like Embassy's SPI implementation allows you to use DMA to do the heavy lifting. It has a basic screen buffer to go with it but obviously you would need an MCU with enough space for a fixed buffer, as jamwaffles: said. | 23:11:47 |
birdistheword99 | Of course you can still use DMA without async but async kinda suits this sort of thing, and it's nicer to read | 23:12:05 |
birdistheword99 | There is an existing ssd1322 crate which uses an iterator to do chunked loading, which massively minimises memory overhead, but at the cost of performance/throughput. Different requirements lead to different solutions:) | 23:14:33 |
dngrs | yeah, I guess DMA is one of the reasons to have async drivers in the first place | 23:20:55 |
dngrs | and/or, well, it obviously gels better with embassy peripherals, even if the underlying transfers don't use DMA | 23:25:32 |
dngrs | the code duplication can get sad tho | 23:26:12 |
13 Jan 2025 |
dngrs | released an update:
- added
smoothstep
- you can now directly call e.g.
ExpInOut::at(t, from, dist) or ExpInOut::at_normalized(t) if you don't want to use the iterators 😬
| 02:43:17 |
dngrs | * released an update:
- added
smoothstep
- you can now directly call e.g.
ExpInOut::at(t, from, dist) or ExpInOut::at_normalized(t) if you don't want to use iterators 😬
| 02:43:52 |
23 Jan 2025 |
| Bunbury set a profile picture. | 07:00:08 |
| Bunbury changed their profile picture. | 07:14:51 |
| "Ody Bhoja" changed their profile picture. | 08:54:01 |