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

I dread writing embedded GUIs

blog.benjamin-cabe.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: I dread writing embedded GUIs

#31

Post by bruce343434 »

kartben_ wrote: post #24
bruce343434 wrote: post #20

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. [0] https://blog.benjamin-cabe.com/wp-content/uploads/2021/10/re...

OP here :) That animation is laggy on the Renode emulator (at the moment at least), but definitely snappy and 30fps on the real HW...

ah, good to hear! In that case act as if I said nothing :)

Re: I dread writing embedded GUIs

#33

Post by LeifCarrotson »

roland35 wrote: post #21

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. 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 mach…

Similar things happen on every industrial machine. Typically, it's a VxWorks-based PLC (implementation detail, never ever exposed to the end user) and a Windows CE touchscreen HMI. It is remarkable, though, how much this separation makes sense.

You end up with some ancient 68000 or PowerPC processor running all the performance-critical logic with - if you're lucky - a megabyte of SRAM. It's expected to hit one millisecond scan times every single millisecond for ten years straight. And it does so, until you miss your SRAM battery maintenance interval or drive a forklift through the panel; it will probably keep running through any lesser hiccup.

The PLC communicates over that serial interface (or an Ethernet socket which emulates a serial interface) with the HMI, which probably has a multicore x86 CPU and literally a thousand times more memory. It runs a pared-down desktop operating system. It's not made to hit one-millisecond scan times, it probably has visible lag while merely changing the background color of an indicator. Good luck creating a usable GUI with the IDE, which might be decades old.

An Arm Cortex microcontroller for the embedded system, and a Linux touchscreen displaying a NodeJS website would be a convergent way to develop such a machine if you didn't have 50 years of legacy code and trundling along behind you....

Re: I dread writing embedded GUIs

#34

Post by IshKebab »

roland35 wrote: post #21

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. 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 mach…

If you can install Linux on your device you won't have any of the problems he is talking about. He's talking about microcontroller GUIs.

Honestly running a node.js website with a Redis cache and a Python script for an embedded GUI sounds like a completely insane and fragile mess!

Qt or Flutter are clearly the best options for embedded touchscreen devices where you can run Linux.

Re: I dread writing embedded GUIs

#35

Post by roland35 »

IshKebab wrote: post #34
roland35 wrote: post #21

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. 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 mach…

If you can install Linux on your device you won't have any of the problems he is talking about. He's talking about microcontroller GUIs. Honestly running a node.js website with a Redis cache and a Python script for an embedded GUI sounds like a completely insane and fragile mess! Qt or Flutter are clearly the best options for embedded touchscreen devices where you can run Linux.

My point was at a hardware cost it may save you software development cost by adding a Linux machine to an otherwise embedded platform

Re: I dread writing embedded GUIs

#36

Post by CamperBob2 »

pydry wrote: post #19

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). I'm thinking for washing machines, dishwashers, aircon, things like that. 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 f…

It's oddly not as common as I'd have expected, though.

If you put Apple on your hardware product's critical path, they may capriciously change their app store rules at some point to invalidate your whole product or business model.

If you put Google on your hardware product's critical path, they may just get bored of supporting whatever Google product(s) you are using, and kill your whole product or business model without even realizing they're doing it.

These companies should be treated as forces to be reckoned with, not (just) as friends to partner with.

Re: I dread writing embedded GUIs

#37

Post by wildrhythms »

wvenable wrote: post #26
bruce343434 wrote: post #20

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. [0] https://blog.benjamin-cabe.com/wp-content/uploads/2021/10/re...

The coffee machine at the office has the laggiest animated interface and as a software developer it's just painful. They have complete control over the hardware and software so there is just no excuse.

What do you think happened there? Did the decision-makers never try using the product before it was manufactured? Were the stakeholders shown the "final product" on some high-powered prototype device?

Re: I dread writing embedded GUIs

#38

Post by CodeWriter23 »

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.

Wrote my whole stack in C# / Winforms and deploy to a Mono running on a Raspberry Pi 4.

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 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.

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.

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.

Re: I dread writing embedded GUIs

#39

Post by jacknews »

Please just stop!

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).

Graphical UIs won't make them better.

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.

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.

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.

Re: I dread writing embedded GUIs

#40

Post by wvenable »

wildrhythms wrote: post #37
wvenable wrote: post #26

Earlier quoted context omitted.

The coffee machine at the office has the laggiest animated interface and as a software developer it's just painful. They have complete control over the hardware and software so there is just no excuse.

What do you think happened there? Did the decision-makers never try using the product before it was manufactured? Were the stakeholders shown the "final product" on some high-powered prototype device?

The interface is very attractive -- high-resolution pictures of the various coffees, nice fonts, and a clean design. My guess is that graphic designers designed the images and interactivity without any considerations of performance. Then that design was given to developers to be shoe-horned into a machine not capable of handling it.

Possibly different teams contracted out to do both jobs. The design is done by one team, finished, and then handed off to the next.

I'm sure the interface could be tweaked (remove some animations, lower the resolution, etc) to make it usable but instead there was a complete failure of management and it was shipped as-is.

Post reply on HN