There are lots of ways to integrate Ethernet. Depending on the requirements of your system, you must make the proper tradeoffs.
Today's embedded systems designers and developers are increasingly asked to incorporate Ethernet connectivity into their systems. When enabling Ethernet connectivity, system designers must pay attention to critical product requirements and evaluate reference designs to ensure a competitive product.
Ethernet's ubiquity and longevity in connecting computers to a network makes it an attractive networking choice for embedded systems. Over the years, the cost of Ethernet connectivity has dropped significantly. In fact Ethernet is now fast becoming the “RS-232” of embedded applications, with unlimited service range and access.
The use of Ethernet offers many benefits–system designers can now reuse the Ethernet interface to perform product-service-related tasks that were once handled by RS-232 or similar interfaces. Aside from the obvious competitive advantages of an Ethernet-enabled system, from a system designer's perspective, the key advantage to connecting over Ethernet lies in the overall savings in software development. If system designers use standard software protocols over Ethernet, they could take advantage of a plethora of software that's already installed on many of today's computers and handheld devices, without worrying about compatibility between multiple operating systems.
Typical embedded Ethernet system
The block diagram in Figure 1 depicts the primary component of an Ethernet-enabled system–the Ethernet controller. This controller may be a separate, standalone device, or it may be integrated with the host microcontroller (MCU). The Ethernet controller transmits and receives data from the Ethernet cable and manages Ethernet protocol. All Ethernet controllers feature the MAC (media-access control) function to implement the Ethernet protocol.
Some controllers also include the PHY (physical layer) module to condition and drive the data signals. The PHY module interfaces to a signal transformer, which in turn connects to the RJ-45 Ethernet socket. The host controller receives data from the Ethernet controller and applies the necessary protocol rules. The host controller also formats outgoing data and places it into the Ethernet controller transmit buffer.
A MAC can interface to one or more PHYs over standard interfaces. These are called media independent interfaces (MIIs) and media-independent interface management (MIIM). However, designers don't have to worry about MII and MIIM if they utilize an Ethernet controller with both MAC and PHY integrated into one chip.
A commonly available RJ-45 connector with integrated transformer and LEDs makes it easy to connect to Ethernet. Designers can use the LEDs to indicate the network link and activity status on embedded Ethernet devices.
While an Ethernet network can support multiple transfer speeds of 10, 100, and 1,000 Mbits/s, for a majority of embedded applications, 10 Mbits/s is sufficient to support remote access, control, and monitoring. This is because most embedded systems only need to transfer a few tens of data bytes in real-time.
Occasionally, a device may need to transfer large amounts of data in the form of a log file or a new application code image. Also, determinism may not be an issue in embedded Web-server applications–a Web-server device may transfer large Web pages and therefore, a delay of one or two seconds in page downloads is tolerable.
Number of simultaneous users
As soon as the embedded system connects to a network, multiple users can request system access. System designers must be clear about the number of simultaneous users the system is expected to serve. Most embedded systems don't require many simultaneous users. For example, in applications involving system control, it's desirable to have a limited number of users to avoid system operation degradation. Handling many simultaneous users would require more resources on the device processor.
Alternatively, if a system is expected to serve many users, there might be access control requirements. Only certain users might be allowed to perform critical operations, while others might be just viewers. These requirements would also increase overall memory and processing requirements.
Selecting the right Ethernet controller
Traditionally, embedded applications have used a parallel interface mode to implement Ethernet connectivity. These include Industry Standard Architecture (ISA) bus-based Ethernet interface controllers with high pin counts (100 pins), interfacing with an 8-, 16-, or 32-bit MCU. Some designs have also used the Peripheral Component Interconnect (PCI) bus-based controllers to provide Ethernet connectivity. Although functional, these solutions aren't practical for use in compact embedded Ethernet applications where cost, size, and flexibility are major concerns.
Instead, a new generation of Ethernet controllers, which come in packages as small as 28 pins, are more efficient due to the utilization of serial interface technology between a host MCU and an Ethernet-interface chip for data exchange and control. These Ethernet controllers also have integrated MAC and PHY with a large RAM buffer. Further, the size of the integrated RAM buffer reduces the overall processing and storage requirements on the host controller.
There's yet another compact design option for implementing embedded Ethernet control. Some vendors offer both an Ethernet MAC and PHY integrated directly within an MCU, resulting in a single-chip Ethernet application solution. These MCUs come in varying package sizes for scalability, offering generous amounts of program memory, data memory, and peripherals (see Figure 2).
Embedded Ethernet hardware and software development
Until recently, complexity has deterred many embedded systems designers from deploying Ethernet connectivity in their applications. This needn't be the case–the many ready-made reference designs available from various silicon and third-party vendors can help designers get a head start in embedded Ethernet designs. These reference designs are based on vendors' Ethernet transceivers and help engineers evaluate embedded Ethernet applications. Most of them carry tutorial examples on a CD-ROM, with links to the vendors' homepages.
Software is vital for fast product development and is often an enabler in product-feature differentiation. For developing embedded Ethernet applications, designers have three options: develop their own, open source, or commercial.
Each option has advantages and disadvantages. System designers must understand all implications and select the optimal solution. Developing their own software takes time and money–typical optimized TCP/IP stacks with a few application modules may alone require many months of development time. In addition, designers must be prepared to spend time adding and maintaining new protocols and application modules.
On the other hand, many open source and commercial solutions exist. Although open-source solutions offer a variety of capabilities, their memory footprint and processing requirements may be out of reach for small embedded systems. Some may also require the use of a real-time operating system (RTOS), which in turn increases overall resource requirements. Some open-source solutions have licensing terms requiring full or partial source code disclosure. Another variation of open-source software is the software provided by the silicon vendors. A handful of these vendors provide complete TCP/IP software for free, as long as you use their products. When selecting vendor-supplied software, designers must ensure that it includes all necessary protocols and modules that their system will need.
System designers may also consider commercially available software solutions. Each has varying licensing and payment terms to suit particular needs. Some commercial solutions may require the use of a specific RTOS, which must be purchased separately. Beware though, adding an RTOS to support a TCP/IP stack may significantly increase the overall cost.
Whatever solution you choose, the availability of full source code is crucial to effectively debugging application code. Not only does the object-only (binary) solution prevent source-level debugging, but it inhibits the required understanding of the systems' limitations and behavior under certain conditions.
Implementation of TCP/IP stack architecture
A significant component in the design of an embedded Internet device is the TCP/IP stack firmware. An embedded Ethernet device can only support the processing of Ethernet packets. However, higher-layer protocols must be supported in firmware.
Figure 3 shows a simplified block diagram of a TCP/IP stack. The stack consists of multiple layers, and each layer contains multiple modules. Each layer is responsible for providing a specific networking function. The application layer, for example, is where various high-level applications interface with low-level stack layers.
Each module within a layer is responsible for managing a specific protocol. The Address Resolution Protocol (ARP), for example, is responsible for resolving the Internet Protocol (IP) address into the corresponding MAC address. Some modules are optional depending on the final application, while others are mandatory. For instance, Ethernet, ARP, and IP are mandatory. A system must also have either a user datagram protocol (UDP) or transmission control protocol (TCP) or both, depending upon the upper layer of the application selection.
Based on the TCP/IP block diagram, one way to implement the TCP/IP stack is to divide it into multiple layers. A strict TCP/IP reference model-based stack requires each layer to use the services of layers immediately below it. This design philosophy may be too taxing for small embedded systems.
On the other hand, to accelerate protocol processing, modules in an embedded TCP/IP stack may directly access one or more layers that aren't directly below it. Designers can decide when a layer bypasses its adjacent module for the services it needs, based on the amount of overhead and whether a given service needs intelligent processing before it can be passed to the next layer.
Remember that the TCP/IP stack is a “live” stack–some of its layers must perform some timed operations asynchronously. To meet this requirement and still stay relatively independent of the main application that relies on its services, designers must either use a multitasking RTOS, or develop a TCP/IP stack based on a technique called cooperative multitasking. Using this method, each task performs its job and returns its control to the next task.
In the interest of optimizing the stack, an embedded TCP/IP stack must be tightly integrated to an Ethernet controller. Most full-featured stacks retrieve Ethernet data packets into a host controller's RAM for processing. This approach increases RAM requirements on the host controller.
Instead, an embedded stack can use the controller's on-chip RAM as a buffer, until a higher-level module needs to access the data. As required by TCP specs, each TCP segment contains a checksum that covers the entire TCP packet, including the data area. To reduce RAM requirements, the TCP layer may use the controller RAM buffer to perform the checksum calculation. Some Ethernet controllers even provide hardware-based checksum engines to compute the packet checksum. This additional support can significantly decrease the total processing time of TCP and UDP packets.
The TCP/IP stack uses a concept called “socket” where application-layer modules can establish multiple virtual connections to remote nodes using one copy of the underlying transport layer module, such as UDP or TCP. An embedded stack with limited RAM can implement this concept using the “shared-socket buffer” approach. Instead of allocating a dedicated data buffer for each socket, the embedded stack only allocates one buffer and reuses it for multiple sockets. This approach, however, places a programming restriction that a socket must be fully processed and released before accessing the next data packet.
The choice of a user interface (UI) plays a key role in the final product's acceptance. There are security implications associated with each different UI, as well. Depending on the application, typical UI options include the Web server, e-mail, simple network management protocol (SNMP) agent, and short message service (SMS) interfaces. A home automation system may use a combination of Web-server, e-mail, and SMS interfaces, while a factory automation floor may use an SNMP interface.
A Web server is appropriate when on-demand monitoring and control are desired. Due to their content, Web pages are specifically designed to suit a human-machine interface (HMI). E-mail and SMS are also suitable HMI applications. If a standard machine-to-machine interface (MMI) is desired, SNMP is the best choice, which is specifically designed to be machine friendly and may use an off-the-shelf SNMP host (called a network management station).
A system may also use a custom host interface that implements a proprietary data protocol using UDP- or TCP-transport layers. A custom host interface is desirable when data throughput and confidentiality are a concern.
Looking closely at the SNMP option, although SNMP is a widely used management protocol for enterprise-computing networks, it can be made suitable for embedded systems. Due to the limited resources of small embedded systems, one must make tradeoffs in terms of protocol compliance and still keep it reasonably practical.
A key advantage of using SNMP protocol is the availability of multiple third-party PC-based monitoring software programs. The majority of the SNMP implementation utilizes UDP as its main transport layer. This is because, for embedded applications, UDP provides relatively small and simple transport services.
TCP, on the other hand, provides a more reliable transport with an increased program memory requirement. When employing a UDP, most of the SNMP-management applications perform extra timeout and error checking to ensure a reliable management connection. As a result, the choice of using UDP or TCP as a transport service really depends on the amount of resources available. For small embedded systems with limited program and data memory, UDP is the choice of transport.
Specifics for adding Ethernet connectivity
A few more things are essential to adding Ethernet connectivity to your design, such as a MAC address. Every Ethernet device must have its own unique MAC address, which is 48 bits long. The first 24 bits of the address are the organizationally unique identifier (OUI). The next 24-bit number of the address is the vendor-assigned ID. An OUI number can be requested directly from the IEEE at http://standards.ieee.org/regauth/oui/index.shtml.
There's a $1,650 fee to request an OUI number. A less-expensive option ($550) is to request an individual address block (IAB). But an IAB will only provide 4,096 unique addresses, versus 224 (more than 16 million) different addresses when using an OUI.
In the case of SNMP devices, a Private Enterprise Number must be obtained. This number is one of the nodes in the Internet Management Information Base (MIB), and is unique to each device maker. Interested parties must apply to the Internet Assigned Number Authority (IANA) at www.iana.org/cgi-bin/enterprise.pl to obtain a number. Unlike other registration processes, this is completely free. However, only one enterprise number per organization is allowed. When the number is received, designers can then create child nodes below this node and add as many sub-trees as they need.
There are two types of Ethernet cable–straight-through (also known as patch) and crossover. When connecting one embedded device directly to another (or PC-to-PC), a crossover cable must be used. When connecting an embedded device or a PC to a hub, switch, or router, a straight-through cable must be used.
When troubleshooting Internet applications, designers must be able to monitor network transactions to understand network activity. Designers may consider using Ethereal (www.ethereal.com), which is a free network protocol analyzer tool that's both powerful and easy to use. For testing for IEEE 802.3 compliance, visit the University of New Hampshire's Interoperability Laboratory (IOL-UNH, www.iol.unh.edu). There's no official IEEE 802.3 test-compliance program yet, but many consider the IOL-UNH testing service as the industry's de facto test house.
Nilesh Rajbharti is an engineering manager in the applications engineering department for PIC microcontrollers at Microchip Technology Inc. He has over 12 years of experience in computer hardware/software design and development. Nilesh holds an MBA in technology management and a bachelor of engineering degree in electronics and communications engineering. He can be reached at .
Case, J., M. Fedor, et al. “A Simple Network Management Protocol (SNMP): RFC 1157.” 1990.
McCloghrie, K. and M. Rose. “Management Information Base for Network Management of TCP/IP-based internets: MIB-II: RFC 1213.” 1991.
Rajbharti, Nilesh. “AN870–An SNMP Agent for the Microchip TCP/IP Stack.” Microchip Technology Inc., 2003.
Rajbharti, Nilesh. “AN833–Microchip TCP/IP Stack.” Microchip Technology, Inc., 2002.
Stevens, W. Richard. TCP/IP Illustrated Volume 1. Reading, Mass.: Addison-Wesley, 1994, pp. 359″389.
Tanenbaum, Andrew. Computer Networks (3rd ed.) . Upper Saddle River, NJ: Prentice Hall PTR, 1996, pp. 630″643.