电路板回板后，如果串口能够正常打印，则我们很多调试手段都可以运用，能够运用串口打印，或者调试工具能够快速地进行问题定位。 最痛苦的就是嵌入式系统，我们的知识体系比较单一，团队中缺少软硬兼修的人。如果回板的电路板虽然不冒烟，但是无法明确是软件问题，还是硬件问题的时候，就需要我们通过一系列操作进行问题定位，然后逐步歼灭问题，最终达到串口能够正常打印的地步。 早期在X86系统中，为了帮助定位问题，会选择这样的80卡，用一个PCI外设来显示故障部件的位置，缩短调试的时间和过程。 但是最痛苦的事情是，80卡也不亮。 所以我们需要逐步排除硬件问题，捋清楚硬件启动的过程： 1、时钟问题。 一般表现在时钟配置异常，晶振的选型频率范围有问题，超出芯片主频工作范围。 还有晶体不起振，我们碰过有同事归一化电容，把晶振的负载电容容量选型选的容值过于大了。 也碰过晶振的走线太长，导致处理器接收端的信号质量不好，导致无法正常启动。 2、电源问题。 电源完整性的质量差，纹波过大，尤其开关电源供电时；或者供电输出不稳定；或者系统供电能力不足而引起电源波动等。例如有一些设计错误，电压错误、电流能力不足、电源之间的相互干扰等等。我们需要仔细排查电源本身的问题。 3、上电时序的问题 电源之间的先后关系，我们设计电路板的时候，需要捋清楚每个电源上电的先后时序要求，很多芯片都会有相关的要求：处理器、FPGA、DSP等等一般都会有时序要求。 容易忽略的一个点是：不光是电源时序有要求，有些芯片的时钟稳定、电源稳定、复位信号之间有先后关系，或者还有时间间隔的要求。 我们需要全方位排查时钟、电源、复位信号之间的时序要求。特别是一些共用电源的芯片，很可能由于时序要求，我们要分别供电，或者需要通过MOSFET控制上电时机。 4、BOOT脚配置问题。 对于ARM芯片往往都有些BOOT配置引脚。经常遇到有人因为BOOT脚的焊接或接触不良导致各类奇怪问题。这种情况多表现在芯片功能时好时坏，或者部分芯片正常，部分芯片异常。 我们不管是ARM也好、X86也好、DSP也好，以及MIPS和RISC-V都存在启动路径的问题。有TF启动、U盘启动、硬盘启动、光盘启动等等。 我们需要知道要么像X86那样，由BIOS来配置启动路径，或者像有的ARM通过上下拉电阻来配置启动路径。 最近在玩英伟达的Jetson，最不爽的一件事就是：不同的启动路径，使用的系统镜像不同。如果我们忽略，会导致系统无法启动。 5、启动文件问题。 经常因为选错了启动文件，导致程序无法正常运行，或者说调试时好好的，脱机运行就不行。这点在做不同系列芯片间移植时最容易碰到。 有些处理器的启动配置文件很复杂，没问题的时候容易被大家忽略，一些处理器的基础配置在配置文件里面。如果配置文件错误，会导致处理器启动异常。 6、地址空间错误 我们从软件的视角，有时候很容易忽略启动地址。地址空间有时经常会把软件人绕晕。硬件的人想搞清楚，也费尽。 1、现象、问题描述 2、关键过程、根本原因分析 问题一：单板启动到什么程度。 结论一：在读取RCW的阶段就挂死了。 问题二：RCW有什么错误，它的错误为什么会导致处理器挂死。 Demo板的RCW 5050 5050 0000 cccc 58400000 c03c2000 0000 0000 00df 07fd a000 0000 0000 0000 我们单板烧入的RCW没有红色的字。 我们的设计方法直接借鉴公司大规模使用的单核PowerPC 8321的设计方法：1、阅读器件资料，理解配置字的含义；2、列出配置字的内容；3、整理成16进制发给软件工程师。 措施二：利用工具生成RCW，烧录Flash。 分析三：配置字已经跑过了，又挂在Bootrom。 先怀疑配置字问题，我觉得没有问题，依据是原来跑步起来，现在跑起来了。 BOOTROM的启动挂死的比较前端，估计应该没有读到BOOTROM。查看Flash烧片文件，第一条指令与RCW之间预留了若干位，其中填0，软件多填了一行0. 发现软件的起始地址不对。 如下图所示： 措施四：于是我们考虑在Flash里面加载现有代码两个地方， 通过设置JTAG的起始地址，实现加载。 127M = 127* 1024 *1024 = 0x7F00000。 最终的交付版本，是通过CPLD地址重定向实现的RCW和BootRom存储在连续地址。 分析四：虽然打印了一堆乱码，但是键盘可以输入。根据判断，单板已经正常工作了，但是当时怀疑是内存问题导致的数据错误，导致打印乱码。 底软的开发人员怀疑的VxWorks下的中断错误，导致串口乱码。当时给出三条否定意见的依据： 为什么Demo可用，而我们单板不可用？ 通过查代码发现： Demo板的所有CS都是连接到FPGA的 Demo板子上面，FPGA的CS3如同我们CPLD寄存器。 FLASH的映射方式 后续，我们重点关注了这个：“单板CPU主频。” 通过CS3读出的处理器主频，直接写定。SYStemCLK是从CS3中读取的，波特率是通过SYSTEMCLK分频得出的。 修改了SYSTEMCLK之后（由于我们的单板没有CS3，所以原先从CS读取SYSTEMCLK，导致了错误），出现VxWorks界面。串口打印正常。 3、结论、解决方案及效果 配置字校验数据缺失； VxWorks加载过程中修改了处理器主频，导致串口乱码。 这不是一个什么高级的案例，但是每个使用新处理器的单板返还，都会有一段曲折的路走。 a、 每一个操作，都需要有依据，例如BootRom的存储位置等，这些不明确的话，肯定会引入问题。 c、 硬件，软件不要划分界限，要相互渗透，在串口还没有打印前的问题，需要所有开发人员都非常清楚，而不是相互推诿，相互依赖。
7. 1 串行外设接口 （ SPI） 7. 1. 1 SPI 模块概述串行外设接口 （ Serial Peripheral Interface， SPI） 是一个高速同步的串行输入 / 输出接口，通常用于 DSP 与外设或其他处理器之间的通信。 其通信长度 （1 ～ 16 bit） 和通信速率都是可编程的。 SPI 可采用主 / 从模式实现多处理器通信， 典型的应用包括扩展 I / O、 移位寄存器、显示驱动器、 模 - 数转换器 （ ADC） 等器件的外设拓展。 C28x 系列 DSP 的 SPI 支持 16 级深度的发送和接收 FIFO （ 先入先出） 以减小 CPU 开销。 1. 增强型 SPI 模块概述SPI 与 CPU 接口如图 7-1 所示。多通道缓冲串行口 （ McBSP）7. 2. 1 McBSP 概述2833x 系列器件提供了两个高速多通道缓冲串口 （McBSP）， 可以与 CODEC 或系统其他器件直接相连。 McBSP 包含了与器件相连接的数据端口和控制端口， 共 6 个引脚， 如图 7-14所示。McBSP 有如下特性：● 全双工通信方式。● 双缓冲发送数据和三缓冲接收数据， 允许连续数据流操作。● 发送和接收具有独立时钟和帧同步的信号。● 具有向 CPU 传送中断请求和向 DMA 控制器传送 DMA 事件的功能。● 128 个发送和接收通道。● 多通道选择模式可以允许或禁止每一通道的传输。● 与工业标准的 CODEC、 模拟接口器件 （ AIC） 及其他串行接口 ADC 模块和 DAC 模块直接连接。● 支持外部的时钟信号和帧同步信号。● 内有可编程的采样率发生器， 用以发生和控制内部时钟信号及帧同步信号。● 帧同步信号和时钟信号的极性可编程。● 与 T1 / E1 帧调节器、 IOM - 2 兼容设备、 AC97 兼容设备、 I2S 兼容设备、 SPI 设备的直接连接。● 数据长度选择范围宽可以是 8、 12、 16、 20、 24、 32 位。● μ - 律和 A - 律格式数据压缩扩展。● 发送或接收 8 位数据时， 可以先传送最低有效位。● 有异常 / 错误状态标志位。● 不支持 ABIS 模式。串行通信接口 （ SCI）7. 3. 1 SCI 模块概述串行通信接口 （ SCI） 是一个两线制异步串行接口， 即通常所说的 UART 口。 SCI 模块支持 CPU 和其他使用标准不归零码 （ NRZ） 的异步外设之间的数字通信。 SCI 的接收器和发送器各自具有一个 16 级深度的 FIFO， 从而减小了 CPU 开销， 并且它们都有独立的使能位和中断位。 两者可以独立地进行半双工通信， 或者同时进行全双工通信。为了保证数据的完整性， SCI 模块对接收到的数据进行间断检测、 奇偶校验、 溢出以及帧错误检测。 通过配置 16 位的波特率选择寄存器可以设置不同的 SCI 通信速率。1. 增强型 SCI 模块特征SCI 模块与 CPU 的连接如图 7-29 所示。DSP原理及应用——跟我动手学TMS320F2833x（411页）.pdf
-Begin-大家好！我是付工。通透！终于把ModbusRTU弄明白了这样看来，ModbusTCP协议太简单了太简单了！C#轻松实现Modbus通信前面给大家介绍了一系列关于Modbus和ModbusTCP的知识。今天给大家来实测一下，对于不同品牌的PLC或板卡实现ModbusTCP通信时，通信速度有多快。测试界面我们使用自己开发的通信库进行测试，不同通信库会有细微区别，测试结果仅供参考，并不针对具体产品及厂家。下面是我们的PLC平台，我们选择其中几个比较常用的支持ModbusTCP通信协议的PLC来进行测试。测试软件设计界面如下所示：ModbusTCP默认端口号是502，所以不同设备仅仅只是IP地址不同而已，为了保证数据的准确性，我们使用循环读取的方式，循环三组，每组连续读取10000次，观察总耗时。同时，我们读取的存储区也是一样的，读取4区从0开始的100个寄存器。西门子200Smart西门子200Smart PLC，我们采用的是CPU ST40，大家都知道西门子PLC想要支持ModbusTCP通信，是需要写一点PLC程序的，如下图所示：测试结果如下所示：西门子1200西门子1200 PLC，我们采用的是CPU 1215C DC/DC/DC，西门子1200 同样也需要写一点PLC程序的，如下图所示：测试结果如下所示：西门子1500西门子1500 PLC，我们采用的是CPU 1511-1 PN，西门子1500 同样也需要写一点PLC程序的，如下图所示：测试结果如下所示：三菱FX5U三菱FX5U PLC，我们采用的是FX5U-32MT/ES，三菱FX5U PLC是直接支持ModbusTCP的，但是需要做下配置，在以太网配置里加上ModbusTCP连接设备，端口号设置为502。测试结果如下所示：施耐德M241施耐德PLC，我们采用的是施耐德M241，这个不需要额外写PLC程序。测试结果如下所示：信捷XD5E信捷PLC，我们采用的是信捷XD5E，国产PLC对Modbus协议支持比较好，不需要额外写PLC程序。测试结果如下所示：台达DVP台达PLC，我们采用的是台达DVP-32ES，这个不需要额外写PLC程序。测试结果如下所示：汇川AM600汇川PLC，我们采用的是汇川AM600-CPU1608TN，这个不需要额外写PLC程序。测试结果如下所示：汇川H5U汇川PLC，我们采用的是汇川H5U，这个不需要额外写PLC程序。测试结果如下所示：汇川EASY汇川PLC，我们采用的是汇川EASY521，这个不需要额外写PLC程序。测试结果如下所示：正运动板卡正运动运动控制卡，我们采用的是ECI1408，这个不需要额外写程序。测试结果如下所示：总结通过以上测试结果，我们可以得出以下几个结论：1、由于不同设备对ModbusTCP的处理方式不同，因此最终通信速率有所区别，但平均周期均在10ms以内，此时间为单次交互的时间。2、上位机通信很稳定，连续百万次交互都没有失败次数。3、读取1个寄存器的耗时与读取100个寄存器耗时时间差别不大，上位机开发中尽量采用批量读取的方式。写在最后今年8月，历经2年，我出版了一本上位机书籍——《C#上位机开发实战指南》。我的新书《C#上位机开发实战指南》出版了大家如果需要购买，可以通过京东旗舰店购买。如果需要作者签名版，可以联系我【+V：fuswj001】，59元包邮。-END-上位机技术文章，请关注公众号【上位机Guide】上位机技术交流，请添加本人微信【fuswj001】感谢大家阅读，关注我，分享上位机开发技术。
扫码关注面包板社区
