Listing 4 shows the implementation of the SSI function, getDIPVal. It reads the current settings of DIP switches and generates an appropriate ASCII representation. In this hardware environment, reading from the address 0xFF80 tells us the current DIP switch settings. A fixed value of 8 is returned for the length of the inserted ASCII text, as we will always process 8 bits. The output is "0" for switch is off, and "1" for switch is on.
To use this SSI function in a Web page and get an array of eight digits representing the settings of the DIP switches, we just have to insert something like the following into the HTML code:
<P>
Current settings of the DIP switches: <B><!‾‾#exec cgi="get_DIPVal"‾‾></B>
</P>
Listing 5 shows how the SSI functions are added to the CMX-MicroNet TCP/IP stack. To add such a get function, mn_gf_set_entry needs to be called with the string identifying the function (the same string as used in the Web page) and a function pointer to the C-function implementing this function.
Feedback With Forms: So far, we had the option of getting data from the application transmitted to the user's browser. We still needed a way to get commands from the user to the application. This function can be performed by standard HTML forms. Much like the SSI functions, the Web page must contain the tags to build a FORM and indicate the name of the POST function to be executed within the Web server.
Assume that we have a form with a text field for user input, and maybe a pull-down menu with a few items. Once the user hits the "Send" or "Submit" button, a POST request goes to the HTTP server with all variable settings squeezed into a single ASCII line. The format of this line is the same one used when passing variables in URLs:
variable1=value1&variable2=value2&variable3=value3...
If spaces are implemented in string variables, they have to be replaced by 20%.
Once the HTTP server receives such a POST message, it locates the application function matching the post request and executes it. The TCP/IP software eases the search for a specific variable in this ASCII line by providing search functions that allow the application function for that FORM to easily detect the variables and their current settings and to respond accordingly.
Listing 6 is an example of a function that's called by the HTTP server when a certain POST request is detected. In this case, the variables named d1 and d2 are detected and used to switch two LEDs on and off.
Listing 7 shows how the post functions become incorporated into the CMX-MicroNet stack. As with the previous function, the post function name string and a pointer to the post function must be passed on.
Continuous Refresh: By now, the user can view dynamic data from the embedded device and send data to it. However, all communication is user-driven as the user needs to initiate every request. Wouldn't it be nice to see a window constantly updating/refreshing itself with the dynamic data from the embedded device without the need for user intervention?
If one refresh every few seconds is sufficient, the HTML REFRESH tag can make the browser refresh the display automatically by re-requesting the Web page. But this causes overhead issues as the entire Web page gets transferred every time (also the static part) and doesn't allow faster updates.
Faster, more efficient window refresh cycles can be achieved using Java. A Java applet can establish an additional TCP/IP channel between the host computer and the embedded Web server. Because the implementation of this TCP/IP channel is customized on both ends of the communication, it can be highly optimized to transfer only the required data. In this application, we used it to transfer all data from the CAN/CANopen network in the embedded device. The Java applet implements a basic CAN monitor that constantly displays all the CAN/CANopen messages in the Web browser. Figure 2 is a screenshot of the results.
Security: One point not yet addressed is security. In this example, we implemented a PPP dial-up server, and thus disconnected the application physically from the Internet. To get access, a user must know the telephone number to dial and know the PPP login name and password. On the downside, the system in this application is never connected to the Internet. We always have just a point-to-point connection between the server and the host computer dialing in—creating a mini-Intranet.
Putting the system onto the "real" Internet would require implementing some additional security functionality, either directly into the system or into an external firewall-type device. (This can be done without any changes to the commercial TCP/IP stack. Only the security aspects of the design require changes to the code.)
Because so many diverse industries are involved in the development of embedded Internetworking solutions, it's unlikely that we will see a dominant standard any time soon. As a result, it's difficult to predict what the technology's usage will be in the future. However, implementing commercially available software and protocol stacks now will help reduce development time and speed integration of the involved network technology. It will also give designers the added flexibility to dynamically grow and change their systems as the technology evolves.
To download the listings, click Download the Code.