[Design View / Design Solution]
Build A Real-Time Flash GUI For Embedded Network Devices
Flash is the obvious choice over HTML when it comes to real-time control and monitoring of Web pages that have rapidly changing dynamic content or animation.
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.
Reprints
)
