{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.xiaopingtou.cn/data/attach/logo/logo.png', '推荐 neqee 的问题《SPI超远距离长线通信方法,以及在SPI显示器上的应用》','https://www.xiaopingtou.net/q-156943.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
本帖最后由 neqee 于 2018-12-3 10:43 编辑
这篇文章也许现在对你没什么用,但以后需要的时候希望能帮到你.
之前在论坛也有很多人讨论过长距离通信的最佳方案,希望能找到一种传输距离几十米,速度不要太慢,但又不需要太快,稳定可靠又简单的通信方法,我个人认为非SPI莫属,不过需要将SPI转换成差分信号传输才能做到稳定可靠的超长距离通信。相比之下,RS232、RS485、Can速度太慢, I2C、UART速度不行距离更不行,Ethernet、USB应用复杂成本高而且不够稳定可靠。
SPI作为同步、单向通信接口,时序严谨,支持推挽驱动,支持驱动缓冲,就算不转换为差分传输,如果布线和对地阻抗做地好的话,比如使用灰排线并且每根信号用地间隔,18MHz时钟频率,一般环境下,2米距离通信完全没有问题;但如果是强干扰环境,超远距离通信,就必须考虑将TTL信号转为差分传输,而常用、简单、高速、低成本的差分传输是LVDS:
image013.jpg (75.74 KB, 下载次数: 0)
下载附件
2018-12-3 10:29 上传
SPI作为同步、单向、推挽串行高速接口,它的扩展性和可转换性是非常强大的,我在想,以后工控设备主机是不是可以像串口DB9那样配备一个这样的"DVI接口"呢?
这篇文章也许现在对你没什么用,但以后需要的时候希望能帮到你.
之前在论坛也有很多人讨论过长距离通信的最佳方案,希望能找到一种传输距离几十米,速度不要太慢,但又不需要太快,稳定可靠又简单的通信方法,我个人认为非SPI莫属,不过需要将SPI转换成差分信号传输才能做到稳定可靠的超长距离通信。相比之下,RS232、RS485、Can速度太慢, I2C、UART速度不行距离更不行,Ethernet、USB应用复杂成本高而且不够稳定可靠。
SPI作为同步、单向通信接口,时序严谨,支持推挽驱动,支持驱动缓冲,就算不转换为差分传输,如果布线和对地阻抗做地好的话,比如使用灰排线并且每根信号用地间隔,18MHz时钟频率,一般环境下,2米距离通信完全没有问题;但如果是强干扰环境,超远距离通信,就必须考虑将TTL信号转为差分传输,而常用、简单、高速、低成本的差分传输是LVDS:
image013.jpg (75.74 KB, 下载次数: 0)
下载附件
2018-12-3 10:29 上传
SPI作为同步、单向、推挽串行高速接口,它的扩展性和可转换性是非常强大的,我在想,以后工控设备主机是不是可以像串口DB9那样配备一个这样的"DVI接口"呢?
友情提示: 此问题已得到解决，问题已经关闭,关闭后问题禁止继续编辑，回答。
最重要的是这种SPI长线通信方式门槛并不高,比较容易实现并能做到稳定可靠,这里只是陈述一种信号传输方法,并不涉及到通信协议,通信协议根据自己实际情况制定...
我在想,既然用CPLD来做协议了,为什么不把校验和重发也做在CPLD 的ip核里面？我知道实现起来还是有一定的难度,但对用户来说,可以摆脱很多工作量,在用户看来,使用就简单很多了！也许你在顾虑MCU和CPLD通信错误怎么办?其实这个问题是可以解决的,MCU读CPLD状态时,读"MCU-CPLD"和"RS485总线"两个校验状态不就可以了?
校验已经做在 FPGA/CPLD 里面了，硬件自动生成和校验 CRC.（我上面只不过是有提到关掉硬件 CRC 的情况，默认是使用硬件 CRC 的。）
数据在仲裁时检测到冲突，会自动避让和重发。
数据之所以出错不重发，因为涉及的问题比较多，
要在硬件层面添加比较复杂的协议，譬如 A 发数据给 B，B 收到后硬件自动发送握手包，这样总线带宽会被握手包消耗很多，不适合所有场合。
而且，如果地址字段出错，那么握手包还会误发给别的节点。
又譬如 A 发送组播包给 B C D E 四个节点，那么还要把组播列表信息写入 A 的硬件，如果组播涉及跨网络，那就更加没法在硬件层面处理。
CAN 总线通过 ACK 位和错误帧实现数据出错自动重发，但依然有局限：
如果 A 发送数据给 B 节点，如果 B 不在线，恰好 ACK 字段遇到干扰 A 检测到低电平，那么 A 会误以为 B 已成功接收。
譬如 A 发送组播包给 B C D E 四个节点，其中 C 节点不在线，那么 A 会误认为 C 也成功接收数据。
又譬如，E 的安装位置离 A 最远，最容易受到干扰，当 E 受到干扰会发出错误帧，从而使 B C D 也放弃接收 A 发来的数据帧，试想如果 A 是刹车踏板、B 是制动装置，而 E 是一个不重要的指示灯，如果 E 连续受到干扰会怎样？
所以，出错之后的处理机制应该在上层针对不同场景做不同处理。
而且，虽然是上层处理，但依然是协议栈（譬如 CDNET 库）自动处理，不会麻烦到用户（就算用户不用协议栈，自行搞一个超时重传机制也不麻烦）。
一周热门 更多>