Single-Chip, Multi-Protocol Switch for Intelligent Apps

Analog Devices recently introduced a real-time Ethernet, multi-protocol (REM) switch chip Ethernet connectivity solution for intelligent factory applications. Well suited for a variety of connected motion applications, you can use the “TSN-ready” (time sensitive networking) fido5000 with any processor, any protocol, and any stack.

The fido5000 two-port embedded Ethernet switch’s features, specs, and benefits include:

  • Reduces board size and power consumption while improving Ethernet performance at the node under any network load condition.
  • Attaches to Analog’s ADSP-SC58x, ADSP-2158x, and ADSP-CM40x motion control processors
  • Supports PROFINET RT/IRT, EtherNet/IP with beacon-based DLR, ModbusTCP, EtherCAT, SERCOS, and POWERLINK.
  • Achieves cycle times below 125 µs
  • Includes drivers for simple integration with any Industrial Ethernet protocol stack

The fido5100 is scheduled for full production in September 2017 and will cost $6 each in 1,000-piece quantities. The fido5200 (EtherCAT Capable) is also scheduled for full production in September 2017 and will cost $8 each in 1,000-piece quantities.

Source: Analog Devices

Simplified, Cost-Effective EtherCAT Implemenation with XMC4300 Microcontrollers

The Infineon Technologies XMC4300 microcontroller series simplifies EtherCAT implementation complexity and cost. Developed for cost-sensitive industrial applications, the XMC4300 is well suited for a variety of applications, such as factory automation, industrial motor control, and robotics.Infineon EtherCAT

Like Intineon’s XMC4800 series, the XMC4300 features an integrated EtherCAT node on an ARM Cortex-M processor with on-chip flash and analog/mixed signal capabilities. Neither the XMC4300 nor XMC4800 require oadditional components such as dedicated EtherCAT ASIC, external memory, or a quartz clock generator to start the EtherCAT slave controller. An integrated PLL supplies the EtherCAT IP with the necessary 25-MHz clock. Code executes from the Cortex-M4 processor at 144 MHz from the integrated RAM or flash memory.

You can use the XMC4300 and XMC4800 in mixed networks with CAN and EtherCAT because they allow a gateway from CAN to EtherCAT via through DMA transfers. In addition to 256 KB of flash memory and 128 KB of RAM memory, the XMC4300 features two CAN nodes with up to 64 message objects to be organized into send/receive FIFO. In addition, the XMC4300 series is certified for an ambient temperature of up to 125°C.

The two devices in the XMC4300 series vary in temperature range, with up to 85°C and up to 125°C, respectively. Offered in an LQFP-100 package, they are pin- and code-compatible with devices in the XMC4800 series.

Infineon offers a development board, the XMC4300 Relax EtherCAT Kit, and software development tools for immediate EtherCAT node setup. The XMC4300 Relax EtherCAT Kit is equipped with an XMC4300 and an on-board debugger, EtherCAT, CAN node, and USB. For software development, you can use the DAVE development environment with libraries for low-level drives and apps free of charge. For EtherCAT, DAVE uses Slave Stack Code (SSC) from Beckhoff. In addition to the free development environment, third-party manufacturers offer commercial EtherCAT slave stacks.

Source: Infineon Technologies

EtherCAT Slave Controller with Integrated PHYs for the Internet of Things

Microchip Technology’s LAN9252 is a stand-alone EtherCAT slave controller with two 10/100 PHYs. Its dual 10/100 Ethernet transceivers support both fiber and copper, along with cable diagnostics capabilities. In addition, the LAN9252 supports traditional Host Bus and SPI/SQI communication, along with standalone digital I/O interfaces, enabling you to select from a wide range of microcontrollers when implementing the real-time EtherCAT communications standard. Additionally, the LAN9252 reduces system complexity and cost for developers using EtherCAT in factory-automation, process-control, motor/motion-control and Internet of Things (IoT) industrial-Ethernet applications.Microchip LAN9252 EtherCAT

The LAN9252 EtherCAT slave controller includes 4 KB of Dual-Port RAM (DPRAM) and three Fieldbus Memory Management Units (FMMUs). It also includes cable diagnostics support that allows field service technicians to rapidly and effectively diagnose line faults and provides for fiber connectivity. This EtherCAT slave controller is available in commercial, industrial and extended industrial temperature ranges, in low pin count and small body size QFN and QFP-EP packages.

To enable development with the LAN9252, two Microchip evaluation boards supporting various system architectures are available. The systems demonstrate how to interface to the LAN9252 through basic I/O connections or to microcontrollers such as the 32-bit PIC32MX family via serial communications. A Software Development Kit (SDK) is also available. The boards—EVB-LAN9252-HBI and EVB-LAN9252-DIGIO—cost $300 each.

The LAN9252 EtherCAT slave controller is available for sampling in 64-pin QFN and QFP-EP packages, starting at $7.01 each, in 10,000-unit quantities.

Source: Microchip Technology

New XMC4800 Microcontrollers with EtherCAT Technology Support Industry 4.0

Infineon Technologies AG has launched a new XMC4800 series of 32-bit microcontrollers with on-chip Ethernet for Control Automation Technology (EtherCAT) node. With its real-time capability, the XMC4800 series is intended to drive networked industrial automation and Industry 4.0 applications.Infineon XMC4800

The EtherCAT node is integrated on an ARM Cortex-M-based microcontroller with on-chip flash and analog/mixed signal capability. The XMC4800 series comprises at least 18 members varying in memory capacity, temperature range and packaging. All XMC4800 microcontrollers will be AEC Q100 qualified, making them also suited for use in commercial, construction, and agricultural vehicles.

The XMC4800 series is a member of the XMC4000 family, which uses the ARM Cortex-M4 processor and was specifically developed for use in the automation of manufacturing and buildings as well as electric drives and solar inverters. The XMC4800 series offers a seamless upgrade path to EtherCAT technology with pin and code compatibility to the established XMC4000 microcontrollers. The XMC4800 enables the use of EtherCAT under the harsh condition of up to 125°C ambient temperature.


With the integration of the EtherCAT functionality, the XMC4800 enables the most compact design without need for a dedicated EtherCAT ASIC, external memory and clock crystal. It offers a 144-MHz-CPU, up to 2 MB of embedded flash memory, 352 KB of RAM and a comprehensive range of peripheral and interface functions. The peripherals include four parallel fast 12-bit A/D converter modules, two 12-bit D/A converters, four delta sigma demodulator modules, six capture/compare units (CCU4 and CCU8), and two positioning interface modules. In addition to its EtherCAT functionality, its communication functions comprise interfaces for Ethernet, USB, and SD/MMC. Also, the XMC4800 series offers six CAN nodes, six serial communication channels, and one external bus interface for communication. The three package options are LQFP-100, LQFP-144, and LFBGA-196.

Samples of the series XMC4800 with EtherCAT technology will be available in August 2015. Volume production is scheduled for Q1 2016.

Source: Infineon 



Seven-Controller EtherCAT Orchestra

When I first saw the Intel Industrial Control in Concert demonstration at Design West 2012 in San Jose, CA, I immediately thought of Kurt Vonnegut ‘s 1952 novel Player Piano. The connection, of course, is that the player piano in the novel and Intel’s Atom-based robotic orchestra both play preprogrammed music without human involvement. But the similarities end there. Vonnegut used the self-playing autopiano as a metaphor for a mechanized society in which wealthy industrialists replaced human workers with automated machines. In contrast, Intel’s innovative system demonstrated engineering excellence and created a buzz in the in the already positive atmosphere at the conference.

In “EtherCAT Orchestra” (Circuit Cellar 264, July 2012), Richard Wotiz carefully details the awe-inspiring music machine that’s built around seven embedded systems, each of which is based on Intel’s Atom D525 dual-core microprocessor. He provides information about the system you can’t find on YouTube or hobby tech blogs. Here is the article in its entirety.

EtherCAT Orchestra

I have long been interested in automatically controlled musical instruments. When I was little, I remember being fascinated whenever I ran across a coin-operated electromechanical calliope or a carnival hurdy-gurdy. I could spend all day watching the many levers, wheels, shafts, and other moving parts as it played its tunes over and over. Unfortunately, the mechanical complexity and expertise needed to maintain these machines makes them increasingly rare. But, in our modern world of pocket-sized MP3 players, there’s still nothing like seeing music created in front of you.

I recently attended the Design West conference (formerly the Embedded Systems Conference) in San Jose, CA, and ran across an amazing contraption that reminded me of old carnival music machines. The system was created for Intel as a demonstration of its Atom processor family, and was quite successful at capturing the attention of anyone walking by Intel’s booth (see Photo 1).

Photo 1—This is Intel’s computer-controlled orchestra. It may not look like any musical instrument you’ve ever seen, but it’s quite a thing to watch. The inspiration came from Animusic’s “Pipe Dream,” which appears on the video screen at the top. (Source: R. Wotiz)

The concept is based on Animusic’s music video “Pipe Dream,” which is a captivating computer graphics representation of a futuristic orchestra. The instruments in the video play when virtual balls strike against them. Each ball is launched at a precise time so it will land on an instrument the moment each note is played.

The demonstration, officially known as Intel’s Industrial Control in Concert, uses high-speed pneumatic valves to fire practice paintballs at plastic targets of various shapes and sizes. The balls are made of 0.68”-diameter soft rubber. They put on quite a show bouncing around while a song played. Photo 2 shows one of the pneumatic firing arrays.

Photo 2—This is one of several sets of pneumatic valves. Air is supplied by the many tees below the valves and is sent to the ball-firing nozzles near the top of the photo. The corrugated hoses at the top supply balls to the nozzles. (Source: R. Wotiz)

The valves are the gray boxes lined up along the center. When each one opens, a burst of air is sent up one of the clear hoses to a nozzle to fire a ball. The corrugated black hoses at the top supply the balls to the nozzles. They’re fed by paintball hoppers that are refilled after each performance. Each nozzle fires at a particular target (see Photo 3).

Photo 3—These are the targets at which the nozzles from Photo 2 are aimed. If you look closely, you can see a ball just after it bounced off the illuminated target at the top right. (Source: R. Wotiz)

Each target has an array of LEDs that shows when it’s activated and a piezoelectric sensor that detects a ball’s impact. Unfortunately, slight variations in the pneumatics and the balls themselves mean that not every ball makes it to its intended target. To avoid sounding choppy and incomplete, the musical notes are triggered by a fixed timing sequence rather than the ball impact sensors. Think of it as a form of mechanical lip syncing. There’s a noticeable pop when a ball is fired, so the system sounds something like a cross between a pinball machine and a popcorn popper. You may expect that to detract from the music, but I felt it added to the novelty of the experience.

The control system consists of seven separate embedded systems, all based on Intel’s Atom D525 dual-core microprocessor, on an Ethernet network (see Figure 1).

Figure 1—Each block across the top is an embedded system providing some aspect of the user interface. The real-time interface is handled by the modules at the bottom. They’re controlled by the EtherCAT master at the center. (Source. R. Wotiz)

One of the systems is responsible for the real-time control of the mechanism. It communicates over an Ethernet control automation technology (EtherCAT) bus to several slave units, which provide the I/O interface to the sensors and actuators.


EtherCAT is a fieldbus providing high-speed, real-time control over a conventional 100 Mb/s Ethernet hardware infrastructure. It’s a relatively recent technology, originally developed by Beckhoff Automation GmbH, and currently managed by the EtherCAT Technology Group (ETG), which was formed in 2003. You need to be an ETG member to access most of their specification documents, but information is publicly available. According to information on the ETG website, membership is currently free to qualified companies. EtherCAT was also made a part of international standard IEC 61158 “Industrial Communication Networks—Fieldbus Specifications” in 2007.

EtherCAT uses standard Ethernet data frames, but instead of each device decoding and processing an individual frame, the devices are arranged in a daisy chain, where a single frame is circulated through all devices in sequence. Any device with an Ethernet port can function as the master, which initiates the frame transmission. The slaves need specialized EtherCAT ports. A two-port slave device receives and starts processing a frame while simultaneously sending it out to the next device (see Figure 2).

Figure 2—Each EtherCAT slave processes incoming data as it sends it out the downstream port. (Source: R. Wotiz))

The last slave in the chain detects that there isn’t a downstream device and sends its frame back to the previous device, where it eventually returns to the originating master. This forms a logical ring by taking advantage of both the outgoing and return paths in the full-duplex network. The last slave can also be directly connected to a second Ethernet port on the master, if one is available, creating a physical ring. This creates redundancy in case there is a break in the network. A slave with three or more ports can be used to form more complex topologies than a simple daisy chain. However, this wouldn’t speed up network operation, since a frame still has to travel through each slave, one at a time, in both directions.

The EtherCAT frame, known as a telegram, can be transmitted in one of two different ways depending on the network configuration. When all devices are on the same subnet, the data is sent as the entire payload of an Ethernet frame, using an EtherType value of 0x88A4 (see Figure 3a).

Figure 3a—An EtherCAT frame uses the standard Ethernet framing format with very little overhead. The payload size shown includes both the EtherCAT telegram and any padding bytes needed to bring the total frame size up to 64 bytes, the minimum size for an Ethernet frame. b—The payload can be encapsulated inside a UDP frame if it needs to pass through a router or switch. (Source: R. Wotiz)

If the telegrams must pass through a router or switch onto a different physical network, they may be encapsulated within a UDP datagram using a destination port number of 0x88A4 (see Figure 3b), though this will affect network performance. Slaves do not have their own Ethernet or IP addresses, so all telegrams will be processed by all slaves on a subnet regardless of which transmission method was used. Each telegram contains one or more EtherCAT datagrams (see Figure 4).

Each datagram includes a block of data and a command indicating what to do with the data. The commands fall into three categories. Write commands copy the data into a slave’s memory, while read commands copy slave data into the datagram as it passes through. Read/write commands do both operations in sequence, first copying data from memory into the outgoing datagram, then moving data that was originally in the datagram into memory. Depending on the addressing mode, the read and write operations of a read/write command can both access the same or different devices. This enables fast propagation of data between slaves.

Each datagram contains addressing information that specifies which slave device should be accessed and the memory address offset within the slave to be read or written. A 16-bit value for each enables up to 65,535 slaves to be addressed, with a 65,536-byte address space for each one. The command code specifies which of four different addressing modes to use. Position addressing specifies a slave by its physical location on the network. A slave is selected only if the address value is zero. It increments the address as it passes the datagram on to the next device. This enables the master to select a device by setting the address value to the negative of the number of devices in the network preceding the desired device. This addressing mode is useful during system startup before the slaves are configured with unique addresses. Node addressing specifies a slave by its configured address, which the master will set during the startup process. This mode enables direct access to a particular device’s memory or control registers. Logical addressing takes advantage of one or more fieldbus memory management units (FMMUs) on a slave device. Once configured, a FMMU will translate a logical address to any desired physical memory address. This may include the ability to specify individual bits in a data byte, which provides an efficient way to control specific I/O ports or register bits without having to send any more data than needed. Finally, broadcast addressing selects all slaves on the network. For broadcast reads, slaves send out the logical OR of their data with the data from the incoming datagram.

Each time a slave successfully reads or writes data contained in a datagram, it increments the working counter value (see Figure 4).

Figure 4—An EtherCAT telegram consists of a header and one or more datagrams. Each datagram can be addressed to one slave, a particular block of data within a slave, or multiple slaves. A slave can modify the datagram’s Address, C, IRQ, Process data, and WKC fields as it passes the data on to the next device. (Source: R. Wotiz)

This enables the master to confirm that all the slaves it was expecting to communicate with actually handled the data sent to them. If a slave is disconnected, or its configuration changes so it is no longer being addressed as expected, then it will no longer increment the counter. This alerts the master to rescan the network to confirm the presence of all devices and reconfigure them, if necessary. If a slave wants to alert the master of a high-priority event, it can set one or more bits in the IRQ field to request the master to take some predetermined action.


Frames are processed in each slave by a specialized EtherCAT slave controller (ESC), which extracts incoming data and inserts outgoing data into the frame as it passes through. The ESC operates at a high speed, resulting in a typical data delay from the incoming to the outgoing network port of less than 1 μs. The operating speed is often dominated by how fast the master can process the data, rather than the speed of the network itself. For a system that runs a process feedback loop, the master has to receive data from the previous cycle and process it before sending out data for the next cycle. The minimum cycle time TCYC is given by: TCYC = TMP + TFR + N × TDLY  + 2 × TCBL + TJ. TMP = master’s processing time, TFR = frame transmission time on the network (80 ns per data byte + 5 μs frame overhead), N = total number of slaves, TDLY  = sum of the forward and return delay times through each slave (typically 600 ns), TCBL = cable propagation delay (5 ns per meter for Category 5 Ethernet cable), and TJ = network jitter (determined by master).[1]

A slave’s internal processing time may overlap some or all of these time windows, depending on how its I/O is synchronized. The network may be slowed if the slave needs more time than the total cycle time computed above. A maximum-length telegram containing 1,486 bytes of process data can be communicated to a network of 1,000 slaves in less than 1 ms, not including processing time.

Synchronization is an important aspect of any fieldbus. EtherCAT uses a distributed clock (DC) with a resolution of 1 ns located in the ESC on each slave. The master can configure the slaves to take a snapshot of their individual DC values when a particular frame is sent. Each slave captures the value when the frame is received by the ESC in both the outbound and returning directions. The master then reads these values and computes the propagation delays between each device. It also computes the clock offsets between the slaves and its reference clock, then uses these values to update each slave’s DC to match the reference. The process can be repeated at regular intervals to compensate for clock drift. This results in an absolute clock error of less than 1 μs between devices.


The orchestra’s EtherCAT network is built around a set of modules from National Instruments. The virtual conductor is an application running under LabVIEW Real-Time on a CompactRIO controller, which functions as the master device. It communicates with four slaves containing a mix of digital and analog I/O and three slaves consisting of servo motor drives. Both the master and the I/O slaves contain a FPGA to implement any custom local processing that’s necessary to keep the data flowing. The system runs at a cycle time of 1 ms, which provides enough timing resolution to keep the balls properly flying.

I hope you’ve enjoyed learning about EtherCAT—as well as the fascinating musical device it’s used in—as much as I have.

Author’s note: I would like to thank Marc Christenson of SISU Devices, creator of this amazing device, for his help in providing information on the design.


[1] National Instruments Corp., “Benchmarks for the NI 9144 EtherCAT Slave Chassis,”


Animusic, LLC,

Beckhoff Automation GmbH, “ET1100 EtherCAT Slave Controller Hardware Data Sheet, Version 1.8”, 2010,

EtherCAT Technology Group, “The Ethernet Fieldbus”, 2009,

Intel, Atom microprocessor, www/us/en/processors/atom/atom-processor.html.


Atom D525 dual-core microprocessor

Intel Corp.

LabVIEW Real-Time modules, CompactRIO controller, and EtherCAT devices

National Instruments Corp.

Circuit Cellar 264 is now on newsstands, and it’s available at the CC-Webshop.