I dread writing embedded GUIs
blog.benjamin-cabe.com
I dread writing embedded GUIs
1–10 of 58 posts
Re: I dread writing embedded GUIs
#2Depends on the kind of embedded you're talking about. On Raspberry PI, Odroid and similar devices Qt works pretty well and it's much less pain than specialized embedded systems and UI libraries.
Re: I dread writing embedded GUIs
#3I suppose I'll be the outlier here, but on more powerful devices like Raspberry Pi or other Cortex-based devices, I have had good luck using LispWorks and their CAPI UI library. Plus, Lisp!
Re: I dread writing embedded GUIs
#4Depends on the kind of embedded you're talking about. On Raspberry PI, Odroid and similar devices Qt works pretty well and it's much less pain than specialized embedded systems and UI libraries.
Do you configure Qt to draw direct to the framebuffer or just use XOrg and/or Wayland?
Re: I dread writing embedded GUIs
#5I've written quick and dirty GUIs in Racket on the Raspberry Pi 4 and 3. I've found the 1gb memory on the PI3 with an editor open, Raspbian running, and a pdf, I have about 300mb free for another app. It can be a little tight with a 150-175mb Gui written in Racket, but on a 2gb PI4 the extra breathing room helps a lot.
Re: I dread writing embedded GUIs
#6A better hardware architecture for running a gui with some real-time requirements is often to move the real-time stuff into a separate microprocessor entirely. I’ve run into some tricky problems trying to do both on the same core, as you have zero control over when the UI will suddenly start consuming more resources, and it becomes a game of whack-a-mole to keep your ui responsive without overtaxing your event loop. I think this is one reason TI put a Cortex M processor on die with the AM335X. It enables you to offload your real-time logic onto a separate processor and dedicate hardware control to that so the main application processor could focus on rendering and responding to user inputs.
Re: I dread writing embedded GUIs
#7That post really resonated with me. I attempted making my own ESP32-based remote for controlling my media centre while I'm in my kitchen, or generally away from my laptop.
The nature of embedded with interrupts (e.g. from buttons) and trying to mix in MQTT events and nice multi-layered UI made me completely question my programming abilities.
I really wanted to have modals/pop-ups (e.g. to show current volume on change) and it ended up so messy. Not only it is about control flow but about memory too (as the author mentioned). I couldn't just store a stack of "screens" to fall back to.
I'm watching this library recently: https://github.com/peterhinch/micropython-micro-gui
It seems promising to solve many of the common issues that you get, once you move from simple static information display.
Re: I dread writing embedded GUIs
#8For small systems, LVGL address all of these pain points. It works well with small amounts of memory, maintains a responsive, animatable UI that works over slower display interfaces, and is easy to port with only a small amount of driver code needed to get up and running.
Re: I dread writing embedded GUIs
#9I suppose I'll be the outlier here, but on more powerful devices like Raspberry Pi or other Cortex-based devices, I have had good luck using LispWorks and their CAPI UI library. Plus, Lisp!
Don't want to put words in anyones mouth, but if it runs linux, it's probably not what the author was talking about. Hence Arduino rather than rpi
Re: I dread writing embedded GUIs
#10For small systems, LVGL address all of these pain points. It works well with small amounts of memory, maintains a responsive, animatable UI that works over slower display interfaces, and is easy to port with only a small amount of driver code needed to get up and running.
I second that. After decades of rolling stuff by hand I recently did a project based on LVGL. It's highly configurable, easy on the resources, properly documented and all. I had some troubles with getting the layout to do what I want, but with the latest release that has been solved with the new CSS-like layouting mechanism.
Recommend, would use again.