User interface simplifies embedded TCP/IP connectivity

User interface simplifies embedded TCP/IP connectivity
Now that TCP/IP connectivity is becoming common for embedded systems, designers have to deal with the problems of setting up, monitoring, and troubleshooting remote devices. One approach is to make each embedded device an HTTP server with a web page that can be accessed from any computer having a browser.

However, putting HTTP and a Web page in a small system can consume too many resources. And even for those systems that are large enough to support HTTP, other issues appear: Can a consistent user interface be maintained across product lines to make training easier? Is it practical to build sophisticated troubleshooting tools into every device? Can access to various features of the embedded device be controlled depending upon the level of user? For example, an R&D engineer might require access to data and/or features that an end user would not.

In recent years, there has been considerable discussion about such embedded system design decisions as whether to code in C or in assembly language, and whether to use a RTOS or to 'roll your own' kernel.

The consensus is that for all but the smallest and simplest systems, using a C compiler and an RTOS can save time and money when developing embedded systems. These tools also allow greater flexibility when making changes to the original design. The same reasoning can be applied to the design of a remote GUI for these systems. It is possible to 'roll your own' GUI by creating a web page, but there is an alternative: a general purpose database driven GUI application.

The use of an RTOS usually requires some additional resources in an embedded device. But in comparison with the web page approach, a database driven GUI can actually save resources. All that is required in each remote device is a TCP/IP stack and a small com driver for reading and writing data in native format. For RS232 connectivity only, the TCP/IP stack is not required.

A commercially available general purpose database driven GUI application should however, provide basic setup and monitoring functions, data capture and charting, logic-analyzer style triggering that can be used to freeze the charts to aid in troubleshooting, and a manual or automatic 'Maintenance scan' for finding fault conditions in multiple remote systems. Documents — typically manuals, schematics, test procedures — should be able to be included in the product databases and users should be able to open documents associated with the embedded device being operated. Access rights for different classes of users should also be supported. The program should also provide a small (1.5 kbytes or so) C language embedded system communication driver that has been integrated with a commercial RTOS and/or TCP/IP stack.

And, the communication driver should eliminate the need for any other coding in the embedded device. If all of the software components (GUI application, RTOS, and TCP/IP stack) are economical and royalty-free, so much the better.

With such a database driven approach, for each type of embedded device, a developer enters information into a product database that identifies the particular device and that also describes each parameter to be read or written in one of that device's native data formats.

Price to pay

The product database tells the GUI application how to display data from the device, including: conversion from various numeric formats to a decimal display; parameter names; conversion of discrete options (numeric or logical) to text phrases; and the generation of grids and custom-looking graphics. This removes nearly all of the work of generating a display from within the device. There is, however, a price for placing the description of the embedded device in a database rather than in the device itself. Unlike the web server solution, in which the device carries its own description with it, the product database must be distributed or be made available to users.

To minimize storage requirements in the embedded system, the protocol for communication between the GUI application and the embedded device can be designed to always have one packet sent to the embedded device and then one packet returned. For RS232 connections, one character is sent and one character is returned, since many UARTs can buffer only one character at a time. Thus, there is no need to assemble multiple packets to form one message and, aside from it having to capture each packet, there are no timing constraints on the embedded device.

Despite differences between the particular parameters that are monitored or controlled in various embedded devices and differences due to access levels, a consistent GUI can be created.

The application works the same way regardless of what is being monitored. This reduces training and makes it easier for everyone involved to work with different devices, whether those devices are based on an 8-bit microcontroller or a 64-bit microprocessor. Coding web pages is replaced by data entry. However, if a custom GUI is required, it can coexist with the general purpose one — HTTP usually runs on TCP/IP port 80; the GUI application can be assigned another unused port. For example, the former might be tailored to the needs of unskilled end users, while the latter can provide manufacturing and maintenance personnel with more powerful capabilities.