Live data from Hacker News

I dread writing embedded GUIs

blog.benjamin-cabe.com

41–50 of 58 posts

Re: I dread writing embedded GUIs

#41

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 a…

There is a lot to discuss here, but if I had to choose I would reject your idea.

This is mostly because, in reality, manufacturers not only will they never open source those apps, most probably they will never provide APIs and the Thing and associated apps will depend on some server. Such a dependency I find unacceptable, but it is the trend of all things IoT.

If this were not the case, if by law all IoT Things had to provide open APIs, I would be all for it.

Re: I dread writing embedded GUIs

#42

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?

As the owner of the first company I worked for said when he was complaining about a product, "somebody said, 'fuck it, it's good enough' and shipped crap out the door."

Re: I dread writing embedded GUIs

#43

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 millis…

That last sentence is what we're mostly standardizing on, except for using QT.

I've pushed for web interfaces but it's weird how even embedded developers with broad backgrounds get when you bring it up. I think there's a psychological barrier some people have to using webpages on an embedded system.

Re: I dread writing embedded GUIs

#44
post #7

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

Unless you're building many thousands of units for a price-sensitive market, it's almost always a better use of your time to run a nice GUI on a separate PC like a Raspberry pi and do your real-time stuff on a $4 arduino or $1.50 MCU.

Re: I dread writing embedded GUIs

#45
post #25
post #23

Earlier quoted context omitted.

Personally I'd rather avoid apps. I already have like seven dozen apps from all the smarthome devices my partner buys. It clutters up my phone, I have no idea how much they're spying on me, and it's a pain to pull out my phone to change some hardware right in front of me. Let me configure it physically, or do it over a web browser, but preferably the later. Especially for when the servers are shutdown because the pro…

This is true. If embedded device makers do make an app they seemingly can't resist doing it without vacuuming up your personal data / device telemetry or proxying device connections via their servers.

It's not even that. I'm one of those people who never has their phone nearby so it would be a chore to have to get my phone out of the bedroom every time I wanted to use an appliance.

Re: I dread writing embedded GUIs

#46

Earlier quoted context omitted.

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 te…

Been down this road many times:

- UI toolkit is cross platform (cough cough Qt, or Altia, or Crank) and runs great on the UX developer's x86 box. The UX guy loves fancy CSS transitions.

- Graphic assets are delivered in 32bit RGBA and the data cache chokes on the massive bit maps. And the cheap LCD is 565BGR so the CPU is constantly mixing channels. Then we discover the hardware has no alpha blending capability. More software load.

- Hardware gets cost reduced. Or the flagship platform gets the beefy CPU and the consumer versions get a Rockchip.

- RAM gets downsized or the project grows out of bounds and now we're blitting from QSPI flash.

- The whole system runs in JavaScript because that's what they can get out of the overseas development team, or it's too expensive to buy 2 more Qt seat licenses (or whatever the hell they want now. I think we're up to first-born children)

It all repeats, over and over.

Re: I dread writing embedded GUIs

#47

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 handl…

A Raspberry Pi 4 is a good bit more powerful than most embedded systems.

Re: I dread writing embedded GUIs

#48
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 wit…

Not to mention they may ask for money, if not now then perhaps later.

Re: I dread writing embedded GUIs

#49

Earlier quoted context omitted.

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 te…

Been down this road many times: - UI toolkit is cross platform (cough cough Qt, or Altia, or Crank) and runs great on the UX developer's x86 box. The UX guy loves fancy CSS transitions. - Graphic assets are delivered in 32bit RGBA and the data cache chokes on the massive bit maps. And the cheap LCD is 565BGR so the CPU is constantly mixing channels. Then we discover the hardware has no alpha blending capability. More…

This is even happening in video games now. See Gameface for example.

Re: I dread writing embedded GUIs

#50

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

Off topic -> but on topic of the original post. Do you know if https://github.com/ocornut/imgui is available for embedded? It might be too much for the very low end but it for a reasonably capable system it's better than web or some high powered UI like Qt.
Post reply on HN