| 11 Jan 2024 |
 therealprof | 
Download Screenshot 2024-01-11 at 15.21.38.png | 14:23:14 |
| therealprof | The alternative would be to find the STM32F429DISCO and rewrite the example to use the GPIO display-adapter driver instead of the FSMC implementation. However that board is probably equally deep hidden in my box of shame. | 14:26:46 |
| therealprof | Oh wait, that was the STM32F413DISCO. Don't recall how the STM32F429DISCO drives the display. | 14:29:43 |
 danielb | haha I have one that acts as my logic analyzer now, that doesn't go anywhere :D | 14:30:13 |
| danielb | I've tested https://github.com/therealprof/display-interface/pull/43 with SPI and I2C. Can anyone please take a look in case I missed/messed up something? | 15:58:28 |
| danielb | In reply to @grantm11235:matrix.org
I don't personally use it with fallible pins, I just noticed the bug while reading the code I've hesitated a bit because the impact of the fix should be minimal for a slight runtime cost, but in the end it's probably the right thing to do. Thanks! | 16:19:06 |
| 12 Jan 2024 |
 GrantM11235 | The generic 'OutputBus' impls are great for prototyping, but I would encourage anyone who cares about performance to use their own custom impl that uses the PAC directly | 00:30:30 |
 Peter Hansen | In reply to @shakencodes:matrix.org
Are there any suggestions for large fonts on the embedded platform?
-- I may just use some fixed bitmap images, as I only really need numbers and a degree symbol. You could use the u8g2_fonts package, which includes some relatively massive fonts, and technically could also work with outside fonts as long as you can get or convert them into BDF format and then use their utility to encode them in the u8g2 format. | 02:53:27 |
| danielb | therealprof: I've released the main display-interface but I can't pull the trigger on SPI, I2C and Parallel-GPIO. Can you please add me to those crates, too? | 06:37:28 |
| therealprof | In reply to@bugadani:matrix.org
therealprof: I've released the main display-interface but I can't pull the trigger on SPI, I2C and Parallel-GPIO. Can you please add me to those crates, too? Sorry about that. Try again. | 07:43:06 |
| danielb | Thanks,I'll have the opportunity tonight | 07:44:36 |
| danielb | * Thanks,I'll have the opportunity tonight at the latest | 07:47:00 |
| danielb | display-interface(-spi|-i2c|-parallel-gpio) built for embedded-hal 1.0 is now live on crates.io | 18:29:32 |
 Dominic Fischer | In reply to @dominaezzz:matrix.org
I'm thinking of making a PR to improve MonoFont rendering a little bit. Specifically https://github.com/embedded-graphics/embedded-graphics/blob/30239bc88f18a9fc88a55bd83f700065c74b4501/src/mono_font/draw_target.rs#L27 .
I want to change that from a draw_iter to multiple batched calls to fill_solid. Would something like this be accepted? My display driver would really appreciate the improvement 🙂.
Made a PR anyway. https://github.com/embedded-graphics/embedded-graphics/pull/741 | 22:51:36 |
| 13 Jan 2024 |
| danielb | out of curiousity, is this a meaningful improvement? I don't have measurements, but I'm assuming that the impact on my host of SSD1306 displays would be somewhat different than what you are aiming for | 07:45:25 |
| danielb | * out of curiousity, what is your setup and what kind of improvements do you see? I don't have measurements, but I'm assuming that the impact on my host of SSD1306 displays would be somewhat different than what you are aiming for | 07:51:47 |
| Dominic Fischer | My setup is https://www.makerfabs.com/esp32-s3-parallel-tft-with-touch-4-3-inch.html + esp-idf-hal + esp-pacs. | 12:45:31 |
| danielb | wow that looks like a sweet bit of kit | 12:46:08 |
| Dominic Fischer | Yeah it's nice and compact, no wiring required | 12:47:26 |
| danielb | btw have you considered making this change on the driver level? | 12:47:40 |
| Dominic Fischer | Setting up a traditional framebuffer to for the whole screen 800x480 would take 768KB, which won't fit in the internal RAM of the device. PSRAM is an option but it's too slow and has awkward bandwidth issues. | 12:48:09 |
| Dominic Fischer | In reply to @bugadani:matrix.org
btw have you considered making this change on the driver level? I chose to DIY the driver and decided batching up draw_iter calls wasn't something display driver should have to do. The caller has the most information and should reduce the draw calls were possible. IMOP | 12:49:14 |
| Dominic Fischer | In reply to @bugadani:matrix.org
btw have you considered making this change on the driver level? * I chose to DIY the driver and decided batching up draw_iter calls wasn't something display driver should have to do. The caller has the most information and should reduce the draw calls were possible. IMO | 12:49:16 |
| Dominic Fischer | In reply to @dominaezzz:matrix.org
Setting up a traditional framebuffer to for the whole screen 800x480 would take 768KB, which won't fit in the internal RAM of the device. PSRAM is an option but it's too slow and has awkward bandwidth issues. So to fit the frame buffer in internal RAM I'm taking advantage of the linked list nature of the esp32's DMA to send the same chunk of color repeatedly to the screen. | 12:50:28 |
| Dominic Fischer | Then to render stuff for DrawTarget I just insert new descriptors pointing to a new buffer with the desired colors. | 12:51:25 |
| Dominic Fischer | Unfortunately when the draw calls are pixel by pixel the descriptors become tiny and the GDMA starts to struggle 😅 | 12:52:06 |
