I've done a few projects interfacing embedded devices, and the "I must guess at the device's state because the manufacturer didn't think communicating that was important" scenario fills me with sadness and rage. I'd love to slap around every developer who thought that making such a device was a good idea.
Hopefully if you ever end up working on a device with firmware I’ve written, you’ll end up pleasantly surprised. I’ve worked all over up and down the hardware/software stack from mobile UI down to gate-level design, and one of the biggest principles I’ve picked up over the years is that observability is absolutely a hard requirement. I’ve felt your pain myself and refuse to design systems that inflict that pain on others :)
You're a gem in the embedded world of almost pure coal and dirt mixture.
I also want to stab embedded developers with a pin header if they ever try to use a touch screen. About the only place a touch screen makes sense and is provably better is your phone. Any other application of a touch screen needs to be eradicated from this planet.
Thing is, it's expected of a lot of devices with a screen to have that screen be a touch screen too.
I've worked on the touch screen UI for a 3D printer, one that used to have a tiny OLED and a rotating push button. Company did some usability research on that and people couldn't figure out how to use that combination.
The touch screen UI was well researched and won an award even and I dare say one function regressed because of the touch screen, but that function (manual build plate leveling where you look at the nozzle instead of the screen) you should never need any more because the rest of the machine got better.
Modern car manufacturers: "Hey let's replace this perfectly fine working knob with a touch screen that sorta looks and feels like a knob but really isn't and that will need an outrageously expensive replacement just after the warranty ends"...
Off the top of my head, systems where a touchscreen is probably better than other input:
- Ticket machines
- Food machines
- Informational kiosks
- Border control machines
Basically whenever you have a public-facing system that's designed to be used for a short period of time, with relatively simple input.
Touchscreens are more accessible than mouse/keyboards, because many people genuinely don't use mouse and keyboards at all. Furthermore, it's a lot easier to keep a touchscreen clean than a mouse and keyboard!
I totally disagree - for simple actions there is no need for a touchscreen. Just put a button and a label. And LED to confirm the action, buzzer if sound is needed. That is all you need.
The only advantage of a touchscreen is surprisingly not the ability to touch, but the ability to reconfigure the input interface through software. When you don't need to reconfigure things, encoders, toggles, push buttons, rotary switches, etc. are far superior (with some downsides - cost, reliability).
> for simple actions there is no need for a touchscreen.
Ok, here's a simple action, that's often solved by touchscreens - Choose a destination from a ticket machine. Let's start with the button-first approach. Here's what the London Underground ticket machines used to look like:
No, your hands are gonna get tired after about 3 mins of using surface. All these futuristic videos showing what the future entails - everyone using a touch screen or a gesture - is ergonomically aggregious and completely out of touch(no pun) with reality.
Only with some sort of approximately-tactile feedback. Some VR systems fall completely short of this (most dataglove type devices) while other "cruder" ones (like console controllers) actually do a better job because interfaces like buttons and triggers are analogous to many real world sensations.
I had to endurance test some industrial flash EEPROM in a humidity/thermal cycling chamber to simulate failure, but the darn Atmel flash was too good. Even so, I wrote logging code that anticipated bit and block pathologies with a layer of turbo coding FEC to extend the serviceable life of the flash well beyond the manufacturer's spec.
What are you concerned about and what are you preaching about in vague, motivational quotes? Have you even ever done any embedded software development in a shipping industrial product? The only industrial flash available at the time (SLC) and already spec'ed in the manufacturing BOM had a warranted cycle time of 10^5 writes. It was doing upwards of 10^6 just fine, but it would've taken months to get close to 10^7. The desired goal was to make the flash live 10-20+ years while writing log data to spare space including data points such as temperature, voltage, errors, etc. for as long as possible.
That's a problem with abstraction layers and hiding state, observability goes into the toilet.
Interesting thing I learned about designing production test equipment. If you show the operator all the nasty state information they quickly learn to associate trashy diagnostic output with corrective action. That janky message means, run it again, it'll pass. This other one means that row of pogo pins needs to be replaced.
My other pet peeve is in-band communication without escape codes. Oh, the radio connected you so now you're talking to the other end. Oh, the link got dropped so now you're talking to the radio itself. What could have been a simple search-for-sequence filter now becomes a best-guess filter. Gaaaah makes my blood boil even 5 years later.
Honestly after my experience in firmware and manufacturing I'm amazed anything every works
I graduated EE with ('understanding' but) bafflement that radio works. Like just plain old amplitude or frequency modulated radio. Madness.
I work with software now/currently. I'd be surprised it all works if only it wasn't so frequently clear that it doesn't! I suppose the idea of updates has been quite quickly ingrained in the consumer mind - software bugs are somehow more acceptable, seen as just 'to be fixed' rather than 'broken' or 'poorly made', 'not very robust'.
