For 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.
On an instrustial machine I worked on we got around this by hosting a node.js website on a Linux touch screen panel. There was a redis cache which was updated by a small python script that communicated with the embedded stuff via a serial interface.<p>If you have the budget for it, this is a great architecture since creating a website GUI is much easier than an embedded GUI. Also, you could very easily pull up the machine control panel remotely from any web browser (with proper remote vs local security enabled of course).
On the contrary, I find writing embedded GUIs enjoyable. Sure, it's harder, but also very rewarding. You need an event queue, so you can handle internal and external events the same way. The rest is "just" programming.
I think this is mostly a problem of finding good tools for your workflow. Admittedly, there are fewer of them in the space of embedded development than for the usual "apps", but there <i>are</i> some. Besides the already mentioned LVGL [1] for the actual GUI you'll need a proper build tool that can handle all that conversion stuff OP's talking about reliably. I can only recommend Bob [2] here. Unfortunately, it's very unknown but brings everything you need for embedded development (w/ or w/o GUI, higher-level stuff like custom Linux images, too). Using it for years professionally and for personal projects and will never look back.<p>[1] <a href="https://lvgl.io" rel="nofollow">https://lvgl.io</a>
[2] <a href="https://bobbuildtool.dev" rel="nofollow">https://bobbuildtool.dev</a>
A 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.
That 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.<p>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.<p>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.<p>I'm watching this library recently: <a href="https://github.com/peterhinch/micropython-micro-gui" rel="nofollow">https://github.com/peterhinch/micropython-micro-gui</a><p>It seems promising to solve many of the common issues that you get, once you move from simple static information display.
I 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!
I recently built a machine with a couple of beams, a Hall effect switch, heater, thermocouple and a couple of badass stepper motors with external controllers.<p>Wrote my whole stack in C# / Winforms and deploy to a Mono running on a Raspberry Pi 4.<p>UI runs on main thread and is purely viewing and event generation. On a background thread, I have a homegrown cooperative multitasking state machine driven kernel that handles all interaction with the machinery. Works awesome. Plenty of CPU to spare. And event response is < 5ms typically, which is based on the timer interval.<p>Only two downsides, only printf debugging. I gave up after a couple of days of following SO and various tutorials on how to get the remote Mono / .NET debugger working. Maybe if I switch to WPF…but I avoided that because the Interface Designer for VS was half-baked (and sucked) at the time.<p>Second downside, some weird point map scaling variation between the Interface Designer and Mono placing with the window under the WM. I worked around by incorporating a build script to parse the source of the form and write out an initialization routine to fix the size and location of all screen elements. It’s definitely sketchy but it works.<p>The end result says it all though. My UI and responsiveness beats the snot out of machines we’ve spent multiple $100K on that run Win Embedded + PLC architecture.
Unless the use cases are very simple or there's a special reason not to for most embedded devices I think I'd rather communicate largely with an app (e.g. by bluetooth).<p>I'm thinking for washing machines, dishwashers, aircon, things like that.<p>Unless simple, embedded UIs are usually bad and usually make complex interactions (e.g. setting timers) especially horrible. Whereas android/apple/the web have been optimized for UX.<p>It's oddly not as common as I'd have expected, though.
We've done real-time JavaScript UIs for several projects where the hardware is slick enough to host a REST API or a WebSockets server. It's worked well, making it easy to access devices from a kiosk browser or remotely. It also enables communication between devices across the same API layer, and by decoupling the UI from the application and control planes, it allows us to iterate super quickly with familiar tools.
I'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.
Please just stop!<p>There is one area where gadgets and appliances are the most cumbersome to use, and that is their electronic UI. They have always been terrible (eg programming VCRs).<p>Graphical UIs won't make them better.<p>And all those screens and buttons will be the first things to fail, will be very hard to source replacements for, and will be too expensive to bother repairing anyway, not to mention, an expensive addition to The Thing in the first place.<p>Please, just add a bluetooth LE interface, and a web app, for control and programming with cheap, ubiquitous, and designed-for-UI mobile phones, and open-source it.<p>The Thing itself should only have the most minimal physical interface, eg on/off button and led. Keep the embedded mcu (and embedded programmers) for low-level device control mechanisms and some policy enforcement for safety.
I agree with him that Renode is by far the best tool around. But I haven't yet managed to add support for my boards yet. Neither to qemu ditto. Renode has much more boards supported than qemu though.<p>Also, lvgl is a very good toolkit.
Depends 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.
I can imagine a generic smartphone app that has configurable UI and is designed to talk to serial devices over BLE. Add a BLE module to your IoT, send a json config to this app, and away you go!
my takeaway from the article is I hope OP isn't responsible for that lag fest of an animation[0]. I hate embedded stuff that takes ages to animate while the hardware obviously just can't handle it. Skip the animation, and just make it snappy, damn it! There's nothing more infuriating than a slow interface that makes you wait needlessly.<p>[0] <a href="https://blog.benjamin-cabe.com/wp-content/uploads/2021/10/renode-guix.webm" rel="nofollow">https://blog.benjamin-cabe.com/wp-content/uploads/2021/10/re...</a>
So how many embedded GUIs did the author actually write?<p>He seems to have compiled an arbitrary list of 'hard things' or 'problems you may encounter'. But these are presented so shallow, I find it hard to believe he ever struggled with them.<p>Although he seems to push the opensource Renode at the end, I feel it is mostly an Azure submarine.