Real-time control meets real-time industrial communications development – part two

In part one of this blog series, I gave an overview of the market opportunity for EtherCAT slave stack support on C2000 MCUs and an introduction to a three phased solution to jumpstart slave stack development.

Beyond this three-faceted development flow, what has TI done to make our solution more compelling than a typical stack porting exercise? First, we applied our knowledge of the C28 CPU architecture and tuned the software to leverage the CPU services accordingly. For example, we optimized the interrupt handling, direct memory access (DMA) and control (pulse-width modulation [PWM]) synchronization routines to make the best use of the on-chip hardware. In addition, we worked with Beckhoff to update/enhance the released stacks to support data handling so that it’s more tailored for the C28 CPU.

Speaking of working with Beckhoff, the C28 slave stack and hardware abstraction layer (HAL) for both Serial Peripheral Interface (SPI) and parallel (external memory interface [EMIF]) communications are supported as part of their Slave Stack Configuration tool (SSC). Based on previous C2000 MCU experience, you will find the reference software solution release “Plugfest-ready.”

Supporting both the SPI and EMIF hardware interfaces provides implementation options, enabling system trade-offs on printed circuit board (PCB) routing complexity vs. the lowest latency communications. In addition, while we tested the release directly with the Beckhoff ET1100 device, you will be able to adapt the SPI and EMIF HAL drivers to support other EtherCAT slave silicon solutions, including TI’s AMIC110 SoC (SPI – please contact the Sitara™ forum) or field-programmable gate array (FPGA) instances (EMIF or SPI) of the slave hardware such as the Beckhoff ET1816.

Among SPI and EMIF processor data interfaces (PDIs), there is no difference between the EtherCAT slave stack code and application code. Only the device name and product code differ, so both SPI and EMIF slave nodes can be different even when they are both in the same network. EMIF slave nodes can be different when they are both in the same network.

A C2000 MCU-specific feature of TI’s EtherCAT software package is the Echoback application example. While the application demonstration is not complex, it simply loops slave-node output data structures back to inputs, viewable using any EtherCAT master or the TwinCAT master as detailed in the “EtherCAT Solution Reference Guide.”

By including the Echoback application, TI shows an example of the basic use of the stack software and provides a placeholder for you to create your own applications. Following the Echoback example will make it easier to take advantage of the many optimizations TI has made in the stack and HAL software modules and gives a good example of the EtherCAT slave information (ESI) file as well. Echoback is also included as part of the quick evaluation binary project.

Figure 1: TMDSECATNCD379 EtherCAT Board Image

Finally, there is the compelling EtherCAT controlCARD hardware platform itself, Figure 1, that leverages the common 180-pin interface of other C2000 MCU control cards.  The EtherCAT controlCARD is physically compatible with any 180-pin C2000 application evaluation module (EVM) or dock, thus making it possible to add EtherCAT connectivity to many existing real-time control application examples. For example, you can use the EtherCAT controlCARD in conjunction with the industrial drives development kit (IDDK) to add real-time connectivity to a servo using fast current loop and/or position manager technology.

Another nice feature is that the EtherCAT controlCARD can operate stand-alone. Powering the hardware with a Micro USB cable eliminates the need for a dock or EVM to supply power. See the “TMDSECATCNCD379D EtherCAT Solution Reference Guide” for details. This can help reduce hardware complexity in multi-node network testing and configuration.

As you can see, the C2000 DesignDRIVE EtherCAT support has taken several additional steps to ease your development of your own slave node and help you get great performance running the stack on our microcontrollers.  In the following posts of this series, I will provide more description of the software support provided by each of the three development phases outlined previously. 

Additional resources