Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Porting the Slint UI Toolkit to a Microcontroller with 264K RAM

slint-ui.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM

#21

Post by duskwuff »

gijou6 wrote: post #10
ilyt wrote: post #9

It's funny to compare "modern" with microcomputers of the old. Original Amiga 500 ran with 512kB RAM, with OS requiring only 256kB (as in "you could run something other than just OS on that"). Meanwhile we have this laggy mess...

The Amiga had a dedicated video chip (and it output vga signals which are fairly cheap). This is a slow SPI bus with the cpu needing to push W x H x BPP pixels and with a 320x240 16bpp that comes out to 9 million bytes/sec for 60fps or 4.5 million for 30 fps. Cortex M0 I believe has 4 cycles for load and store, so even if you had a perfect parallel 16 bit bus where you could do 1 load + 1 store to send a pixel, that…

> with the cpu needing to push W x H x BPP pixels

Only if it needs to update the entire screen for every frame, which it probably doesn't.

> Cortex M0 I believe has 4 cycles for load and store, so even if you had a perfect parallel 16 bit bus where you could do 1 load + 1 store to send a pixel

DMA can shovel data from RAM straight into the SPI peripheral with no CPU involvement beyond the initial setup (which is simple).

Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM

#22

Post by mmoskal »

wmf wrote: post #12
KRAKRISMOTT wrote: post #8

Earlier quoted context omitted.

It's slow even with DMA. The original iPhone was snappier than this.

The original iPhone was far more powerful than this hardware.

Typically these SPI screens only work up to 50MHz (which is already way out of spec, which is often 15MHz), there is 5M bits in 640x480x16 so you won't get more than 10fps no matter what you do rendering side.

Which is why they often also offer 8 bit serial interface. I guess one can use it with the PIO on rp2040.

Edit: whoops it's only 320x240. Not sure how fast are they are running it.

Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM

#23

Post by dmitrygr »

mkj wrote: post #19
dmitrygr wrote: post #18

Forget running "a simple ui toolkit". I have ENTIRE PalmOS 5.2 running on the pico with that a screen. At 47FPS ! Feel free to hit me up for pointers. Video proof: https://photos.app.goo.gl/zZiLnDNLQs2omBXz5

Do you know what kind of ui drawing architecture PalmOS uses? Seems like it's probably more aligned with that type of device.

Software blitter. Rectangle based. To a frame buffer. It knows NOTHING about rp2040. It just writes pixels to a memory area. The rest I do with PIO and DMA. I am publishing an article in a few days on how to drive this display properly with RP2040 here: http://dmitry.gr/?r=06.%20Thoughts&proj=09.ComplexPioMachine...

Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM

#26

Post by karmicthreat »

tronical wrote: post #11
karmicthreat wrote: post #7

Does this offer me much over LVGL?

A typed and tooled (lsp, live-preview, etc) DSL for the UI and Rust/C++20 APIs, compared to C APIs.

Looks interesting, I like the online demos. I would look at using it but it doesn't look like there is a port for esp32. The lack of explicit instructions/info about getting this running with esp-idf puts a bit of a damper on it. Rust is nice, but I'm not sure how to get that working with an existing C, freeRTOS project. So while the technical parts of this seem really nice, the developer experience for someone outside of slint seems a little hard.

Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM

#27

Post by ilyt »

gijou6 wrote: post #10
ilyt wrote: post #9

It's funny to compare "modern" with microcomputers of the old. Original Amiga 500 ran with 512kB RAM, with OS requiring only 256kB (as in "you could run something other than just OS on that"). Meanwhile we have this laggy mess...

The Amiga had a dedicated video chip (and it output vga signals which are fairly cheap). This is a slow SPI bus with the cpu needing to push W x H x BPP pixels and with a 320x240 16bpp that comes out to 9 million bytes/sec for 60fps or 4.5 million for 30 fps. Cortex M0 I believe has 4 cycles for load and store, so even if you had a perfect parallel 16 bit bus where you could do 1 load + 1 store to send a pixel, that…

But it doesn't need to push every frame every second, the whole screen not always changes

> Another core wont help much because it shares the memory bus, and fill rate is the bottleneck here.

Depends on CPU, some (RP2040 for example) have segmented memory which means you can just have one core working on the graphics, and dedicate segment to DMA

Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM

#28

Post by cstrahan »

KRAKRISMOTT wrote: post #8
detrites wrote: post #2

If you get to the inlined video and think it looks a little sluggish, keep reading - they later implemented DMA to speed it up. Here's the link to this video showing it: https://youtube.com/watch?v=dkBwNocItGs

It's slow even with DMA. The original iPhone was snappier than this.

For an example of a faster demo, see my Slint backend for the Teensy MicroMod:

https://twitter.com/charlesstrahan/status/163002622435647488...

Now, admittedly, this is 600 MHz beast (the NXP i.MX RT1062). But I’d like to think it’s still impressive for the hardware involved.

As mentioned in the Twitter thread, to eke out the performance I had to implement an 8-bit parallel bus using FlexIO along with DMA (all written in Rust) — but with that implemented, the display is pretty zippy.

Re: Porting the Slint UI Toolkit to a Microcontroller with 264K RAM

#29

Post by cstrahan »

ilyt wrote: post #27
gijou6 wrote: post #10

Earlier quoted context omitted.

The Amiga had a dedicated video chip (and it output vga signals which are fairly cheap). This is a slow SPI bus with the cpu needing to push W x H x BPP pixels and with a 320x240 16bpp that comes out to 9 million bytes/sec for 60fps or 4.5 million for 30 fps. Cortex M0 I believe has 4 cycles for load and store, so even if you had a perfect parallel 16 bit bus where you could do 1 load + 1 store to send a pixel, that…

But it doesn't need to push every frame every second, the whole screen not always changes > Another core wont help much because it shares the memory bus, and fill rate is the bottleneck here. Depends on CPU, some (RP2040 for example) have segmented memory which means you can just have one core working on the graphics, and dedicate segment to DMA

Slint already supports rendering just the dirty regions of the screen. SPI is a major performance handicap though — they could use PIO on the RP2040 to implement an 8 or 16 bit parallel bus (and then they’d need a display with support for parallel IO), and that would help a ton.

Here’s Slint running on my own backend for the Teensy MicroMod (has an NXP i.MX RT1062 processor) using DMA and an 8-bit parallel bus using FlexIO:

https://twitter.com/charlesstrahan/status/163002622435647488...

I’d say that’s fairly smooth.

Post reply on HN