标签: esc

    各位，好久不见，说来惭愧，小编已经有好几个月没分享过文章了，最近小编了解了一些关于EtherCAT协议的知识和市场，发现EtherCAT这一工业以太网技术在国内也已经开始应用起来了，尤其在速度和精度有高要求的场合，EtherCAT技术更有着它独一无二的特点和优势。国内的几大运动控制厂商也正为他们的运动控制产品升级EtherCAT技术，可以说，EtherCAT绝对是运动控制的未来，更是工业4.0概念下的完美体现。     小编今天分享的这篇文章，是关于EtherCAT从站开发与设计的，对于那些刚接触EtherCAT，或打算开发EtherCAT设备的工程师来说，可以帮你快速地扫盲和上手。而对于那些非常熟悉EtherCAT的高级开发工程师来说，本文提到的方案也可以给您做一个参考，提高开发效率，缩短开发周期。 EtherCAT 从站设计中的重要事项和关键观念（一） 一般从站包括以下三个核心部分： 物理层：网口 数据链路层：有 EtherCAT  从站控制器 ESC （这是通讯模块）和 EEPROM 。 应用层 ： 有主控制器或者说应用控制器或微控制器 u C （即比如 DSP28346 或者 F407 之类的）。 ESC 即 EtherCAT 从站控制器可以通过 FPGA (Field Programmable Gate Array) 或者 ASIC  (Application Specific Integrated Circuit) 来完成。 EtherCAT 通讯的速度和性能与主控制器（比如 DSP28346 ）软件程序的性能 互不影响。 关于 PDI ： ESC 上的 PDI-  Process Data Interface 过程数据接口有这几种情况： i. Up to 32 Bit digital I/O  ： 32 位的数字量 IO ii. Serial Peripheral Interface (SPI)  ： SPI 总线 iii. 8/16-bit synchronous/asynchronous Microcontroller Interface (MCI)  ： 8/16 位的同步 / 异步微控制器接口 MCI iv. With FPGA: specific on-board-bus (Avalon on Altera devices resp. OPB on Xilinx devices)  ： 带 FPGA 的：特定的 on-board-bus 过程数据和参数是通过 ESC 上的 DPRAM 来交互的。为了保证数据的一致性， ESC 硬件上会有一些机制：比如同步管理器等。 chapter 1.3.4 关于 FPGA : 为了实现 FPGA ， ESC 会用 IP Core 的方式实现 EtherCAT 功能和通讯。  FMMUs ( Fieldbus Memory Management Units  现场总线内存管理单元 ) ， SyncManagers, DC support, PDI 这几个功能是可以配置的 。 FPGA 实现方式有两种：一个是在 FPGA 上集成 ESC 和一个软核 uC ，然后用 FPGA 的板上总线与主控制器交互。另外一个方式是： FPGA 只用于 EtherCAT 功能部分，然后通过 SPI 总线连接到外部的主控制器。 关于 EEPROM 也叫 SII ：  (Electrically Erasable Programmable Read-Only Memory, also called Slave Information Interface, SII) ， 它包含在上电后会自动加载到 ESC 寄存器的配置信息。 EEPROM 可以通过 ESI 文件的配置工具修改。 EEPROM 的内容必须在从站设备厂家再研发时就设置好。下图时 EEPROM 的寄存器的值 .   关于应用层的 主控制器 uC ： 主控制器主要实现： i. EtherCAT State Machine (ESM) in the slave device (chapter 1.3.7)  ：从站设备的 EtherCAT 状态机 ESM ii. Process data exchange with the slave application (e.g. application and configuration parameters, object dictionary, chapter 2.3.6)  ： 过程数据交互 （配置参数，对象字典等） iii. Mailbox-based protocols for acyclic data exchange (CoE, EoE, FoE, chapter 1.3.6) ：非周期数据交互的邮箱协议： CoE, EoE, FoE iv. Optional TCP/IP stack if the device supports EoE  ：可选的 TCP/IP 堆栈（前提是设备支持 EoE ） uC 的性能只取决于设备功能应用部分而非 EtherCAT 通讯部分，大部分情况下， 8bit 的 uC 或者 PIC 就够了。（想表达的是： EtherCAT 通讯是不会影响性能的， EtherCAT 协议的一个好处） 关于 ESI （ EtherCAT Slave Information ） :  每个 EtherCAT 设备都必须随货给用户一个 ESI 文件，一般是 .xml 格式。 ESI 文件是配置工具在离线模式下用来编译网络信息 ENI 的（比如过程数据结构，同步命令等） See also related description in chapter 2.4.1. 关于 ESC 的 EtherCAT 接口： ESC 最多只能提供 4 个 EtherCAT 接口，端口 0 必须定义为输入口。从站必须提供至少 2 个 EtehrCAT 接口。为了避免有些从站只有 2 个接口的，所以配合使用的 ESC 上的端口 0 和 1 必须使用，端口 3 和 4 可以保留。 ESC 总是通过端口 0 与主站相连的，与其他从站设备则通过端口 1-3 来连接。 EtherCAT 的报文帧结构： 关于 FMMU ：现场总线内存管理单元： 用于映射主站的逻辑过程数据映像和从站设备的物理层（本地）内存。 从下图看来：这个 FMMU 就是为了从主站发出去的一条报文中找到属于自己从站需要的那条。 关于同步管理器： SyncManager  不管是 EtherCAT 主站还是从站主控制器 PDI 去读取 ESC 的 DPRAM ，这个 DPRAM 的访问都需要确认数据一致性。同步管理器就是一个用来确保 DPRAM 中过程数据能被访问的机制：不同时间访问，但是访问到的是一致的。 如果从站使用 FMMU ，对应数据块的同步管理器位于 DPRAM 与 FMMU 之间。 EtherCAT 的同步管理器可以在两种模式下操作： 邮箱模式 ： 数据交互采用的是握手机制。 EtherCAT 主站和 uC 的控制程序只有在对方已经访问完缓冲区的时候才能继续访问。发送方在写入缓冲区的时候，缓冲区被锁定 for writing  直到接收方已经全部读完。邮箱模块一般用于应用程协议和非周期数据的交互（比如参数设置） 缓冲模式 ： 缓冲模式一般用于周期性数据交互，比如过程数据，因为缓冲模式允许任何时候 EtherCAT 主站和从站主控制器 uC 都可以访问通讯缓冲区。发送方总是可以更新缓冲区的内容。如果缓冲区被写入的数据快于接收方去读取的速度，则旧的数据就会被丢掉。因此，接收方永远都是收到最新的而且与缓冲区内容一致的数据。 注意：同步管理器如果工作在缓冲模式下，则需要比分配在 DPRAM 中的过程数据大小大三倍。 应用程序的设计可以参考免费的 ET9300 或者商业版 KPA 的代码，**式，可选常见平台的 demo 。具体对比如下： 由于篇幅字数限制，下次再给大家分享余下内容。

You could rarely find a paleontologist at the Embedded Systems Show. Seeing two at a single booth would be even more unusual. At the premier venue of all things state of the art – indeed, in some cases the salesmen's claims about the features of the not-quite-finished new products are even a bit beyond their actual capability – it's surprising to find any booth that celebrates ancient technologies. Did these scientists unearth some buried artifact in Silicon Valley, perhaps a fab that, in ancient times, cranked out parts with 1.3 micron geometry? Or maybe a construction project turned up a cache of 8048s, buried for ages, guarded during the dig by a hastily thrown up barrier, courtesy of San Jose's historical society. No, these paleontologists at the recent ESC were explaining a 70 million year old T Rex skeleton on display at the Green Hills booth. Wikipedia tells me that predates even vacuum tubes. And indeed the displayed artifact was bigger than any tube I've seen. Though named Samson, it turns out the dino was a girl. I'm not sure what Samson had to do with embedded systems, but it sure created buzz. Even more buzz happened when the power went out for an hour or two. Emergency lights quickly lit up the convention center, but vendors were left without the ability to showcase their products. Some wags suggested the outage was really a demo of low power management. One event manager said that, this being the city's largest show, and given the extreme heat (like, low 70s), we had excessively stressed the grid. About 1000 houses lost their power as well. I was surprised at Microsoft's booth. There wasn't one. Also surprising were the dearth of Linux vendors. A couple were there, but the count was far down from other recent shows. I suspect Linux has become so mainstream it's no longer novel enough to warrant much sales effort. LeCroy was there. And pretty much everywhere. They had a small army of young ladies zipping around San Jose on Segways handing out literature. And at least one LeCroy ad truck was parked out front. Steve Wozniak gave a keynote, but he didn't want to call it such. So it was a "fireside chat," a casual discussion conducted on a couch. He rambled a bit but was surprisingly personable. No dancing, but the packed auditorium was mesmerized. Jeri Ellsworth gave Thursday's keynote. A high school dropout, she's now a freelance ASIC designer. Jeri has some quite innovative YouTube videos, and her life story is truly that of the up-from-nothing American entrepreneur. I go to most of the ESCs and enjoy them all. As I told my wife the latest was unusually compelling, both for the quirkiness and the technical content. My briefcase is bulging with material from the show; some of which will make it into future columns here.

The recent Embedded Systems Conference (ESC) had an extraordinarily interesting mix of vendors. Some I'll feature later – like the intriguing new scope for the iPad and iPhone from Oscium, and a complete redesign of Microchip's IDE. The Embedded App Store But did you know the embedded world now has an app store? Or something similar. Express Logic's ThreadX kernel can now handle what they call "downloadable application modules." The idea is to cheat the linker; to completely isolate parts of a program from each other via the kernel. These apps can be downloaded from, say, bulk flash into memory during execution of the program. They are independent and not part of the usual big monolithic executable. Communicating only via kernel API calls each application is independent of each other and of the main executable. The up side is that the apps can live in protected memory. Any crash is mediated by the MMU. Changes don't require rebuilding the entire code base. One can conserve expensive memory by not loading an app till it's needed. And then there's the concept of partitioning: one reason software productivity is not higher is that by building a single executable, we're caught on a trap of constant communication with our colleagues. Joe has to talk to Jill about how her code will interface with his. Partition the code into completely independent hunks and they can both work at a very high level of productivity. Requirements Poor requirements are an industry-wide bane. In the best of circumstances they're hard to elicit, which has led some to practically abandon the quest. But some regulated industries have very strong demands on how requirements must be handled. In avionics, for instance, requirements must be traceable to the code. If a requirement has no corresponding code, there's something wrong, and if the code can't be mapped back, it must be removed. The current standard in the US for avionics is DO-178B. But soon – perhaps this year – this two-decade old gem will be replaced by DO-178C. According to FAA Consultants , among the changes is, as I understand it , the "requirement" that requirements must be traceable all the way down to the object code and back. In the meantime the FDA is pretty much clueless about software engineering and uses an antiquated process to qualify medical devices. Why they don't simply replace all of the excess verbiage with the statement "DO-178C. Do that." is beyond me. But increasingly companies on their own volition are adding requirements traceability simply to insure they're building best-in-class software that will help the patients rather than their lawyers. LDRA has updated their tool suite to support requirements traceability all the way from the source code to the object... and back up. This insures that despite an overly-aggressive optimizer, for example, the machine code matches the customer's needs. There are quite a few traceability tools available, but to my knowledge LDRA's is the first to go to the object level. Security The nice folks at AdaCore directed me to a new NIST study . The government looked at C, C++ and Java for security vulnerabilities. I found it interesting that NIST used SPARK, an Ada subset, as the baseline language since it inevitably leads to correct code. To quote: "There are languages that are, by design, more suitable for secure programming. We added SPARK as an example of one." While it's certainly possible to write great code in pretty much any language, the use of some lingos inevitably leads to better code.  

At the Embedded Systems Conference in Silicon Valley a few months ago, I had the chance to talk to various vendors of static analyzers. These are the tools that evaluate your program to find potential runtime problems, like variables going out of bounds or dereferences of null pointers. Static analyzers are relatively new ideas that still have little market penetration, but that offer the chance to rid a program of a large class of bugs long before loading a debugger. Though in many cases these are still somewhat immature, I think that over the course of the next decade most of us will consider them an essential part of how we build systems. However, a pattern is emerging that makes me think the current crop of tools are missing a valuable opportunity. Consider the following snippet: int divide(int value1, value2) { return value1/value2; } Very simple code, of course. At least some of the current static analyzers will return a message saying that a divide by zero is possible, though the tool cannot predict if indeed such a case will ever occur. To be fair, the tools are pretty smart and will not emit an error if the code looks like: int divide(int value1, value2) { if(value2!=0) return value1/value2; } Others do deeper analysis and will look at how the function is called, but all can get tripped up since many cases are simply not analyzable. For instance, if a calculation is based on a reading from a peripheral, none of the commercial tools can predict the possible input ranges. So they'll issue a warning, and it's up to the developer to insure that the code will be safe. Why don't the tools take this a bit further? If there's a chance that an error will occur if an un-analyzable input assumes some value, perhaps the tool should generate a new version of the source file annotated with an assertion that tests for the potential error condition. Pour the code into the tool and let it generate: int divide(int value1, value2) { assert (value2!=0); // WARNING! Possible error return value1/value2; } The upside is that the code will fail if the possible error does occur, and it's a signal to the developer that the tool has found a limitation on the range of values a variable is allowed to assume. This is but a trivial example, but I suspect there are a vast number of situations where a static analyzer cannot provide a definitive answer, but could generate the appropriate assertions to insure that if bad things occur at runtime and exception will be thrown.  

It's quite rare to find a paleontologist at the Embedded Systems Show. It's even more unusual to find two at a single booth. At the premier venue of all things state of the art – indeed, in some cases the salesmen's claims about the features of the not-quite-finished new products are even a bit beyond their actual capability – it's surprising to find any booth that celebrates ancient technologies. Did these scientists unearth some buried artifact in Silicon Valley, perhaps a fab that, in ancient times, cranked out parts with 1.3 micron geometry? Or maybe a construction project turned up a cache of 8048s, buried for ages, guarded during the dig by a hastily thrown up barrier, courtesy of San Jose's historical society. No, these paleontologists at the recent ESC were explaining a 70 million year old T Rex skeleton on display at the Green Hills booth. Wikipedia tells me that predates even vacuum tubes. And indeed the displayed artifact was bigger than any tube I've seen. Though named Samson, it turns out the dino was a girl. I'm not sure what Samson had to do with embedded systems, but it sure created buzz. Even more buzz happened when the power went out for an hour or two. Emergency lights quickly lit up the convention center, but vendors were left without the ability to showcase their products. Some wags suggested the outage was really a demo of low power management. One event manager said that, this being the city's largest show, and given the extreme heat (like, low 70s), we had excessively stressed the grid. About 1000 houses lost their power as well. I was surprised at Microsoft's booth. There wasn't one. Also surprising were the dearth of Linux vendors. A couple were there, but the count was far down from other recent shows. I suspect Linux has become so mainstream it's no longer novel enough to warrant much sales effort. LeCroy was there. And pretty much everywhere. They had a small army of young ladies zipping around San Jose on Segways handing out literature. And at least one LeCroy ad truck was parked out front. Steve Wozniak gave a keynote, but he didn't want to call it such. So it was a "fireside chat," a casual discussion conducted on a couch. He rambled a bit but was surprisingly personable. No dancing, but the packed auditorium was mesmerized. Jeri Ellsworth gave Thursday's keynote. A high school dropout, she's now a freelance ASIC designer. Jeri has some quite innovative YouTube videos, and her life story is truly that of the up-from-nothing American entrepreneur. I go to most of the ESCs and enjoy them all. As I told my wife the latest was unusually compelling, both for the quirkiness and the technical content. My briefcase is bulging with material from the show; some of which will make it into future columns here.