How are embedded user interfaces controlled

Question

How do they code the logic of a user interface running on embedded hardware. Microwave ovens, flat screen televisions, portable DVD players and even a digital watches these days have complex user interfaces. Are there tools / frameworks available to remove all the dirty work or are the developers using IF ELSE kind of constructs.

I'm not asking for user interface toolkits in the sense of QT or WxWidgets. I am more interested in knowing if there are frameworks to handle the logic behind the controls.

if (mTemperature > maxTemperature)
    temperatureDialControl.Enabled = false;

Answer 1

Are there tools/frameworks to remove all the dirty work .. ? Yes, there are. They are called embedded OS'es and RTOS'es. As a rule, they help in handling interrupts generated by timers, buttons, and other controls, they contain hardware abstraction levels, they include various communication protocol stacks and etc. So, basically, they do all dirty work. All you need is to process what they provide using IF/ELSE or SWITCH or whatever you like. At least who knows better that temperatureDialControl.Enabled has to be false if mTemperature exceeds maxTemperature?

Answer 2

I've used the Quantum Platform family of frameworks from Quantum Leaps for several embedded products with user interfaces (and those without UIs as well).

The QP is a framework for event-driven programming (which essentially all embedded systems are). User interfaces in particular are a good match, because most user interfaces consist of "widgets" which can be customized, and the widgets typically receive events (timeout, button press, movement, etc.) from an event dispatcher. This "inversion of control" is very typical with user interfaces. Most (embedded) user interfaces that I've come across in my career are either event-driven state machines, or they should have been implemented that way.

You asked specifically about handling the logic & controls. What's nice about the QP is that the active-object model of computing that it embraces lends itself to very natural & straightforward implementation of state machines (flat or hierarchical). So in your example above, you'd probably receive a "temperature update" event with a new temperature, and your state handler would perform the logic & decide what action is necessary. With a framework, you create the logic behind the controls, but the infrastructure handles almost everything else.

The Quantum Platform is pretty slick. It's also very easy to see the connection (traceability) between the design (statechart) and the implementation/code. Best of all, the framework implements all the infrastructure (event queueing & dispatching, state transitions, garbage collection, memory pools, etc..) so all you have to do is focus on your application.

I've used Nokia's Qt on non-embedded platforms, but your question seems to suggest you're already aware of it. I think there's a smaller "embeddedable" version of Qt but I've never used it.

Answer 3

With embedded you have the freedom to do whatever you want, you are not confined by the limits of an operating system or worse an API. Embedded systems can be event driven, esp if power is a concern (battery powered) because you essentially want to go to low power and only wake up for events. But you can also use no interrupts and no events in the sense of interrupts, you can poll everything so long as your response time is guaranteed to meet whatever the requirements are.

As far as microwave user interfaces, which are trivial compared that of a computer keyboard for example, can be complicated or simple depending on the system. For cost each of those buttons may be fed into a microcontroller and the microcontroller has to poll or get an interrupt for each one and do the debouncing, etc. Or like your computer keyboard or mouse for example there maybe hardware and logic that does all that work and the microcontroller is sent a single byte or packet indicating an event, on some special or standard bus like serial or spi or other. Now that logic that performs that task may itself be another microcontroller whose only job is to debounce and detect button presses and then fire out the serial byte when it sees a state change. Polling is probably easier but I can imagine ways to debounce using interrupts as well.

Embedded is only special in the sense that you are not confined by operating system limits and apis, except for those that you impose on yourself (or are imposed by the customer). The user interfaces are normally much much simpler than a desktop programs user interface.