Copyright © 2006 Penton Media, Inc., All rights reserved.
Printing of this document is for personal use only.
Reprints

A critical concern for any embedded device is the user interface. Embedded network devices hold a tremendous advantage for creating an intuitive user interface by using a Web browser. Traditionally, this has been accomplished by using an embedded Web server on the embedded device and creating Web pages written in Hypertext Markup Language (HTML). HTML is very easy to understand and implement for static Web pages, but it’s a very poor option for rapidly changing dynamic content or animation.

Along with a brief overview of various Web-based user interface platforms, this article offers a detailed implementation of a platform created in Adobe Flash. Flash can be used to create an amazing look and feel. If you can imagine it, you can probably create it in Flash, whether you want animated controls or a simple interface without the flicker of HTML page updates. We will build a graphical user interface (GUI) that will control and monitor an embedded network device.

Our example uses the NetBurner MOD5270LC Eclipse Ethernet Development Kit (available at www.netburner.com for $99), but the ideas and code can be used with other embedded network devices as well. The project was created with a 30-day evaluation of the Adobe Flash development environment, which you can download at Adobe’s Web site. Thirty days is more than enough time to acquire enough knowledge of Flash to create a complete solution.

WHAT ABOUT JAVA, AJAX, AND DYNAMIC HTML?
Before we get to the code, lets take a quick detour and address why we don’t build our GUI using Ajax, Java, or a simple dynamic Web page. Dynamic Web pages are great if you just want a simple configuration page or a device status snapshot. If, however, you want this page to give you real-time feedback, you’re out of luck. The best you can do is set the page to refresh every second or so. However, you end up with a page-flickering resource hog. By continually refreshing a page, the entire page is reloaded, which means bandwidth and system resources are used.

One idea would be to use Ajax to cleverly update only the portions of the page that need updating. The problem, though, is it would still require continuous polling of the network device server to check for updates.

A Java applet would solve this problem by providing an interface with a persistent TCP connection. We wouldn’t have to serve the entire page. The Java applet is a program that runs in the Web browser. It can create a persistent TCP connection back to the embedded device and obtain continuous device status information. The Java applet updates the display in the Web browser, so there’s no page reloading or flicker, which is the case with HTML. The problem with Java, JavaScript, and Ajax is that their functionality may be disabled, or they can look or run differently with different platforms and versions.

As a result, Flash becomes a very interesting option with significant advantages for the presentation of a user interface: You can easily open a persistent TCP connection, the application will look the same on any platform it runs on, it excels at animation and graphics, and it comes installed on almost everyone’s browser.

APPLICATION OVERVIEW
Figure 1 shows the Web-based user interface we will create in this article. When the user rolls the mouse pointer over LEDs, the LED lights up immediately on both the NetBurner and the Web page. The update is so fast that it feels instantaneous to the user. When a dip switch is changed on the NetBurner, the image of the switch smoothly transitions from one position to the other as an animation, rather than just showing up in the new position as is done with two on/ off images.

There is a status window in the upper right corner that verifies an active connection with the NetBurner. In addition, a blinking heartbeat light flickers each time a heartbeat response is received from the NetBurner device.

There’s no programming required on the client/Web browser side (e.g., a Windows PC). The Flash application is stored in the Net- Burner embedded Web server, and it is served to the host Web browser when a connection is made.

The application consists of the following components running on the Net- Burner device:

• Web server to serve the Flash application on the initial request.
• TCP server task that waits for the incoming TCP data connection from the Flash application.
• Flash application that runs in the host’s Web browser and opens a new TCP data connection back to the Net- Burner device.

THE NETBURNER WEB SERVER
At the highest level, we have a PC running a Web browser like Firefox or Internet Explorer that connects to the NetBurner Web server. The Web server sends the requested information: the HTML page and Flash application. The Web browser then runs the Flash application, which creates a TCP connection back to the NetBurner device (Fig. 2).

On a much lower level, the process begins when you enter a URL in the Web browser: for example, www.myurl. com. Next, the TCP/IP stack on the PC executes a Domain Name Server (DNS) lookup to convert the name into an IP address. A TCP connection is then established with the Web server on port 80, the “well known port number” for a Web server.

If you look in the URL address line of your Web browser, you will normally see the URL begin with “http://”. This tells the Web browser to use the Hypertext Transfer Protocol (HTTP). HTTP is a protocol that defines the rules for Web pages. It defines commands such as “GET” to tell the Web server which Web page it wants and “POST” to send data to the Web server in a HTML form.

Continue to page 2

Once the TCP connection is established from the browser to the Web server, the requested HTML page is sent and the Web server closes the TCP connection. This is why dynamic content is hard to do with HTML—there’s no persistent TCP connection by which the Web browser and server can communicate. However, this is where our Flash application and some programming on the NetBurner device enter the picture.

At this point, we’ve established that HTTP is a protocol that relies on a TCP connection. We can easily create another TCP server on the NetBurner device that runs in addition to the Web server, as long as we give this additional TCP server a different port number. As an example, let’s use port 10,000. We can now think of the NetBurner device as running two TCP servers: one that’s listening on port 80 that can speak the HTTP protocol, and another on port 10,000 that can speak our own custom protocol known to the Flash application to communicate LED and dip switch positions, as well as the heartbeat.

We used HTTP to get the Flash application from the Web server. Once the Flash application starts, it creates an outgoing TCP connection to the NetBurner device’s IP address on port 10,000. Unlike HTTP, our connection will not terminate until the Flash application tells it to terminate. It will be used to continuously send data back and forth between the Flash application and Net- Burner device, providing remote control and monitoring capabilities. Our custom protocol is very simple—just single characters and numbers representing the illuminated LEDs and dip switch positions. This protocol will be described further in the Flash application section.

Figure 3 shows this sequence of events. While the connections for both the Web server and Flash TCP server are both TCP, the arrow designations of HTTP and TCP are used to distinguish between Web server communication and Flash TCP server communication.

THE FLASH TCP SERVER
The NetBurner device will have two TCP servers: the HTTP Web server and our custom TCP server to communicate with the Flash application. By “server,” we mean we will listen for an incoming connection on a particular port number, in this case port 10,000. The Flash application will be the “client,” which means it initiated the TCP connection to the server. Once the connection is established, each side can send or receive data.

The NetBurner TCP/IP stack provides an API for the Web server, which we start with the StartHTTP( ) function call. To create the Flash application server, we will use the µC/OS real-time operating system included with the NetBurner development tools ( Fig. 4). The function call OSCreateTask( ) is used to create a new task that runs the function FlashConnectionServer( ). This function is in an infinite while( ) loop. It blocks “waiting for an incoming connection” from the Flash application with the TCP/IP listen( ) function, which returns a handle to the TCP connection that we call fdnet. The handle is used to send and receive data through the TCP connection.

The FlashConnectionServer task was written so the Flash application is the master. The task blocks on a ReadWith- Timeout( ) function waiting for incoming data. When data is received, it’s parsed using the simple single character command protocol: ‘~’ = heartbeat, ‘$’ = update LEDs, ‘?’ = status update.

If an LED command was received, the UpdateLeds( ) function is called to update the physical LEDs on the development board. If the heartbeat request was received, a ‘!’ character is sent back to let the Flash application know that the device is still alive. The dip switch settings are returned with the status response.

Commands will continue to be parsed as long as fdnet is valid. When the Flash application is closed, fdnet will be closed and the FlashConnectionServer will loop back to the listen( ) function and block until a new connection request is received.

THE FLASH APPLICATION
The purpose of the Flash application is to provide a visually appealing user interface to the LEDs and switches on the development board. Flash accomplishes this in two ways. First, it can run as an application in the Web browser and create a permanent TCP connection back to the NetBurner device. Unlike HTTP, this enables a constant real-time flow of data between the user interface and the hardware. Second, it lets us create smooth animation to display the data. The LEDs turn on and off, and the switches glide smoothly between their on/off positions.

Flash applications are written in ActionScript. This language is owned by Adobe, and it contains a large library of functions that can be used to develop Web content. To create a real-time client TCP connection to our server, we will use the ActionScript XMLSocket( ) object. Code 1 shows the XMLSocket( ) object and associated methods.

To implement our Flash application, we create a XMLSocket( ) object and use the methods to connect, send, and receive data. The callback functions will link to our own code so we can send initialization instructions when a connection is made and process data when it’s received from the server. Code 2 gives the callback functions assignments.

RUNNING THE FLASH APPLICATION
A Flash application is an event-driven collection of functions (Fig. 5). There’s no main processing loop. Once the Flash application is downloaded into the browser, it automatically starts. It first declares variables with the “var” keyword and does some initialization of the viewable objects. From that point the setinterval( ) function is called to continuously call the keepConnectionAlive( ) function every 1000 ms:

setInterval(keepConnectionAlive, 1000);

The keepConnectionAlive( ) function will initiate a TCP connection if one doesn’t exist or perform the 1000-ms heartbeat function if a connection is already made. Once the connection is established, the following events are handled:

LED events: When the mouse rolls over one of the eight LED images, a Flash event is generated that calls SendLed( ). The link between the image and this function is created by editing the properties of the LED image. This function verifies when a connection is established and sends the command to change the LED to the server (Code 3).

Once the server receives the command and modifies the LED, it replies with a confirmation. The reply is received by the myOnData( ) function with a ‘$’ command and status of the LEDs and switches. UpdateLeds( ) and UpdateSwitches( ) are then called to update the images in the Flash application (Code 4).

Switch events: A switch event is created when someone changes a switch position on the NetBurner development board and a message is sent to the Flash application through the TCP socket. The myOnData( ) function is called, which calls UpdateSwitches( ). The switch positions are then updated on the screen using a simple Flash animation sequence.

Heartbeat event: We use the idea of a “heartbeat” to verify a constant connection with the server. The “~” is sent to the server, which must be acknowledged by the receipt of a “!” character. If more than three heartbeat messages are ignored, the connection is closed and an attempt is made to reconnect.

In summary, the demand for visually appealing and easy-to-use Web interfaces on embedded systems is mushrooming. Creating a GUI in Flash can be very easy to implement, to the point of being visually stunning. Flash is supported in 98% of desktop computers, and updates are quick and easy for all of the major browsers.

Flash was created for display and animation. Once you know the underlying TCP socket function calls, it takes very little code to implement a TCP client and provide a display that people will want to show off.