!SfJCDXZbMHXkPovtKL:matrix.org

Rust Embedded Graphics

186 Members
Help and chat for embedded-graphics and the wider embedded Rust graphics ecosystem | https://github.com/embedded-graphics/embedded-graphics | https://crates.io/crates/embedded-graphics18 Servers

Load older messages


SenderMessageTime
19 Sep 2022
@jamwaffles:matrix.orgjamwaffles * 🎉 version 0.4.0 of https://crates.io/crates/embedded-graphics-simulator just released. No changes other than bumping MSRV to 1.61.10:09:04
@xgroleau:matrix.orgxgroleauHi, I've never really used spi displays before, what is the speed to expect using only one data lane? It currently takes about 950ms to send a 240x240 image on the st7789 (rg565) with a 32MHz clock using display_interface_spi and mipidsi, is that the approximately expected time?21:04:11
@xgroleau:matrix.orgxgroleau * Hi, I've never really used spi displays before, what is the speed to expect using only one data lane? It currently takes about 900ms to send a 240x240 image on the st7789 (rg565) with a 32MHz clock using display_interface_spi and mipidsi, is that the approximately expected time? 21:04:26
@therealprof:matrix.orgtherealprof
In reply to @xgroleau:matrix.org
Hi, I've never really used spi displays before, what is the speed to expect using only one data lane? It currently takes about 900ms to send a 240x240 image on the st7789 (rg565) with a 32MHz clock using display_interface_spi and mipidsi, is that the approximately expected time?
Sounds a bit slow. If you have a 32MHz clock and and you can fully saturate it, you should be looking at a datarate of 32Mbit/s. With a 565 encoding you're looking at 2Mpix/s. 240x240 are only 57600 pixels. Ideally you should be able to render 34.7 fps or a 28.8ms time per frame.
21:11:24
@xgroleau:matrix.orgxgroleauHmmm that is what I though, though the code is not very complicated so I don't understand what could cause such a bottleneck.21:17:13
@xgroleau:matrix.orgxgroleauI think the nrf52 has a limit to it's dma buffer of 512 bytes, so it probably does multiple transaction, but it shouldn't have such an impact21:17:53
@therealprof:matrix.orgtherealprofThe issue is usually not the data transfer itself but getting the data over to the peripheral. I'd probably check for the efficiency of the data generation; it's likely you're bound by calculation speed.21:19:59
@therealprof:matrix.orgtherealprofIt's nice that DMA gives you the transfer for almost free if the MCU takes multiple times of the transfer to generate the pixel data. 😉 21:23:25
@xgroleau:matrix.orgxgroleauBy data generation, do you mean the parsing of the TGA/BMP data? The image is directly in ram using include_bytes! macro, the data is not generated at runtime21:25:24
@xgroleau:matrix.orgxgroleau
In reply to @therealprof:matrix.org
It's nice that DMA gives you the transfer for almost free if the MCU takes multiple times of the transfer to generate the pixel data. 😉
God yes, rust is so much nicer to use, gone are the days to manually do the dma using platform specific interrupts in C
21:26:03
@therealprof:matrix.orgtherealprofHow is the data rendered onto the screen? It sounds unlikely you have multiple decoded 57600px images in RAM. 😉 21:27:21
@xgroleau:matrix.orgxgroleau I'm using tinytga, though even sending a solid color using display.clear(RPB565::GREEN) is about 900ms. I can see the line drawing over the screen :/ 21:32:51
@xgroleau:matrix.orgxgroleau * I'm using tinytga, though even sending a solid color using display.clear(RGB565::GREEN) is about 900ms. I can see the line drawing over the screen :/ 21:32:59
@therealprof:matrix.orgtherealprofOuch. Yeah, that doesn't sound right. Is clearing with a black screen much faster or the same?21:35:12
@therealprof:matrix.orgtherealprofAnd just double checking, you're building in release mode, right?21:35:59
@xgroleau:matrix.orgxgroleauI was in debug, just, though in release it's about 10ms faster, so nothing ground breaking, same time for black instead of green21:39:03
@xgroleau:matrix.orgxgroleauI'm using embassy, but I've never had issue with it's spi driver before21:40:21
@xgroleau:matrix.orgxgroleau The code is actually pretty simple. I'll try to check via a logic analyser 21:45:35
@xgroleau:matrix.orgxgroleaunvm the only the spi3 can go to 32mhz22:01:41
@xgroleau:matrix.orgxgroleaui'm getting 80ms for full black screen and 210ms on actual 32mhz, makes more sens but still a bit short on speed. probably a config problem on my side, sorry about that22:05:25
@grantm11235:matrix.orgGrantM11235Do you have LTO enabled?23:04:14
20 Sep 2022
@therealprof:matrix.orgtherealprof
In reply to @xgroleau:matrix.org
i'm getting 80ms for full black screen and 210ms on actual 32mhz, makes more sens but still a bit short on speed. probably a config problem on my side, sorry about that
No worries. Don't forget that even just copying the data to the DMA buffer will also take significant resources and the nRF chips have rather pedestrian clockspeeds. 80ms for a full black frame is within my expectations. If you want to go high speed rendering you will need to find a way to do partial updates/draws.
06:10:52
@xgroleau:matrix.orgxgroleau
In reply to @therealprof:matrix.org
No worries. Don't forget that even just copying the data to the DMA buffer will also take significant resources and the nRF chips have rather pedestrian clockspeeds. 80ms for a full black frame is within my expectations. If you want to go high speed rendering you will need to find a way to do partial updates/draws.
I will definitely do partial renders, it was mostly just for a demo and benchmark. Otherwise it's a really easy library to use and the ecosystem is way more complete than I expected!
10:58:11
@jamwaffles:matrix.orgjamwaffles
In reply to @therealprof:matrix.org
epd-waveshare supports this: https://www.waveshare.com/5.65inch-e-paper-module-f.htm
If you were curious, it looks like it's 3bpp, but transmitted as 4bpp with the upper bit ignored, e.g. 0xxx0#### for 2 pixels.
13:49:27
@jamwaffles:matrix.orgjamwaffles
In reply to @therealprof:matrix.org
epd-waveshare supports this: https://www.waveshare.com/5.65inch-e-paper-module-f.htm
* If you were curious, it looks like it's 3bpp, but transmitted as 4bpp with the upper bit ignored, e.g. 0xxx0### for 2 pixels.
13:54:02
@therealprof:matrix.orgtherealprof
In reply to @jamwaffles:matrix.org
If you were curious, it looks like it's 3bpp, but transmitted as 4bpp with the upper bit ignored, e.g. 0xxx0### for 2 pixels.
Hooray? 😉
14:36:51
23 Sep 2022
@suizo:matrix.orgMartin changed their profile picture.11:52:21
24 Sep 2022
@finomnis:matrix.orgFinomnis changed their display name from finomnis to Finomnis.10:15:52
@almindor:matrix.orgalmindorMipidsi also batches fills by default but the batch sizes are small. If you have ram you could try making that bigger.15:00:01
@mryalamanchi:matrix.orgMr. Yalamanchi joined the room.20:44:19

There are no newer messages yet.


Back to Room List