搜索
bottom↓
回复: 46

SPI超远距离长线通信方法,以及在SPI显示器上的应用

  [复制链接]

出150入135汤圆

发表于 2018-12-3 10:21:46 | 显示全部楼层 |阅读模式
本帖最后由 neqee 于 2018-12-3 10:43 编辑

这篇文章也许现在对你没什么用,但以后需要的时候希望能帮到你.
之前在论坛也有很多人讨论过长距离通信的最佳方案,希望能找到一种传输距离几十米,速度不要太慢,但又不需要太快,稳定可靠又简单的通信方法,我个人认为非SPI莫属,不过需要将SPI转换成差分信号传输才能做到稳定可靠的超长距离通信。相比之下,RS232、RS485、Can速度太慢, I2C、UART速度不行距离更不行,Ethernet、USB应用复杂成本高而且不够稳定可靠。
SPI作为同步、单向通信接口,时序严谨,支持推挽驱动,支持驱动缓冲,就算不转换为差分传输,如果布线和对地阻抗做地好的话,比如使用灰排线并且每根信号用地间隔,18MHz时钟频率,一般环境下,2米距离通信完全没有问题;但如果是强干扰环境,超远距离通信,就必须考虑将TTL信号转为差分传输,而常用、简单、高速、低成本的差分传输是LVDS:


为什么用DVI线传输LVDS差分信号?原因有下:
(1)连接器可靠性好,非常适合工业应用.
(2)标准线,有各种长度选择,有18+1和24+1两种规格选择,便宜成本低.
(3)双绞线,绕线严谨稳定,100Ω传输阻抗适合LVDS信号传输要求,带屏蔽并且屏蔽效果非常好。
(4)扩展性强,还有好几根线没用到可以用作其他用途,比如从机可以通过DVI线供电,还可以用24+1的DVI线,增加多机通信片选信号。
下面是SPI时序分析,如果不对SPI时序理解透彻,实际操作时有可能会发现通信不稳定,或者通信时钟频率上不去,但又查不出什么原因。
上面我也已经提到,SPI是同步通信,严谨的理解时钟线和数据线的关系是非常重要的,不过在这里我也不可能对这方面做非常详细的讲解,只能说一说需要注意的地方,更多的知识可以到网上查资料学习。

做进一步探讨之前,我们先来看STM32的SPI主机和从机的时序图,在这里我只说明CPOL=1,CPHA=0模式的情况:



对于CPOL=1,CPHA=0模式,不管是主机还是从机,都是下沿获取数据上沿输出数据:
(1)tc是时钟频率,也可以说是时钟周期宽度,这个好理解。
(2)tv是时钟边沿到数据有效时间,理解这个很重要,MISO是经过D触发器输出,时钟边沿(跳变)到触发器输出是需要时间的,也就是数据相对于时钟边沿来说有一定的延迟,这个延迟就是tv,当然,这个tv是相对于单片机I/O那个点来说,事实上,时钟和数据输出还要同时经过最外面一层延迟,那就是I/O处的一个缓冲器。
(3)tsu和th是数据的建立和保持时间,书上长篇大论反而越看越糊涂,其实就是你要用一个时钟边沿去采集一个数据,你总该往数据的中心点采集才可靠吧?tsu意思就是时钟边沿已经到I/O引脚处,MOSI的数据必须提前tsu时间准备好;th意思就是时钟边沿已经从I/O引脚处消失,但MOSI的数据不能马上消失,至少还要保持th这么长时间,否则SCK采集MOSI线的电平可能会发生错误。
从机又多了几个时间概念:ta、tdis、tsu(NSS)、th(NSS):
(1)ta意思就是主机NSS变低有效之后,从机最迟会在ta时间之前把MISO上的数据准备好。
(2)tdis意思是主机NSS变高之后,从机MISO上的数据还会维持tdis时间之后才会消失。
(3)tsu(NSS)、th(NSS),因为对于从机来说,NSS也是数据,当然也要和MOSI一样有建立和保持时间要求。

上面对SPI时序的说明只是帮助理解,下面才是重点:
既然我们要做远距离传输,那么线的延迟就不能忽略了,事实上,相对于几十MHz的信号来说,线的延迟影响是非常大的。
我们先讨论假如没有MISO的情况,SCK、MOSI、NSS三根线的方向都是主机发送到从机,那么经过TTL转LVDS延迟t1、DVI线延迟t2、LVDS转TTL延迟t3,幸运的是, SCK、MOSI、NSS三根线的延迟差不多相等,都是t1+t2+t3,那么到达从机端之后它们之间的时序关系还是保持不变,所以DVI线的长度多少并不会影响到信号传输,如果暂不考虑信号衰减,1米和100米效果是一样的。
但对于MISO来说,情况就完全不一样了,SCK上沿从主机出发,经过延迟t1+t2+t3到达从机I/O,SCK上沿到达从机I/O之后,MISO还要经过延迟t5才会输出到从机I/O处,MISO再经过延迟t1+t2+t3才能到达主机I/O,也就是经过一个环路延迟;而且DVI线越长,这个环路延迟将变的越大;而前面说到SCK是上沿输出下沿获取,意味着这个环路延迟必须要在半个时钟周期之内,否则主机内部的SCK下沿没法正确采集MISO。
这样带来的后果是什么?又想速度快又想接线长就变的矛盾了,我实测在15MHz速率下DVI线最长只能2米左右,那么有什么办法可以解决这个问题?
办法就是稍微改一下从机的时序,让从机不在上沿输出,而是在下沿输出,即主机不变从机改为下沿输出下沿获取,也就是从机的MISO提前半个时钟周期输出,这样就可以多出半个时钟周期的时间给信号延迟使用。这样做之后,我实测在15MHz速率下DVI线长度可延长至5米,10MHz速率下DVI线长度可以做到8米。
那么新的问题又来了,任何单片机的SPI都不能改为下沿输出下沿获取啊,那怎么办?这就没办法了,或者用一个CPLD做转换,或者乖乖的降低时钟,按照上沿输出下沿获取方式工作,只是时钟频率刚好要降低一半。
还有一种方法,也是比较好的方法,加长的线在原来基础上再多延迟1个时钟周期,比如原来SPI频率最高只能到10MHz(100ns),频率不变情况下,线你再加长一点点可不行,干脆加地很长,让增加部分双向延迟等于1个周期100ns或小一点,让主机的SCK对MISO采集多偏移1个时钟周期。这样带来的问题是对于主机采集MISO来说,多出一个没用的最高位,但最低位不见了,怎么办?这个问题是可以解决的,比如你要传一个字节8bit数据,可以把SPI设定为16bit模式,收到之后再移位回来就行,这种方法确实可行而且可靠性不会受任何影响,这样SPI速率是不是可以做到很高?
但位数增加以及软件移位也消耗了速度,所以需要自己衡量,这里只是告诉你有这个思想,如果主机是FPGA就不会有这个问题;这种方法特别适合主机发送多接收少的情况,因为对MISO采集移位是主机接收的事,和主机发送、从机接收没有半毛钱关系;如果你接线很长很长的话,甚至可以偏移几个时钟周期,但下面要说的余量要大一些;按这样算的话,SPI通信速率20MHz传几十米完全没问题!
到这里可能会有人问我,如果拉几十米的线,我该怎么知道SPI时钟频率设置多少合适? 最好的方法是: 大概计算SPI最高频率->实验测试SPI可靠通信最高频率->将SPI时钟频率降低个8至几十ns以保证有一定的余量.
根据上面提供的SPI时钟频率和最大通信线长(从机下沿获取下沿输出),我们就可以大概算出1米线造成的双向延迟是多少,这样我们就可以根据需要的通信距离大概算出SPI可以工作在什么时钟频率,5米@15MHz(66.6ns),8米@10MHz(100ns)-->1米双向延迟11.1ns左右.
如果从机工作在正常时序--上沿获取下沿输出,由前面我们可以推断出线长和最高速率:2米@15MHz(66.6ns),3.5米@10MHz(100ns);如果使用前面所说的"延迟偏移"方法,那么我们可以推断出:
偏移1个周期线长和最高速率是: 8米@15MHz(66.6ns),17米@10MHz(100ns).
偏移2个周期线长和最高速率是: 14米@15MHz(66.6ns),26米@10MHz(100ns).
偏移3个周期线长和最高速率是: 20米@15MHz(66.6ns),35米@10MHz(100ns).
15MHz速率下线长由2米提高到20米,"延迟偏移"方法很厉害吧?

如果使用24+1的DVI线,还可以增加三组片选即总共四组片选信号,如果用编解码方式就可以组建成带16个从机的SPI差分总线(编解码器用高速的):

备注[1]:对于主机接收来说,每一个从机的环路延迟都不一样,如果使用"延迟偏移"的方法接收,那么主机获取MISO输入就要区别对待每个从机的环路延迟(包括线和器件),比如某几个从机环路延迟偏移1个周期,某几个却是2个或几个周期...,这个问题暂时没有很好的解决方法,除非你有办法在主机启动时做个自动检测机制.
备注[2]:如何把握好每个从机环路延迟?要深刻理解前面的内容,还要注意器件的延迟是个范围值(所以余量很重要),否则做出来的东西不是稳定可靠的!

下面是SPI差分超远距离传输的实际应用,下图的"SPI显示器"使用8米24+1 DVI线(28AWG, Ø=7.3),显示器通过DVI供电,触摸屏、鼠标、键盘也是通过SPI回传给STM32,所以,显示器和主机只有1根接线,SPI时钟频率最高10MHz(作为从机下沿获取下沿输出),这个显示器已经申请专利并获得授权,SPI差分通信本身并非专利:


下面是"SPI显示器"使用16米24+1 DVI线(28AWG, Ø=7.3),使用"延迟偏移"2个周期方法,线长和最高速率是:16米@15MHz(作为从机下沿获取下沿输出):


看到这里,你可能会发现一个问题,对于一个显示器来说,10MHz的SPI速度怎么可能够用?这是因为这个"SPI显示器"并非像一般显示器那样传输RGB像素数据,而是用指令控制显示的。打个比方,要显示器显示一个矩形,那么单片机只需要发送矩形的坐标、颜色、长、宽给显示器,显示器再去执行这个指令,生成矩形RGB数据并写入内部显存中。其实这只是基本原理,这个显示器最大的特点在于可以和界面软件库emWin无缝衔接,作为emWin的图形加速显示屏,利用显示器强大的图形处理能力,还有大容量FLASH储存字库和图片,还有双显存设计防止"拉窗帘"现象,让emWin的界面显示效果发挥的淋漓尽致。

下面是显示器DVI接口的引脚定义,把供电VCC定义在中间4个引脚好处是:(1)线够大(2)可以使用18+1 DVI线也可以使用24+1 DVI线,使用18+1线时显示器由外部电源适配器供电.
如果你的主机和从机都是FPGA,那就更好了!加上中间3组差分引脚,你可以实现2对MOSI加2对MISO,或者4对MOSI加1对MISO,那传输速度就不得了了!而且还可以省掉TTL、LVDS互转芯片:


SPI作为同步、单向、推挽串行高速接口,它的扩展性和可转换性是非常强大的,我在想,以后工控设备主机是不是可以像串口DB9那样配备一个这样的"DVI接口"呢?

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?注册

x

阿莫论坛20周年了!感谢大家的支持与爱护!!

月入3000的是反美的。收入3万是亲美的。收入30万是移民美国的。收入300万是取得绿卡后回国,教唆那些3000来反美的!

出0入475汤圆

发表于 2018-12-3 10:43:13 来自手机 | 显示全部楼层
没看完,简陋的挑了几个字看到,实际上就是串口屏?  spi串口而已?

出0入0汤圆

发表于 2018-12-3 10:45:05 | 显示全部楼层
1a2b3c 发表于 2018-12-3 10:43
没看完,简陋的挑了几个字看到,实际上就是串口屏?  spi串口而已?

本质就是那么回事,不过是跑SPI总线,速度比串口快

出0入0汤圆

发表于 2018-12-3 11:07:25 | 显示全部楼层
有创意

出0入4汤圆

发表于 2018-12-3 11:07:39 | 显示全部楼层
如果是串口屏的话 看不出来比 485  can的优点啊。

这个应用我觉得痛点在接spi从设备上,比如某些spi接口的传感器前端。其实几年前我就发过贴问过spi长距离通信的问题。

出0入0汤圆

发表于 2018-12-3 11:08:52 | 显示全部楼层
研究一下channel link 协议,可能有更多我收获

出0入0汤圆

发表于 2018-12-3 11:45:37 | 显示全部楼层
SPI长线通信 mark
感谢楼主分享~

出150入135汤圆

 楼主| 发表于 2018-12-3 11:59:08 来自手机 | 显示全部楼层
mubei 发表于 2018-12-3 10:45
本质就是那么回事,不过是跑SPI总线,速度比串口快

确实类似于串口屏,只不过需要做emwin的显示屏,配合emwin出界面,要用SPI口速度才够

出150入135汤圆

 楼主| 发表于 2018-12-3 12:08:10 来自手机 | 显示全部楼层
本帖最后由 neqee 于 2018-12-3 12:09 编辑
huarana 发表于 2018-12-3 11:07
如果是串口屏的话 看不出来比 485  can的优点啊。

这个应用我觉得痛点在接spi从设备上,比如某些spi接口的 ...


你是说显示器也挂在总线上做从机吗?这样可能总线负担比较大,因为emwin数据量还是挺大的。像文中所说长线通信方法,做一般数据总线挂多个从机用途没问题,不过具体可能还需要评估并衡量,最大问题还是延迟,还有从机数量

出150入135汤圆

 楼主| 发表于 2018-12-3 12:11:20 来自手机 | 显示全部楼层
老徐 发表于 2018-12-3 11:08
研究一下channel link 协议,可能有更多我收获

我也看看,谢谢!

出150入135汤圆

 楼主| 发表于 2018-12-3 12:12:34 | 显示全部楼层
pan.xuehan 发表于 2018-12-3 11:45
SPI长线通信 mark
感谢楼主分享~

出0入0汤圆

发表于 2018-12-3 23:57:28 | 显示全部楼层
这个创意不错;但是显示还是不如使用套件来的快些;
成本也是个问题;完全不如使用树莓派+网线

出615入1076汤圆

发表于 2018-12-4 02:54:13 来自手机 | 显示全部楼层
本帖最后由 dukelec 于 2018-12-4 02:58 编辑

差分 SPI 要接那麼多線。。。
就算加多週期能支持遠距離,但近距離就又不支持了,我覺得這樣要求客戶會被吐槽的。。。
覺得沒有 CDBUS 簡潔,速度也夠,最近還出了一個變種,針對節點少的高速應用做了優化,文檔正在更新中。。。

出70入145汤圆

发表于 2018-12-4 07:26:51 来自手机 | 显示全部楼层
谢谢分享,里面的思路和计算方法很有价值,对于理解高速情况下的数据处理简单易懂

出150入135汤圆

 楼主| 发表于 2018-12-10 10:11:55 | 显示全部楼层
pzt 发表于 2018-12-3 23:57
这个创意不错;但是显示还是不如使用套件来的快些;
成本也是个问题;完全不如使用树莓派+网线 ...

只有适合自己的才是最好的,在我看来树莓派和RJ45接口的可靠性还有待考验..

出150入135汤圆

 楼主| 发表于 2018-12-10 10:36:46 | 显示全部楼层
dukelec 发表于 2018-12-4 02:54
差分 SPI 要接那麼多線。。。
就算加多週期能支持遠距離,但近距離就又不支持了,我覺得這樣要求客戶會被吐 ...

我大概看了下CDBUS,如果我没有理解错的话应该还需要外挂一个CPLD做物理协议层(有开源IP核),经过CPLD物理协议层之后再通过RS485走总线,而MCU和CPLD的通信可以是串口、SPI、I2C等等,速率可以做到10Mbps以上.因为涉及的东西比较多,还有阅读大量资料,还要会用CPLD,我怎么感觉要让这个CDBUS总线非常稳定可靠地工作并没有那么容易呢?

出150入135汤圆

 楼主| 发表于 2018-12-10 10:38:14 | 显示全部楼层
hailing 发表于 2018-12-4 07:26
谢谢分享,里面的思路和计算方法很有价值,对于理解高速情况下的数据处理简单易懂 ...

这也是我写这篇文章的初衷...

出615入1076汤圆

发表于 2018-12-10 11:19:36 | 显示全部楼层
本帖最后由 dukelec 于 2018-12-10 11:35 编辑
neqee 发表于 2018-12-10 10:36
我大概看了下CDBUS,如果我没有理解错的话应该还需要外挂一个CPLD做物理协议层(有开源IP核),经过CPLD物理 ...


MCU 和 CPLD/FPGA 的通信是 SPI 或 I2C,没有串口。(基础款 总线速率 10 Mbps,SPI 速率 20 Mbit/S).
如果不想自己整 CPLD/FPGA, 也有现成可以使用的模组(基础款 CDCTL-B、高阶款 CDCTL-H、mPCIe 多路板卡 CDCTL-P)。
有支持 STM32 的库,也有示例工程,再加上寄存器定义本来就很简单,上手应该很快。

最新的变种 CDBUS-BR (Break Sync)  更加方便软件实现,不过 STM32 自身的 UART 本身速度有限(记得 103 是 4.5 Mbps),不过一般用也够了。
不够的话,CDBUS-BR FPGA 硬件实现更加适合节点偏少的高速应用:
用 MAX10 FPGA 做的高阶模组可以支持到 40 Mbps,这是优化之前的数据,现在应该能把 TI 的 RS485 收发器 SN65HVD78 的速率用满(50 Mbps)。

备注:
CDBUS-BR 文档已经在我之前发的帖子中同步更新(签名链接 123 楼),GitHub cdbus_ip 页面也有更新。
CDBUS-BR 的 STM32 纯软件实现代码也很快会发布出来。

出0入0汤圆

发表于 2018-12-10 12:38:05 | 显示全部楼层
记号18楼 ,学习了

出0入0汤圆

发表于 2018-12-10 14:22:25 来自手机 | 显示全部楼层
长距离时钟和数据分开是不稳定的,楼主可以参考一下同步编码的知识,时钟和数据编码到一根差分线中,这样就收发各一对差分线,成本几块钱加个cpld就行了

出0入0汤圆

发表于 2018-12-10 15:41:29 来自手机 | 显示全部楼层
测井仪器

出150入135汤圆

 楼主| 发表于 2018-12-11 09:10:37 | 显示全部楼层
dukelec 发表于 2018-12-10 11:19
MCU 和 CPLD/FPGA 的通信是 SPI 或 I2C,没有串口。(基础款 总线速率 10 Mbps,SPI 速率 20 Mbit/S).
如 ...

原来CDBUS是你自己发明的总线,厉害!
请问下是怎样实现10、20、30MHz的RS485异步信号采集?IP核里面校验和重发机制是怎样的?应该在单片机端还需要读总线发送状态吧,这样单片机是如何实现DMA发送?

出615入1076汤圆

发表于 2018-12-11 12:23:43 | 显示全部楼层
本帖最后由 dukelec 于 2018-12-11 12:53 编辑
neqee 发表于 2018-12-11 09:10
原来CDBUS是你自己发明的总线,厉害!
请问下是怎样实现10、20、30MHz的RS485异步信号采集?IP核里面校验 ...


跟 MCU 采样 UART 相似,都是用更高的频率来采样:
STM32 一般是固定 16x 倍频采样,部分型号支持 8x 倍频采样,不过该频率是独立产生,波特率生成计数器不会同步 开始位 的下降沿,优点是方便,节省资源。
cdbus_ip 采用的是动态倍频采样,可以指定任意大于等于 4x 的倍频采样,波特率生成计数器会在 开始位 的下降沿清零同步,优点是波特率计算方便、速率高、各节点同步性好。
(cdctl-b 主频默认是 40MHz,÷4x = 10Mbps,÷5x = 8Mbps 以此类推。)

固定倍频采样还方便多次采样,譬如 STM32 固定在中间的位置采样 3 次,以判断数据是否受到干扰;
而带完整协议的 cdbus_ip 每个 bit 只采样 1 次,最后通过 CRC 字段校验整个帧。

默认的校验机制你可以参考 cdbus_ip 文档中的动图,发送方 MCU 把不含 CRC 的一帧数据写入 cdbus_ip, cdbus_ip 在发送数据的时候计算 CRC 并在一帧的最后两个字节把生成的 CRC 发送出去;
接收方的 cdbus_ip 在接收包含 CRC 的完整一帧数据后,判断 CRC 是否正确,正确的话通知用户有新的待读数据,错误的话会置位接收错误位,告诉用户数据出错。
(只有在完整收到两个字节及以上的错误数据才可以置位接收错误位,因为 CDBUS 协议第二个字节是目的地址,至少要接收到它。)
(如果启用出错也保存的模式,收到的错误数据依然可以保存下来被 MCU 读取分析。)

如果 cdbus_ip 所在的器件离 MCU 距离较远,担心 SPI 端数据出错的话,可以启用用户 CRC 模式,这种方式下,发送方 MCU 需要把包含 CRC 在内的完整的一帧数据写入 cdbus_ip,
如果 SPI 传输时数据出错,该帧依然会发送出去,只不过接收方会检测到 CRC 错误,从而不会使接收端 MCU 误操作。

CRC 校验出错不会硬件自动重发,需要用户程序自行处理。(另有可选的上层 CDNET 协议栈可以在出错超时后负责重传。)

单片机不用理会总线状态,只要把一帧数据写入 cdbus_ip, 之后cdbus_ip 会自动尝试发送数据,发送完成之后,发送帧所在的内存页面会被硬件释放,
如果有更多数据等待启动发送,则可以使能对应的中断,cdbus_ip 有一个中断脚接到 MCU, 在中断处理程序中启动 SPI 的 DMA 操作,包括读取状态、搬运数据、启动发送等。
具体可以参考 DMA 操作 CDCTL SPI 的库代码:https://github.com/dukelec/cdnet/blob/master/dev/cdctl_it.c
(简单应用的话可以不用中断和 DMA, 在主循环中通过 SPI 访问 cdbus_ip 即可。)
(发送数据的内存页面是乒乓操作,下一帧的数据可以提前写入 cdbus_ip, 等待上一帧发送完毕,直接启动下一帧即可。)

已启动发送的帧,cdbus_ip 会不停的尝试发送,直到成功发送、发送错误、用户手动取消发送。
发送错误只存在 CDBUS-A 使能仲裁的模式下,如果首字节仲裁字段发送出去的数据为 0 而读回来的数据为 1 则置发送错误位并取消发送。
仲裁模式下,发生了仲裁,且因为自身优先级比其它节点低而暂缓发送,会置位冲突检测标志,但后续依然会不停的重试发送。

出0入0汤圆

发表于 2018-12-12 09:35:51 | 显示全部楼层
感谢分享,收藏了!

出0入4汤圆

发表于 2018-12-13 00:11:40 | 显示全部楼层
非常好的经验,谢谢分享!

出0入0汤圆

发表于 2018-12-13 09:23:15 | 显示全部楼层
学习一下,spi长线通信

出0入4汤圆

发表于 2018-12-13 09:32:21 | 显示全部楼层
是,TI 有一些这样的芯片。有时一个 MCU 的外围设备要被引到设备上比较远的地方,这种方案很有用。

出150入135汤圆

 楼主| 发表于 2018-12-13 21:43:05 | 显示全部楼层
atommann 发表于 2018-12-13 09:32
是,TI 有一些这样的芯片。有时一个 MCU 的外围设备要被引到设备上比较远的地方,这种方案很有用。 ...

最重要的是这种SPI长线通信方式门槛并不高,比较容易实现并能做到稳定可靠,这里只是陈述一种信号传输方法,并不涉及到通信协议,通信协议根据自己实际情况制定...

出150入135汤圆

 楼主| 发表于 2018-12-13 22:52:33 | 显示全部楼层
dukelec 发表于 2018-12-11 12:23
跟 MCU 采样 UART 相似,都是用更高的频率来采样:
STM32 一般是固定 16x 倍频采样,部分型号支持 8x 倍 ...

我在想,既然用CPLD来做协议了,为什么不把校验和重发也做在CPLD 的ip核里面?我知道实现起来还是有一定的难度,但对用户来说,可以摆脱很多工作量,在用户看来,使用就简单很多了!也许你在顾虑MCU和CPLD通信错误怎么办?其实这个问题是可以解决的,MCU读CPLD状态时,读"MCU-CPLD"和"RS485总线"两个校验状态不就可以了?

出615入1076汤圆

发表于 2018-12-14 01:08:03 | 显示全部楼层
本帖最后由 dukelec 于 2018-12-14 01:18 编辑
neqee 发表于 2018-12-13 22:52
我在想,既然用CPLD来做协议了,为什么不把校验和重发也做在CPLD 的ip核里面?我知道实现起来还是有一定的 ...


校验已经做在 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 库)自动处理,不会麻烦到用户(就算用户不用协议栈,自行搞一个超时重传机制也不麻烦)。

出235入235汤圆

发表于 2018-12-14 09:17:29 | 显示全部楼层
感谢分享!大家有STM32做SPI从设备的案例吗?

出0入0汤圆

发表于 2018-12-14 09:26:25 | 显示全部楼层
那个DVI线也不便宜吧,有那线钱两端都搞个以太网转发器,直接上网线。当然也有这样应用的,范围不大。

出150入135汤圆

 楼主| 发表于 2018-12-14 12:08:42 来自手机 | 显示全部楼层
本帖最后由 neqee 于 2018-12-14 12:18 编辑
tangkuan660 发表于 2018-12-14 09:26
那个DVI线也不便宜吧,有那线钱两端都搞个以太网转发器,直接上网线。当然也有这样应用的,范围不大。 ...


如果用18+1的线,价格和带屏蔽的网线是差不多的

出0入0汤圆

发表于 2018-12-14 14:26:34 | 显示全部楼层
很不错的文章!

出0入24汤圆

发表于 2018-12-17 22:28:21 | 显示全部楼层
增加一组差分线,把SCK再原封不动传回来,这个SCK的延迟跟MISO的是一致的,同步的
再用一个SPI外设,工作在从设备模式,接上面的SCK和MISO

出0入0汤圆

发表于 2018-12-18 08:23:30 来自手机 | 显示全部楼层
20061002838 发表于 2018-12-17 22:28
增加一组差分线,把SCK再原封不动传回来,这个SCK的延迟跟MISO的是一致的,同步的
再用一个SPI外设,工作在 ...

两个spi 都做单向用  确实简单了

出0入0汤圆

发表于 2018-12-18 08:51:35 | 显示全部楼层
难得的技术文章,为各位点赞!

出0入0汤圆

发表于 2018-12-18 09:42:53 | 显示全部楼层
很不错的文章!谢谢分享

出150入135汤圆

 楼主| 发表于 2018-12-19 11:50:59 | 显示全部楼层
本帖最后由 neqee 于 2018-12-19 11:57 编辑
20061002838 发表于 2018-12-17 22:28
增加一组差分线,把SCK再原封不动传回来,这个SCK的延迟跟MISO的是一致的,同步的
再用一个SPI外设,工作在 ...


这个想法很好,不过估计没人这样用,两个单片机,一个发一个收,FPGA就没问题

出0入24汤圆

发表于 2018-12-19 18:50:16 | 显示全部楼层
neqee 发表于 2018-12-19 11:50
这个想法很好,不过估计没人这样用,两个单片机,一个发一个收,FPGA就没问题 ...

用有两个SPI外设的单片机就是了
用FPGA的话,可以采用补偿传播延迟的方式,参考EnDat

出0入0汤圆

发表于 2019-2-21 22:18:30 | 显示全部楼层
SPI 远距离 好文章,谢谢共享

出0入0汤圆

发表于 2019-4-20 13:12:33 | 显示全部楼层
本帖最后由 hong7817987 于 2019-4-20 13:17 编辑

如果速度不是很高,比如5M,那么能不能直接就用普通的485芯片来传输?我看25M  50M的485芯片都有
前提是距离也不能太远

出10入12汤圆

发表于 2019-4-20 23:55:12 | 显示全部楼层
真是杀鸡用导弹……
你都能上LVDS了,还用SPI这种东西?

出0入0汤圆

发表于 2019-4-21 00:32:24 | 显示全部楼层
hugohehuan 发表于 2019-4-20 23:55
真是杀鸡用导弹……
你都能上LVDS了,还用SPI这种东西?


我觉的也是这个理,呵呵。

另外,如果长距离,还可以考虑用WIFI、光纤等,这个速度和距离更快更远。

出0入0汤圆

发表于 2019-4-21 13:04:50 来自手机 | 显示全部楼层
各种长距离通信专门干这个的,电路通用,材料好买。自己再发明一个就是重复造轮子。不如做个网口转SPI

出0入0汤圆

发表于 2019-5-7 19:30:42 | 显示全部楼层
好文,要的就是这种深入一点的.

出0入984汤圆

发表于 2019-5-7 19:45:41 | 显示全部楼层
记得spdif的光纤收发器巨便宜,不知长距离下可靠性如何
回帖提示: 反政府言论将被立即封锁ID 在按“提交”前,请自问一下:我这样表达会给举报吗,会给自己惹麻烦吗? 另外:尽量不要使用Mark、顶等没有意义的回复。不得大量使用大字体和彩色字。【本论坛不允许直接上传手机拍摄图片,浪费大家下载带宽和论坛服务器空间,请压缩后(图片小于1兆)才上传。压缩方法可以在微信里面发给自己(不要勾选“原图),然后下载,就能得到压缩后的图片】。另外,手机版只能上传图片,要上传附件需要切换到电脑版(不需要使用电脑,手机上切换到电脑版就行,页面底部)。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

手机版|Archiver|amobbs.com 阿莫电子技术论坛 ( 粤ICP备2022115958号, 版权所有:东莞阿莫电子贸易商行 创办于2004年 (公安交互式论坛备案:44190002001997 ) )

GMT+8, 2024-4-25 12:27

© Since 2004 www.amobbs.com, 原www.ourdev.cn, 原www.ouravr.com

快速回复 返回顶部 返回列表