GB2482546A

GB2482546A - End user configurable user interface for device test system with user interface elements appropriate for the device under test

Info

Publication number: GB2482546A
Application number: GB201013262A
Authority: GB
Inventors: Ian Bowman Brockbank
Original assignee: Wolfson Microelectronics PLC
Current assignee: Cirrus Logic International UK Ltd
Priority date: 2010-08-06
Filing date: 2010-08-06
Publication date: 2012-02-08
Also published as: GB201013262D0

Abstract

An evaluation system monitors and controls a device under test. The user interface of the system displays controls for the device, which are appropriate for the device under test. These controls may include sliders to set numeric values or toggle buttons to set single bit values. The user interface is constructed from pre-configured user interface elements. The user interface may display a number of different controls, which are mapped to different registers in the device under test. The mapping and the layout of the controls may be defined using a configuration file written by a test engineer. The device under test may be an audio filter or an audio codec.

Description

APPARATUS AND METHOD FOR MONITORING AND CONTROLLING

A DEVICE UNDER TEST

Technical Field

The present invention relates to an evaluation apparatus and method, for example an apparatus and method for monitoring and controlling a device under test, for example an electronic device. In particular, the invention relates to a domain-centric approach to user interface design.

Background

When testing and evaluating devices, engineers need to change the settings on the device under test (DUT). There are 3 typical scenarios where this is required.

Figure 1 shows an example of a first scenario in which a DUT I is placed on an evaluation board 3 and controlled using a separate computer 5. The evaluation board 3 has appropriate supporting circuitry and components that allow the operation and performance of the DUT 1 to be evaluated. In this scenario control software running on the computer 5 communicates with the DUT 1 via a communications link 7 (for example a USB, serial or parallel communications link). In practice some form of additional interface is also provided, for converting signals received from the computer 5 into signals that the DUT 1 can process. Typical communication interfaces for devices under test include AC'97, 120, 12S or SPI. This scenario is typically used during the initial evaluation of a DUT 1 (and also during development) to debug problems and work out how to achieve the best operation and performance from the DUT 1.

Figure 2 shows a second scenario in which the DUT 1 is installed on some form of development platform 9 that also includes all the processor(s), memory, controllers and other components and devices necessary to develop a full system. In this case the control software is running on the development platform and communicating with the DUT directly via one or more interfaces, (for example AC'97, 12C, 12S or SPI as mentioned in the first scenario). This type of arrangement is typically used during system development in order to help get a whole system up and running, including all of the hardware, software and drivers necessary for full development. The development platform 9 is also used for debugging problems that occur when integrating the different components of the system. Once fully debugged and working, the development platform 9 will typically be used as a reference platform for one or more customer applications (i.e. mass-market products).

According to a third scenario shown in Figure 3 the DUT 1 is installed in a customer application 11 that also includes all the processor(s), memory, controllers and other components and devices necessary for a full system. In this case the control software is running on the customer application and communicating with the DUT directly via one or more appropriate interfaces (for example AC'97, 120, 12S or SPI as mentioned above). This scenario is typically used by a customer once a customer's application has been developed from a reference design, for debugging integration issues which occur during the development of the application.

The standard way of creating user interfaces is to select user interface controls (e.g. buttons, sliders, drop-down lists) and place them on a canvas. The developer then writes custom code which calculates the correct information and options to display in the controls, based on the current state of the program, and updates the controls to display this information. Code must also be written so that as the information changes, the controls are updated to reflect the new values.

The developer must also write code to respond to control actions such as button presses, key click, slider updates, list selections, and update the state of the program accordingly.

This has the following problems: 1. It requires a level of software programming skill to develop the code.

Modern development environments go a long way to reducing the amount of skill required, by auto-generating the standard code elements, but it is still an exercise in software development.

2. Good user interface design requires a combination of both software user interface design skills and domain knowledge. Typically a domain expert is not also a software engineer.

3. The connection between the user interface and the program state is added manually by the developer; every manual step introduces the possibility of user error which can result in incorrect interfaces.

4. A domain expert may have a passing knowledge of user interface design, and what controls are suited to which purposes, but they will not do as good a job as a professional user interface designer. They also typically do not have a lot of time to spare for software development, since they are responsible for all aspects of their domain.

5. The user interface designer/developer, while expert at developing software interfaces, is typically not also an expert in the domain. She understands how to create user interfaces but does not have the knowledge of how domain users work and think, or the tasks they wish to accomplish.

One instance where user interface software needs to be developed to provide domain-specific control and support is for an audio codec, such as those provided by the applicant. Here the domain expert will be a hardware engineer who understands electronic circuits and how to optimise the codec configuration and support circuitry for best audio performance and power usage. They need to spend a lot of time familiarising themselves with the detailed electronic design and specification of the codec. This is not usually someone who is also an expert on software user interface design and development.

Another instance where user interface software needs to be developed to provide domain-specific control and support is a software audio effect algorithm to be run on a digital signal processing (DSP) core. Here the domain expert will be a DSP engineer who understands signal processing and transformations and how to implement these in software. While this may well be a software engineer, the skills required for this role are again very different from those required to develop user interfaces.

Summary

It is an aim of the present invention to provide an evaluation apparatus and method, for example an apparatus and method for monitoring and controlling a device under test, which helps reduce or overcome the disadvantages mentioned above.

Embodiments of the present invention relate to an apparatus and method for specifying user interfaces based on domain-specific entities, which enables domain experts without software skills to develop high-quality domain-specific user interfaces.

Brief description of the drawings

For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example only, to the following drawings in which: Figure 1 shows a typical scenario for testing a device using an evaluation board controlled from a separate computer; Figure 2 shows a typical scenario for testing a device using a development platform; Figure 3 shows a typical scenario for testing a device using a development platform installed in a customer application; Figure 4 shows an example of a panel according to one embodiment; and Figure 5 shows an example of a panel according to another embodiment.

Detailed Description

Although the embodiments described herein will be described in the context of an evaluation apparatus and method for use with audio devices such as audio codecs or filters, it is noted that the evaluation apparatus and method may be used with any other form of device that is to be tested or evaluated.

The prior art allows user interfaces to be developed, but only allows task-specific panels to be created in an ad-hoc fashion based on hard-coding user interfaces using standard user interface components.

The embodiments of the invention described herein allow development and support engineers and even users to create domain-specific user interfaces in a simple, extensible and portable manner based on the actual units of control involved in the task.

A user interface may be considered to be built up of informational images and text, plus user controls which provide access to viewing and modifying the current state of the program. Each user interface control provides access to a single unit of program state control.

For example, a codec is controlled through a register map, with registers consisting of a plurality of bits collected into units of control known as register fields. A field may span one or more bits within a register, and indeed may span multiple registers, but the defining characteristic of a field is that it has a single indivisible purpose. For example, a field may be a single bit enabling and disabling a portion of the DUT. Alternatively a field may contain multiple bits which control the amount of gain applied to a signal passing through a certain component of an audio chip. It may contain one or more bits controlling the voltage output from a current converter. It may contain a single coefficient used in a user-controllable filter within the DUT.

In this case the unit of control within the domain is the register field.

In other applications, such as an audio filter library, the unit of control may instead be a coefficient which is applied to configure an aspect of a filter within the library. The unit of control may also be an abstract concept which affects multiple units of control within the device or unit. Examples of this would be the centre frequency and band width of a band-pass filter, which are combined and converted into multiple coefficients using a set mathematical formula before applying these coefficients to the filter.

Achieving optimal performance can require a sequence of updates to one or more controls in a specific order. The domain expert would know what sequence of operations provides the best performance for a particular operation. This sequence can be captured in a script, either human-readable or machine-readable, and executing the steps of the script in order can be considered as a single control operation.

Embodiments of the invention consist of a machine-readable representation of a domain-specific control panel, described in terms of the units of control within the domain. How the control is presented within the panel can be determined automatically based on the specification of the unit of control, or can be specified by the user.

This control panel specification is parsed by the software GUI code and appropriate user interface elements are created for each of the control elements within the panel. Since the software understands the domain-specific purpose of the control element, it can be programmed to automatically display the most appropriate user interface elements for the control element. The software will also understand how the control element relates to the program domain, allowing it to automatically manage the connection between the user interface control on one hand and the program state on the other.

This allows the domain expert to work in terms of the units of control with which they are familiar and concentrate on presenting and combining the necessary control units for the tasks which users will wish to accomplish. The actual user interface definition comprises the steps of selecting the appropriate units of control and arranging them together with appropriate diagrams and text so as to guide the user in the execution of their task. This addresses problems 1 and 4 mentioned above.

This also has the benefit that the software user interface expert's input is only required to implement the rules mapping a unit of control within the domain to a user interface element and its auto-generated handling code. The user interface designer can concentrate on providing up-to-date user interface elements which comply with best practice, and these will be automatically instantiated according to the units of control specified by the domain expert. This addresses problem 5.

The embodiments of the invention separate the input required by the software user interface designer and the input required by the domain expert, allowing the two roles to concentrate on their relevant areas of expertise. This addresses problem 2.

Because the connection between the program state and the user interface controls is managed automatically by the mapping layer within the software, it is guaranteed to be managed correctly (assuming that the mapping layer itself has been developed correctly). This addresses problem 3.

There are many functionally-equivalent machine-readable formats that can be used with embodiments of the invention, including a binary representation, a database or a textual representation. The examples described herein will be given using XML, a human-readable format which lends itself well to machine processing also.

Codec control panel example I A feature of the invention is the provision of one or more control panels, each of which can contain representations of the units of control. At its simplest, it might just have a single panel with an image on it. For example: <Panels> <Panel> <Title>WM8958 Block Diagram</Title> <Group>Overview</Group> <Picture>WM8958 Block Diagram</Picture> </Panel> </Panels> Here "WM8958 Block Diagram" within the Picture tags is assumed to refer to an image stored either within the same file or otherwise accessible by the user interface software.

Codec control panel example 2 The domain expert might add another panel with controls for a specific audio output. Controls can be located and sized within the panel. As example of such a panel is shown in Figure 4.

The panel shown in Figure 4 could be described as follows: <Panel> I riz,-'i i-r- <Size Width="5O Height=16" I> </Control> <Control> <Thrnct FkId="SPKOI ITI 7C." I> the type of register field what user interface control to use to display that control element. So: o SPKOUTL_MUTE_N is a single register bit. This is represented as a push-button within the interface, with raised corresponding to a 0 value and depressed corresponding to a 1 value.

o SPKMIXR_VOL is a multi-bit register field with a range of values from -63dB to 0dB corresponding to register values OxOO to Ox3F respectively. This is represented as a slider, with the thumb

showing the current setting of the field.

o BIAS_ENA is a multi-bit register field with each value having a corresponding label. This is represented as a drop-down list of values. In the screenshot, the field is set to the value corresponding to "Disabled".

* Controls are optionally located within the panel using the Location tag.

Note: if the location is not specified, the software is adapted to lay out the controls automatically according to some standard layout heuristics.

* The size of the controls can be specified to give the panel designer more control in layout.

* There is no code required of the panel designer to create user interface controls, connect them to control operation handlers or ensure that updates to the register field values are reflected in the controls. This is all handled automatically by the user interface software based on the information within the panel definition.

* The panel designer can specify text labels which are displayed along with the control to provide further guidance to the user.

* To allow the user interface to know how to display each unit of control, it needs some definition elsewhere within the program of what that unit of control represents and what values it can take. This could either be built into the application, or loaded from an external source, without materially affecting the invention.

The panel definition can be updated to allow further specification of the appearance of controls. For example, control colour could be specified or text orientation. Also, different user interface controls may be appropriate for different domain units of control -for example a date target might be represented with a calendar control, or a script target might be implemented with a button, which executes the stored script when pressed. This is within the remit of the mapping code which the user interface designer develops.

The form of user interface design described above may also be extended for use with a graphical drag-and-drop based specification tool, which further reduces the skill level required of the panel designer and enables them concentrate on their domain knowledge without having to worry about the

syntax of the panel specification.

Further details will now be given of how panels may be created.

The panels allow more control, more direct connection with the register map, and positioning of controls relative to the underlying picture.

The panels can contain: * A background picture, for example in Enhanced Metafile (.emf) format, although other formats such as JPG, GIF, PNG may also be used.

* Colour-coded buttons, for example, positioned either on the left or on the right, which run a text file when clicked In addition, the panels can contain: * Controls which are connected to the register map. This includes o Buttons -a single bit which can be on (1, set) or off (0, clear). The button is down when the bit is on and up when the bit is off; clicking the button toggles between on and off.

o Sliders -a multi-bit field with a scaled, exponential or compound value -e.g. a volume control, voltage level, etc. The slider position corresponds to the value of the field; dragging the slider updates the register map.

o Drop-down lists -a multi-bit field with an enumerated value -e.g. a clock source select, interface bit-width, etc. The list is filled from the enumerated values; choosing a new value from the list updates the register map.

* Positioning of controls relative to the underlying image. For example a button or slider centred at (13.2, 15). This allows controls to be visually related to the diagram -for example enable bits on top of the switch they enable, or volume sliders on top of the gain they control.

* Some form of cross-referencing which can take the user to another panel.

Adding a panel Adding a panel has the following steps:

* Creating and adding a background image

* Adding panel information * Adding controls to the panel * Testing and debugging...

These are described in more detail below.

Adding background images

To add a background image, first create your image in Visio, then save it as an Enhanced Metafile (.emf). If you want a simple scenario panel with buttons corresponding to coloured paths in the diagram, draw your paths on the diagram.

Now add your image to the device description using the apparatus: After saving the.emf file into the device description there will now be a set of new tags at the bottom of the description file for describing the quick start panel.

The next section describes the format of this.

== The Panels node This contains the QuickStart Panel details.

<Panels> <Panel> <Title></Title> <Group>< /Group> <Picture>89O2Blockdiagram all paths</Picture>

<Controls!> </Panel> </Panels> Title: goes between the <Title> and </Title> tags. This must be specified.

Group: To organise multiple panels into groups of similar panels you fill in the group tag. This must be filled in if there is more than one panel. This is just a text string -all panels with the same group name are collected together within the apparatus.

Description: The description appears in the tool tip when you hover over a thumbnail when multiple panels are displayed. It should tell the customer what this panel does. It does not need to be filled in and is not viewable if there is only one panel.

Adding controls to the �anel according to one embodiment According to one embodiment the apparatus supports generic controls connected to the device register map. In the simplest form, this will just specify a register field and let the apparatus choose suitable defaults for the presentation.

<Control>

</Control>

<H-A multi-bit field control -->

<Target Field="LINEINLVo / r

Single-bit Fields

If the field is a single bit, the apparatus will create a button connected to that bit in the register map. When the bit is 0, the button will be up, and when the bit is 1 the button will be down. Clicking the button changes the bit value between 0 and 1.

<H-A single-bit control --> <Control>

</Control> Read-only bits may be represented by an LED instead. When the bit is 0, the LED is unlit. When the bit is 1, the LED is lit.

Multi-bit fields

<H-A multi-bit field control -->

</Control> For multi-bit fields, the default control created will depend on how the field is described in the device description, based on meaningful values. A meaningful value presents a register field value in terms meaningful to a human. So for example, a field ADCL_VOL might be set to 0x33. To the chip this makes perfect sense, but to a human, it's much more useful to see "-3dB". The mapping from field value to user value is part of the device description.

Enumerated values Enumerated values are compound values which just contain labels. These will be represented by a drop-down list presenting the options from the register field. For example, if we had description field with the following mapping:

Field value Label

0 16-bit 1 20-bit 2 24-bit 3 32-bit A control connected to this register field may be created as follows:

<H-A multi-bit field control connected to WL -->

</control> This would be represented by a labeled drop-down list with the 4 options "16-bit", "20-bit", "24-bit" and "32-bit". If the user selects "1 6-bit", WL will be set to 0.

If the user selects "20-bit", WL will be set to 1. If the user selects "24-bit", WL will be set to 2. And if the user selects "32-bit", WL will be set to 3. Conversely, if WL is set toO, this control will change to show "16-bit", and so on.

Decimal, Hex, Binary, Scaled, Exponential All other values will be represented by a slider, possibly with overlaid label and value, possibly with separate text box for value.

The range and values are taken from the register description.

For example, given a field where the value 0 is displayed as 0dB, and each increment in field value gives a 1.5dB decrement (i.e. 1 = -1.5dB, 2 = -3dB, ...): A control connected to this register field may be created as follows: <!--A e e e > <T e *e V L" /> > This would create a slider connected to LINVOL with a range from 0dB to -22.5dB with 1.5 dB steps.

Script Files To create a button which loads a script file, use a Filename target instead.

<f--A button to load a text file --> <Control> <Target Filename="LINE IN to ADC.txt" /> </Control> Panel Linking To create a link from one panel to another, a Target of Panel is used, giving the name of the panel to switch to (the content of the Title field in the description).

For example:

<H-Swi oh to the Quick Start Panel --> <Control> <Target Panel="Quick Start Panel" /> </Control> If there are rriultiple panels with the same name in different groups, specify the group first, followed by::, followed by the panel title. For example: <H-Switch to the "Asynchronous Cellular Voice Call to Earpiece" panel --in the "Digital. Mixing Core" group.

<Control> <Target Panel="Digital Mixing Core::Asynchronous Cellular Voice Call to Earpiece" /> </Control> Specifying the size of the controls If you need the controls to be a particular size -for instance if you are trying to create small buttons over routing linkages in the block diagram -you can specify this using <Size>: <H-Control DACL to HPL --> <Control>

<Size width="lO" height="lO" I> </Control> This will make the button 10 pixels wide by 10 pixels high.

Controlling the position of the controls If you don't specify a location, the apparatus will try to lay out the controls intelligently within the panel in the order in which they appear within the panel. If you need to, you can control this layout in one of two ways.

Specifying an absolute position To control the position of the control relative to the background image, add a <Location x="xx" y="yy"I> field to the definition. The x and y coordinates are measured from the top left of the background image.

This is useful for aligning controls on top of (e.g.) a block diagram.

For example:

<H-Con rol DACL to HPL --> <Control>

<Location x="731" y="13O" I>  </Control> Assume the background image is 800 pixels wide by 600 pixels high. This will centre the slider on a point 731 pixels from the left of the image and 130 pixels from the top of the image Specifying control groupings If you don't need to line up the controls exactly with an image, but just want to control how they are laid out relative to each other, use <ControlGroup> instead. Control groups can be nested, allowing grids to be built up.

This is useful where you have several related controls which need to be together. For example: Label is the text to be displayed on the button. If not provided, this uses a default based on the Target: the register field name or the file name with the.txt stripped off (so for example if the filename was LINE_IN to ADCtxt, the default label would be "LINE_IN to ADO". Typical character lengths for button labels are around 15 characters with a maximum of 25 characters. A label can have optional Width and Height parameters. This is used if the label is displayed separately from the main control, for example with drop-down lists. A label can also have an optional Align parameter, which can be either Left or Top. If not specified, it defaults to Top.

<-Control with specified label width --> <Control>

<Label width=" 60 ">Word length</Label> </Control> <!-Control with both specified label width and height --> <Control>

<Label width"40" height="40" align="Left")TaII left-aligned label!</Label></Oontrol> Description provides extra information about the control. It appears on the tool tip when you hover over the control. This is optional. By default this uses the

description from the field in the register map.

Colour is the colour of the control and is optional. This is split into the red, green and blue components. If not specified, the apparatus will use the default control colour.

Adding controls to the panel according to another embodiment The final step is to add some controls to the panel to allow the user to interact with it.

Button Note: this may be deprecated in certain embodiments, and Oontrol with a Target of Filename used instead.

<Button> <Label>LINEIN to ADC</Label> <Filename>LINEIN to ADC.txt</Filename>

<Description>Connects the line in to the

ADC </Description>

<Action> <LoadTextFile/> </Action> <Colour> <Red>2 55</Red> <Green>2 55</Green> <Blue>Q</Blue> </Colour> <Location> <Left/> </Location> </utton> Label is the text to be displayed on the button. If not provided, this uses the file name with the.txt stripped off (so for example if the filename was LINE_IN to ADC.txt, the default label would be "LINE_IN to ADC". Typical character lengths for button labels are around 15 characters with a maximum of 25 characters.

Filename is the text file loaded when the button is clicked. This appears on the tool tip when you hover over the button. This is required for a LoadTextFile action (which is the only action supported in these versions).

Description provides extra information about the button. It appears on the tool tip when you hover over the button. This is optional.

Action tells the apparatus what to do when the button is pressed. In certain embodiments the only supported action is LoadTextFile.

Colour is the colour of the button face and is optional. This is split into the red, green and blue components. If not specified, the apparatus will use the default button colour.

Location is where on the panel the button will appear. In certain embodiments, the only supported locations are Left and Right. In one embodiment there is a maximum of 10 buttons in any one location. They are ordered with the buttons defined first placed nearest the bottom of the screen. If there are more buttons on one side, the apparatus will balance them so that the top buttons on each side are level.

Creating further panels To add more than one panel simply put another set of Panel tags within the Panels tags. More than one panel can share the same picture. More pictures can be saved into the file by repeating the steps in the Saving the image into

the device description' section.

== The Panels node. This contains the QuickStart Panel details.

<Panels> <Panel> panel information </Panel> <Panel> panel information </Panel> </Panels> As mentioned above, although the embodiments have been described in relation to the testing and evaluation of audio devices, the invention may be used with any device under test or evaluation.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS1. An evaluation apparatus for monitoring and controlling a device under test, wherein the evaluation apparatus is adapted to specify a user interface based on one or more user interface formats relating to domain-specific entities, wherein each domain-specific entity relates to a particular device under test, wherein the apparatus comprises a display for displaying a domain specific interface for a device under test without a user having knowledge of the program code used to program the evaluation apparatus.
2. An apparatus as claimed in claim 1, wherein the one or more user interface formats are pre-configured in the evaluation apparatus.
3. An apparatus as claimed in claim 1 or 2, wherein a device under test comprises a plurality of registers, each register having a register value and comprising a plurality of data bits for controlling a setting or settings of the device under test, and wherein the domain specific interface comprises an interactive register map that is configured to display a plurality of register values simultaneously, and wherein the register map is further adapted to display one or more data fields corresponding to each register value, each data field relating to one or more of the data bits and having a first indicator for representing a corresponding device setting.
4. An apparatus as claimed in claim 3, wherein a data field comprises a single data bit, and wherein the first indicator comprises a toggle button for representing a device setting having first and second states that are controlled by the single data bit.
5. An apparatus as claimed in claim 3 or 4, wherein a data field comprises two or more data bits, and wherein the first indicator comprises a slider device for representing a device setting having variable states that are controlled by the two or more data bits.
6. A method for monitoring and controlling a device under test using an evaluation apparatus, the method comprising the steps of: specifying a user interface based on one or more user interface formats relating to domain-specific entities, wherein each domain-specific entity relates to a particular device under test; and displaying the domain specific interface to a user, such that a user can use the evaluation apparatus for monitoring and controlling a device under test without the user having knowledge of the program code used to program the evaluation apparatus.
7. A method as claimed in claim 6, further comprising the step of pre-configuring the one or more user interface formats in the evaluation apparatus.
8. A method as claimed in claim 6 or 7, wherein a device under test comprises a plurality of registers, each register having a register value and comprising a plurality of data bits for controlling a setting or settings of the device under test, and wherein the domain specific interface comprises an interactive register map that is configured to display a plurality of register values simultaneously, and wherein the method further comprises the step of displaying one or more data fields corresponding to each register value, each data field relating to one or more of the data bits and having a first indicator for representing a corresponding device setting.
9. An apparatus as claimed in claim 8, wherein a data field comprises a single data bit, and wherein the first indicator comprises a toggle button for representing a device setting having first and second states that are controlled by the single data bit.
10. A method as claimed in claim 9, wherein a data field comprises a single data bit, and wherein the first indicator comprises a toggle button for representing a device setting having first and second states that are controlled by the single data bit.
11. A method as claimed in claim 9 or 10, wherein a data field comprises two or more data bits, and wherein the first indicator comprises a slider device for representing a device setting having variable states that are controlled by the two or more data bits.