Device Menus

Date

2014-08-01 10:33

Update

2020-06-06 13:00 - Shorten title, adjust introduction.

During experimentation with my DN2012-000 - I2C Experiment Board and an Arduino board, I decided that I wanted to code in a service/configuration menu to allow me to change settings and read the memory locations without having to reload the sketch. This had me thinking about menus in general and how they are implemented on different devices.

Common Menu Types

- User Menus - User preference changes, screen layout, font size etc.
- Configuration Menus - Power on defaults that persist across reboots.
- Service Menus - Calibration settings and adjustments.

How are menus implemented on existing devices? What methods are used?

My day job working in Medical Engineering means I have plenty of opportunities to work with products from different manufacturers. Devices range in cost from the cheaper (replace rather than repair) items to the very expensive (needing maintenance/servicing over many years). The devices can be the latest the manufacturer has to offer or the ones that refuse to fail as they were built to last. Device menus are implemented in a few distinct ways.

Approaches to menu implementation

1. No menu options. The device has no changeable settings. Fixed HW/SW.
1a. No menu options. Switch or button operation to toggle modes, features. Fixed SW.

2. User accessible menu options during normal operation. Changes reset on reboot, power cycle. [Features such as Volume, screen brightness, alarm triggers]

3. User accessible menu options during normal operation. Changes preserved across reboot, power cycle. [Features such as Volume, screen brightness, alarm triggers]

4. As approach 3 but requiring user to input a code to change or save a setting. [Used for setting default alarm triggers]

5. As approach 4 but requires user to enter multiple codes to enter different levels of nested menus. [First code for configuration options, second code for service menu]

6. Configuration/Service menu is not accessible via normal operating mode. Unit needs to be put into service mode. [Prevents accidental changes of settings]
6a. Combination of button/switch presses during power up.
6b. Change/removal of physical switch/jumper. Can be hidden/internal.
6c. Hardware dongle or key.

7. Data Port. Another device (Laptop/RS232/USB/Other) is connected to a data port to access settings. [Less complex user interface needed on product, can be used to take log data from device.]
7a. Manufacturer provided cable/programmer [Usually for non-standard ports/protocols]
7b1. Terminal Access (RS232/USB) - Standard Serial Console tools
7b2. Terminal Access (RS232/USB) - Manufacturer Application
7c1. LAN/WIFI – Access Web Interface
7c2. LAN/WIFI – Manufacturer Application
7d. Memory Card/USB Stick to upload/download settings file.

8. Multiple of any of the above approaches.

Assessment of Approaches

Creating the different menu methods requires different amounts of hardware/software to implement. Having a code to change settings needs a way to input the code and process it.

Whichever method is used depends on several factors:

  • What does the menu needs to access? (user settings, configuration, logs, service functions)

  • Who needs to access the menu? (End User, Developer, Service Personnel, Company Representative)

  • How often is access needed? (Easy access for common tasks of a few more steps for occasional options)

  • Where is access needed? (On-site, during use, on a workbench)

  • Disassembly / Tools required?

The method used will ultimately depend on which is the best fit for the product. If the user interface is sufficiently complex anyway adding extra menu options is software only. A basic user interface might encode options as numbers on LCD/7-Segment displays or just go for a data port approach.

Which Approach will I use?

My needs are simple. I am working with a serial data connection, led and 2 buttons (one is for resetting the Arduino board). My approach will use a held button and board reset to enter the service/configuration mode. The same serial console used to read data during normal operation will be used to show the menu. No additional hardware required. I have no need for codes to protect changes as the project doesn’t warrant the additional security that brings. The need to enter service mode and connect with a serial terminal should be sufficient to prevent accidental changes.

The intent is to have the serial console output human readable text. This might change if the program exceeds the capacity of the chip. In this case I might resort to an external application to provide the human readable side by processing the raw serial data.