Network processors: CAN or Ethernet?

Although any microprocessor with a network interface can arguably be classified as a network processor, any sophisticated processor should support one of the widely adopted communications buses such as Ethernet or CAN (Control Area Network). In choosing the appropriate network bus to support, a designer should ask several questions: Will both CAN and Ethernet continue to be widely adopted? If ...

By Colin MacDonald October 1, 2003

Although any microprocessor with a network interface can arguably be classified as a network processor, any sophisticated processor should support one of the widely adopted communications buses such as Ethernet or CAN (Control Area Network).

In choosing the appropriate network bus to support, a designer should ask several questions: Will both CAN and Ethernet continue to be widely adopted? If so, how will they co-exist? And finally, how will the choice of buses affect the design of network processors? We can answer these questions by comparing technical features of the buses and examining developments in the marketplace.

This processor has two roles; a networked embeded controller and an Ethernet-CAN bridge.

The fact that the CAN protocol is message-based and not address-based has several benefits. First, this approach supports the use of modular electronics—transmitting controllers don’t need to know the receivers and vice versa. Second, ease of servicing and upgrading is improved. Third, this allows multiple nodes to receive information from the same message; for example, measurements needed by several controllers can simply be broadcast, thus minimizing bandwidth used. Another bandwidth-saving feature of the CAN protocol is called Remote Transmit Request, which permits a node to request that information be sent from other nodes. This can be used, for example, during the execution of a diagnostic suite. Rather than having all monitoring stations periodically send status information, one can request status information from non-critical nodes only when actually required.

Another strength of the CAN bus is termed Fault Confinement. This prevents the whole production line from going down when a problem occurs with, say, a room temperature sensor. CAN nodes are able to perform self-diagnoses and, depending on the severity of the problem (i.e., permanent/temporary), can transition into one of three modes, including shutting down completely. This feature prevents a bad node from continuously signaling faults and halting communications. The greatest benefit of Ethernet is the easy access to the TCP/IP protocol stack within network processors from local PCs and workstations, by virtue of the Internet, the other side of the world. Given sufficient processing power, software, and random access memory, networked processors can actually run Web servers. In addition, longer segment lengths and higher bandwidth allow for physically larger networks with greater information carrying capacity and the availability of low-cost network cards. Microsoft Windows TCP/IP sockets make the development of interfacing software much simpler, faster, and less costly.

Ethernet’s CSMA/CD arbitration scheme does not include a non-destructive priority arbitration, and message latency or deterministic behavior cannot be guaranteed. However, in many network situations, real-time response is not important and a number of ways to improve Ethernet’s performance exist, for example, employing intelligent switches to forward only those frames intended for the node connected to the switch. These performance improvement capabilities, coupled with the use of higher transmission rate, will reduce bandwidth utilization and opportunities for collisions. In terms of electromagnetic interference, standard Ethernet does not have sufficient immunity to be used near high-energy equipment on the factory floor (such as welders), and its connectors are considered barely rugged enough for the office space. However, fiber-optic cable, which is decreasing in cost, provides an excellent solution, and RJ-45 connectors enhanced for strength and durability are available.

Weighing the options

Now, back to the original questions:

Will both buses continue to be widely adopted and, if so, how will they co-exist? One of the initial barriers adopting Ethernet as a fieldbus was cost. However, integration of an Ethernet controller along with CPU, NVM, RAM, and peripherals has dramatically reduced system cost over the past few years.

Today, Ethernet physical interfaces are not commonly integrated, due to different processing requirements, but the price of these too has dropped significantly with increased sales. The lowering of the cost barrier, along with availability of protocols, such as BACnet and Ethernet/IP, will lead to an increased market for network processors supporting Ethernet.

CAN will also continue to be successful for several reasons—it requires about a third of the silicon real estate of Ethernet; it needs a smaller CPU; and its physical interface devices are less expensive.

Many cost-sensitive devices, such as valves, simply do not need extra bandwidth or an Internet connection. Also, CAN still has a considerable advantage with respect to real-time processing and noise immunity.

How will the buses co-exist? No doubt many networks will continue to use either CAN or Ethernet, but not both. If one bus satisfies all the required features of a network, no incentive for change exists. More exciting, however, is the development of hybrid networks that combine Ethernet’s connectivity and bandwidth with CAN’s low-cost and deterministic behavior.

How will the two buses affect the design of network processors? Small and inexpensive CAN controllers with 8/16-bit CPUs will continue to be the choice for simple, networked devices, especially commodity items. However, more highly integrated network processors with an Ethernet controller can add a CAN interface for little extra cost. That allows the device to function with Ethernet, CAN, or to act as a bridge between the two buses. MCF5282 from Motorola is such a device (see diagram).

Author Information

Colin MacDonald is a design engineer at Motorola’s 32-bit Embedded Controller Division, Austin, TX.