Input methods for embedded sistems

[ppTRN]

Hi everyone,
each time I design a new circuit, I always spend way too much time into figuring out what would be the best input method for my project. I am talking about touch screens, buttons, encoders, spring loaded Thumbwheels (whitch I am considering for my latest project) ecc... Of course it strongly depend on the specific project, but I mean, we can keep this conversation as generic as possible.
What consideration do you make designing your circuits? What input method do you think is the most user friendly being fast, simple and reliable?

As always, thank you.

[Doctorandus_P]

There is no single user interface that fits all use cases.

A PC keyboard and mouse works quite well for most PC applications, but for an oscilloscope a bunch of dedicated buttons and rotary encoders work much better.

My induction cooking plate has some touch buttons which sort of work and are easy to clean, but adjusting the timer is quite horrible. It has a "velocity" control, which means it starts slowly, and when you hold it for some time the adjustment speed picks up, which means that setting the clock to for example half an hour is both slow (because of the start) and annoying because once it gets near half an hour the adjust ment is so quick there is no way to stop on the right spot.

Those clocks you have to wind forward 23 hours and 59 minutes just because you were 100ms too slow to release a button... Yugh!

I've also built me a clock which has quite a lot of functions, but only 4 buttons. (Left, right, Up, Down).
Left and right step though the digits, while Up and Down increase and decrease the digits. Going "off" the display on the right side acts as an enter button, while backing up to the left side acts as an escape key and cancels input. The "digit under adjustment" is blinking to indicate that.

It's also got a week timer with 32 programmable times.
When the (6 digit 7 segment) display shows the time and Up or Dn is pressed, it cycles through displaying the programmed switch times, and going Right on any of those times enters the "adjust" mode for that time.

This all works quite nicely and intuitively. I once gave the clock to someone else and he figured out how it worked within a few minutes and without telling them anything about the user manual.

For other projects, just a serial port is sometimes the best interface. Just plug in a terminal emulator and adjust functions with some text based menu.

If you want to build lab equipment such as multimeters or power supplies, then look a bit around to what other manufacturers do with similar equipment, make notes about what you do and do not like and mix that with your own ideas.

[jwet]

I've struggled with this too over the years.  I think people's expectations have changed over the years.   I build embedded systems for biologists and they can't handle buttons and deep menus.  What they really want is a iPhone like interface.  Cheap color touchscreens are available but not especially rugged or reliable.  That's the way I'm headed.  In the past, I would have small displays with an interface like a VCR interface- a buttons and a a one or two line LCD.  This won't cut it these days for the masses.  I've tried to use cheap android platforms but they have their own set of quirks- mainly agressive power and memory garbage collection in the OS that kills idle processes.  Most embedded systems look pretty idle when waiting for an even or a time.  This is not easy to fix.  A lot of my stuff, does stuff at sundown or sun up for some time- plays sounds or takes pictures.  You have to be able to set local time, give it location (long or lat or a city database) and some times and offsets.  Not difficult but I haven't come up with one where the "user" can do it.  I have to go out and make changes.  Considering using a GSM or phone module and making them maintainable by phone but this requires a phone contract generally.  Keep the board posted.  A microwave type glass touch interface could work but its large and isn't an off the shelf type of item.