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

1–10 of 29 posts

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

#3

Post by sitzkrieg »

the "if we can port it to the constrained pico we can make it run on any mcu" bit made me wat. the pico is a pretty large mcu really.

i get displays are not the realm of single digit cents 4 bitters or something. but i can think of other mcus more constrained w probably still enough flash and fast enough SPI bus and dma that would be a much better showing.

i guess i feel the pico is overkill, but at any rate this is mostly unfair because its not the toolkits target market in the first place

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

#4

Post by MrBuddyCasino »

sitzkrieg wrote: post #3

the "if we can port it to the constrained pico we can make it run on any mcu" bit made me wat. the pico is a pretty large mcu really. i get displays are not the realm of single digit cents 4 bitters or something. but i can think of other mcus more constrained w probably still enough flash and fast enough SPI bus and dma that would be a much better showing. i guess i feel the pico is overkill, but at any rate this is…

Its weird they don't mention RAM and code sizes. If they require just two lines (240 x 2 Bytes x 2) thats less than 1K for the pixels, but the code size can't be that small if they compile in fonts etc.

I feel people that don't usually work mit MCUs think a Pico2040 or ESP32 is a crazy constrained environment, when those are really rather luxurious. I'm not sure how much it matters - maybe its like complaining about Elektron while Slack (deservedly) succeeds.

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

#5

Post by cryo »

The Pico runs at 133 MHz. I don't know how the slint-ui works under the hood but the shown demo (with DMA speedup) could be much more snappy imho. For that the code needs to be aligned to what the SPI protocol of the display offers instead of treating it as a general purpose frame buffer. For example while scrolling not sending the whole area but only the part which becomes visible.

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

#8

Post by KRAKRISMOTT »

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.

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

#10

Post by gijou6 »

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 comes out to a best case ~80 fps @ 100MHz with 100% cpu utilization (i.e you could do nothing else on that cpu, not even serve interrupts). Another core wont help much because it shares the memory bus, and fill rate is the bottleneck here.

There's a good reason why we have dedicated chips for pushing framebuffer -> lcd physical pixels even back in the 80s.

Post reply on HN