Embedded networking and Internetworking implementations are without a doubt on the rise. However, anecdotal evidence from engineers, gathered at trade shows and seminars, indicates that the embedded industry is still in the exploration stage. Everybody knows that they will eventually need some type of Internet connectivity, but it's really not a priority. Yet, decisions to add Internetworking capability now may eliminate the need for costly redesign in the near future.
If an embedded system already has access to a PC of some sort (either connected to one or maybe using an embedded PC within), supplying Internet access isn't really a challenge. Commercially available software and protocol stacks can greatly reduce development time and speed integration of the involved network technology, even for tiny 8-bit devices. Today, the greatest hurdle for embedded Internetworking isn't the technology itself, but rather predicting its usage in the future.
This article explores some of the variables involved in adding Internet connectivity to an 8-bit device and discusses current developments in the field of embedded Internetworking. It also offers an application example giving a closer look into one possible route for Internet-enabling embedded devices, based on the implementation of a TCP/IP-to-CANopen (Controller Area Network) gateway.
Internet Connectivity Parameters: Due to a lack of standards regarding "remote-access" implementation for embedded systems, the number of technical variations is great. For example, which physical media should one assume? Ethernet? If so, is there a DHCP server to assign an Internet-protocol (IP) address, or must a static IP address be assigned? Or if the choice is to dial-up via a modem, which phone number and ISP will be chosen? What protocols and services will be necessary for support (e-mail, Web server, and/or FTP server), and what about reliability and security issues?
Note: To address the standardization of methods and protocols used to access embedded devices, the authors of this article currently work with several companies and universities on an Internet Draft that might eventually become an RFC (Request For Comments) published with the RFC editor (www.rfc-editor.org). For more information on embedded Internetworking and to read the latest about the Internet Draft on "Embedded Internetworking with Remote Access," go to www.embeddedinternetworking.com.
Perhaps the biggest challenge in determining a design route is the "gateway question." Do we allow our embedded device to directly communicate with the Internet, or will all communication be funneled through a gateway? If a gateway is used, where does it come from? Is it an external product, or part of the embedded system—potentially running on one of many controllers within the application?
The preceding question highlights a trend in the embedded industry where embedded systems often consist of several microcontrollers communicating with each other. This is especially true for any machinery with multiple sensors and/or actuators. If a local network already exists (something like a proprietary serial bus, CAN/CANopen, DeviceNet, LON, or USB—just to name a few), the logical approach is to try to implement a gateway between the local network and the Internet. This approach gives "remote access" to all local nodes.
Implementing A TCP/IP-To-CANopen Gateway On An 8-Bit Processor: When Philips Semiconductors approached the Embedded Systems Academy to prove that such embedded Internetworking gateway applications could be implemented on a regular 8051 microcontroller, we accepted the challenge—and designed and built a prototype of a gateway between the Internet and a CAN/CANopen network (Fig. 1).
CAN and CANopen were chosen due to their increasing popularity in embedded machine-control applications. CAN interfaces are available directly on-chip (with a wide selection of 8- and 16-bit microcontrollers from many manufacturers). Consequently, developers can most likely find a derivative of their favorite microcontroller that has an on-chip CAN interface. Other than a transceiver and the connector, no hardware is needed to join such a microcontroller to a CAN bus, which only requires a twisted pair as physical media.
As is usual with today's embedded projects, time-to-market is an issue even in a "proof-of-concept" project. Due to customer requirements, the prototype (based on the Philips 8xC591 Rapid Development Starter Kit from Phytec) had to be completed in less than three weeks.
This implementation of a network protocol stack is a perfect example of how to shorten time-to-market by selecting off-the-shelf software products. Instead of re-inventing the wheel and writing the network protocol stacks for TCP/IP and CANopen ourselves, we chose CMX-MicroNet. This is a commercial, off-the-shelf implementation, optimized for 8-bit and 16-bit microcontrollers. It also includes all source files.
Adapting The Software: Once the hardware components and development tools were in place, implementation was straightforward. Using #define statements, the source code was configured to enable/disable certain protocols and features. We enabled modem and point-to-point protocol (PPP) support, as the 8051's serial channel was connected to an external modem and we wanted to allow users to dial-up the system. Furthermore, we selected TCP (versus UDP) as the main transport protocol and enabled the HTTP Web server.After making the local adjustments to the timers (required to select a baud rate and implement a timeout based on multiples of milliseconds) and assigning some fixed IP addresses to both the local server and dial-up host, we quickly finished the microcontroller-specific adaptations. Before activating the Web server, we needed to have some Web pages in place. Fortunately, they can be written in standard HTML.
We used the conversion utility HTML2C to convert any DOS/Windows file—HTML, GIF, and so on—into a pair of .h and .c files. These were directly included in the project and easily added to the minimized virtual file system implemented within the TCP/IP software stack. Listings 1, 2 and 3 show the .h and .c files created by the HTML2C and how these files get inserted into the minimal file system. Listing 3 also shows the MicroNet function of the virtual file system that adds an entry to the list of files. In this example the files index.htm, mixed.htm, and canopnrd.htm are added to the file system.We were then ready for the first test. Our computer's internal modem was connected via a telephone line to the external modem that was connected to the 8051's serial port. Using an in-circuit emulator we loaded the code to the application and hit "GO." On the computer side we had to specify a new dial-up connection using the fixed, assigned IP number we specified earlier in the code.
Using the login name and password specified in the code, we had a successful dial-up. We started the Web browser. In the URL field, we typed in the IP address of the 8051 board. Because this is a closed system with no domain name server, the 32-bit IPv4 addresses must be used to directly identify the connected computers. Our two Web pages were displayed as static files with a small graphic served by an 8051 running at 12 MHz.
But the excitement cooled off pretty quickly. We were only serving up plain, static Web pages with no application-specific data. The next step was implementing Web pages that were dynamically updated by the server and displayed data from the application.
Dynamic Web Pages: To create dynamic Web pages, we employed a method similar to one used by many "full-grown" Web servers to transmit dynamic pages: Server Side Includes (SSI). Using some special HTML tags to indicate SSI, an HTML page can be marked up to insert dynamic data in place of the tags. The SSI tag itself indicates the name of a function that the Web server needs to call locally to get access to the dynamic data. So, for each SSI tag used, a function must be implemented within the application that will be called from the server. The syntax for these SSI tags is:
The implementation works as follows: During the initialization phase, the TCP/IP software builds up a list of all the applications with SSI functions. The entire process of requesting dynamic Web pages involves:
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:
Current settings of the DIP switches: 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.