Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[request] Embedded GUI #13

Open
puzrin opened this issue Mar 27, 2019 · 7 comments
Open

[request] Embedded GUI #13

puzrin opened this issue Mar 27, 2019 · 7 comments

Comments

@puzrin
Copy link

puzrin commented Mar 27, 2019

No GUI, suitable for embedded use on small SOC-s

Currently there are no complete solutions, suitable to create modern interfaces on "small" devices (like 8-16K RAM + 64-128K Flash).

Targeting

I'd suggest to focus on "small" systems like stm32f0-stm32f4 with colour displays up to 320*200.

Reasons:

  • "Big" embedded systems, where linux available, can run restricted versions of QT and other "desktop" libs.
  • Hardware should be simple enough, to order via EasyEDA and assemble manually. I mean, primary focus on chips like TQFP64 and below, without external DRAM.
  • Displays 320*200 is almost maximal size to have 25FPS with SPI. Bigger displays usually have more powerful hardware => shift to linux-based solutions.

That's only examples, to explain range of devices, where hardware already CAN run modern GUI, but no appropriate software available. Of cause, you can find lot of exclusions, but reason of GUI request is to fill gap, not to compete with existing libs.

Specifics of hardware restrictions

  1. No memory space for full display buffer (320*240*16bpp). This is solved by multi-pass rendering, when buffer size is 1/20 of screen area.
  2. No resources (primary - RAM) for TTF (vector) fonts. Bitmap fonts used.
    • Related: there are some solutions to convert font from TTF, but those do not support good compression. Appropriate tools required.
  3. No GPU. As a result - no need to have abstraction layer for appropriate draw commands. It's enough for driver to support region copy only.

UX/look

Most of existing GUI-s try to invent own look instead of following one of existing guideline. Result is very poor. IMHO something like Material Design is "minimal possible quality requirement".

PC emulator

When you do simple device, it's not difficult to code "meat". The most time-consuming task become interface polishing. It's not convenient to do such things on bare metal. Having PC emulator of display/touch will speed up development significantly.

Success criteria

Ideally, it would be nice to have GUI, able to create Material Design interfaces on SOCs with 8-16K RAM and 64-128K flash.

  1. GUI core. To not fall into technical details - something like LittlevGL.
  2. Tool to convert TTF fonts to bitmap fonts, with subsetting and RLE-like compression.
  3. Demo with "Settings menu". A lot of small devices can be described as "Main screen + settings". Having demo with good design will help a lot to quick-start.
  4. PC emulator (driver), easy to install on major platforms.

References

This chapter replaces "Work in Progress" because referred things are not for rust. But those have a lot of reusable things, and should save a lot of time.

  • LittlevGL - example of nice GUI for C. It's not ideal due C restrictions, but worth to check instead of reinvent all from scratch.
  • lv_font_conv - WIP, see dev branches & issues. Fonts convertor + area to experiment with compressions. It's written in JavaScript for LVGL, but with keeping in mind to be reusable for Rust.
  • Settings menu screenshots - how modern settings could look.
@rafaelcaricio
Copy link

Hi,

I just found this issue and I find it very interesting. A couple of weeks ago I started creating LittlevGL (LVGL) bindings for Rust.

https://github.com/rafaelcaricio/lvgl-rs

The project is still in very early stages. A lot of polishing is still necessary as I'm figuring out the best design for the API.

lvgl-rs highlights:

  • Built upon the embedded_graphics traits, making it compatible with any display drivers.
  • Desktop simulator, you can run your GUI apps in your computer and then use the same GUI code in your embedded project.

I've shared the lvgl-rs project with the folks that created and maintain LVGL and we are exchanging some ideas on how to speed up the process of creating the bindings. I don't have a timeline for when it will be completed as this is a project I develop in my free time. However, I'm open to accepting pull requests and feedback about the project in general.

lvgl-rs seems to be exactly what you are looking for. Let me know what you think.

@puzrin
Copy link
Author

puzrin commented Jun 7, 2020

@rafaelcaricio

lvgl-rs seems to be exactly what you are looking for. Let me know what you think.

At current moment i use lvgl directly, and don't like use it via bindings. While still the best of available in current moment, lvgl has some controversial architecture decisions, no tests, no benchmarks and so on. IMO, for awesome result, it would be more simple to write native GUI in rust from scratch.

@xgroleau
Copy link

Just FYI, there is slint-ui which can run on embedded. It also comes with an emulator using webassembly and respects most of the criteria. They already have examples using embedded-graphics and can render by line instead of the full frame buffer so it can easily fit in ram. Note that the project is GPL and not MIT/Apache though so it may be incompatible with some projects.

@puzrin
Copy link
Author

puzrin commented Oct 24, 2022

@xgroleau from readme: "Slint apps can run on MCUs with less than 300K of RAM."

That's out of expected for small MCU-s.

@xgroleau
Copy link

xgroleau commented Oct 24, 2022

@puzrin You definitely don't need the full 300kb of RAM to use it. I've used it successfully with an nrf52840(192kb of ram with the softdevice)while allocating only 24kb of heap for slint (I haven't checked usage). Now obviously consumption vary on the number of components. It's ram usage seems similar but a little higher than lvgl for a similar UI. It does seem to use more flash space though.

@ryankurte
Copy link

i think this is subsequently also fairly well covered by embedded-graphics ^_^

@puzrin
Copy link
Author

puzrin commented Oct 24, 2022

That's not GUI at all, just a shapes drawer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants