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.