大家觉得 CDBUS 这个带仲裁的 RS485 怎么样？跟 CAN 比呢？

cl1cl1cl1cl1 · 发表于 2018-7-18 06:21:28

楼主的用103性能可以达到多少速度？

dukelec · 发表于 2018-7-18 11:16:06

cl1cl1cl1cl1 发表于 2018-7-18 06:21
楼主的用103性能可以达到多少速度？

你是指我在 17 樓說的 “单片机软件模拟仲裁我之前有写过代码，基于 STM32F103” 這個嗎？

速度當時測試是 57600 和 115200 之間，所以只能是選擇 57600 來當最大使用，CPU 已經跑到 72MHz 了，用的是 cube 生成的代碼，已經刪掉了用不到的浪費時間的代碼，如果繼續優化應該還能再快一些。

（P.s. 系統定時器中斷頻率是兩倍於波特率的關係。）

cl1cl1cl1cl1 · 发表于 2018-7-18 20:40:24

dukelec 发表于 2018-6-13 13:53
半驱指的就是弱 1 强 0：

弱 1 由 A B 线上的电阻提供，此时 DE 脚为低电平不使能输出即可（DI 虽 ...

每位进行比较可以换成首字节发完后进行一次比较，这样对硬件要求可以降低些，个人看法。

xxc007 · 发表于 2018-7-18 23:17:17

好牛逼啊

dukelec · 发表于 2018-7-19 03:13:29

cl1cl1cl1cl1 发表于 2018-7-18 20:40
每位进行比较可以换成首字节发完后进行一次比较，这样对硬件要求可以降低些，个人看法。 ...

是的，很多人這樣做，但要注意：

首字節依然要半驅輸出，否則發生衝突時，由於線路本身存在電阻，各節點收回的數據很可能與自己發送的相同，因此檢測不到衝突，這點經常被人忽略。
（用單片機軟件實現仲裁的時候，沒必要搞雙速率，也沒必要切換成標準的推輓差分輸出，把 TX 數據反向接 DE 即可，原 TX 輸入接地。）

按字節單位仲裁的話依然可以實現非破壞仲裁，但最多支持的設備數量比較少，只能支持 0x00 0x80 0xc0 0xe0 0xf0 0xf8 0xfc 0xfe 0xff 共 9 個地址（ 1 和 0 不交錯）。

用硬件控制器的好處除了效率高，更重要的是方便，不用寫那麼多代碼。。。

cl1cl1cl1cl1 · 发表于 2018-7-19 04:34:58

dukelec 发表于 2018-7-19 03:13
是的，很多人這樣做，但要注意：

首字節依然要半驅輸出，否則發生衝突時，由於線路本身存在電阻，各節點 ...

1、半驱条件下首字节检测，应该与每位检测具有同等的范围，如果是只能检测0x80+x，那么整个cddus的基础都有问题了。
2、tx反向接到de端可靠性极差，发送数据时有毛刺，低速率下勉强可以，用在多设备长距离时不能正常通讯是很平常的事情。

dukelec · 发表于 2018-7-19 11:34:59

cl1cl1cl1cl1 发表于 2018-7-19 04:34
1、半驱条件下首字节检测，应该与每位检测具有同等的范围，如果是只能检测0x80+x，那么整个cddus的基础都 ...

當然可以不限於我所說的這 9 個地址，只不過檢測到衝突之後可能所有節點都需要等待重傳，而「非破壞仲裁」始終是最高優先級即刻享用總線。

我給的 9 個地址可以優先使用，超過 9 個地址再隨便分配，同樣可以在一定概率上享用到「非破壞仲裁」帶來的高效。

（注：硬件控制器是按位檢測，不用特別指定地址就可以達成「非破壞仲裁」）

你第二點說的低速率大概是什麼範圍？

KunShan_a_dai · 发表于 2018-8-25 17:25:16

dukelec 发表于 2018-6-6 12:00
是的，如果你的产品本来就有用 FPGA, 那么直接用开源免费的 IP 核就好。
如果是 MCU 用，需要实现仲裁的 ...

如果楼主愿意，能直接开源软件模拟的source code是一件好事情，先培养基础使用环境，也是市场推广一种方式；

dukelec · 发表于 2018-8-25 18:57:22

KunShan_a_dai 发表于 2018-8-25 17:25
如果楼主愿意，能直接开源软件模拟的source code是一件好事情，先培养基础使用环境，也是市场推广一种方 ...

好，多謝建議，我會儘量抽時間整理一下之前軟件模擬的代碼，然後放出來，最近快忙哭了。。。

cddx · 发表于 2018-8-26 01:29:56

本帖最后由 cddx 于 2018-8-26 01:37 编辑

哈哈，好熟悉的话题，10多年前写了个纯软件的CSMA485，虐狗啊，万恶的资本家多一分钱的硬件钱都不愿花！

dukelec · 发表于 2018-8-26 18:15:06

本帖最后由 dukelec 于 2018-8-27 17:59 编辑

最新版 v7 增加了组播功能，英文 multicast.

实现的方法很简单，也很灵活，不强制占用地址范围，在不使用组播的情况下，单条总线依然最多可支持 255 台设备（0~254, 地址 255 强制为广播地址）。

只是建议把地址 0xe0 到 0xfe 保留为组播地址（共 31 个地址），这样普通地址依然有 223 个可用，多数情况也足够了。

使用组播的场景示例：
一条总线有 10 个电机（地址 0~9）、2 个抓子（地址 10~11），我们可用同时把所有电机加入 240 这个组播地址，把所有抓子加入 241.
当我们想同时控制所有电机时，往 240 这个地址发送数据包即可，10 台电机收到之后，如果需要回复，则使用自身地址 0~9 做为源地址。

如果没有组播，可以使用广播代替，但这样不相关节点也会被打扰，尽管上层软件可以过滤。

（如果对同步性要求没那么高，单独发 10 条命令给 10 台电机是更常用的做法，毕竟 CDBUS 支持迸发，同步性已经很不错。
迸发的意思是指主机可以连续发送 10 条命令给 10 台电机，然后再等 10 台电机慢慢回复。
不支持迸发的传统方式：主机发一条命令就要等一条回复，等待时间随设备数量翻倍。）

目前受限硬件资源，只添加了两个组播过滤器，意思是每个节点最多只能加入两个组播地址，大多数情况够用了。
（如果需要更多组播地址，可以单独定制，比如不同时支持 SPI 和 I2C 就可以省出资源支持更多组播过滤器。）

---------------------------------------------------------------------

两个多月前的上一版本 v6 增加了全双工通讯功能，主要用于单片机串口不够的情况下扩展串口。

且扩展出来的串口也是自带 CDBUS 协议便是了。

其实，单片机串口一般都够用，反倒是树莓派这些处理器的串口比较紧缺，譬如树莓派对外就一个串口，默认是用于内核打印和用户登录，如果拿来做设备控制，那么出了问题（譬如死机）就没办法调试了。。。

單片機的串口波特率受限于 CPU 和其它外設頻率，速度滿足不了或分不到想要的波特率的時候，也可以考慮外部擴展串口。

---------------------------------------------------------------------

目前为止，每一版更新都是向前兼容的。

且每次改动都会想很久，会很谨慎，改完也会大量测试，哪怕改动部分很小。

最後順便一提的是，另外的高速版硬件現在支持到 40 Mbps 波特率。

---------------------------------------------------------------------

接下来，IP 核会再出一个 32 位的版本，将会更加方便 FPGA 用户使用。

也会推出实时转发的桥接器，方便长距离通讯。（目前桥接的方案是单片机收到完整的数据包之后再转发。）

Mini PCIe 的版本也准备就绪了，硬件迭代了两版已经稳定。可以转接大的 PCIe 卡，也可以转更小的 M.2 卡。

zhaogq · 发表于 2018-9-26 17:04:05

dukelec 发表于 2018-8-26 18:15
最新版 v7 增加了组播功能，英文 multicast.

实现的方法很简单，也很灵活，不强制占用地址范围，在不使 ...

有评估用的硬件demo吗

chenwei1919 · 发表于 2018-9-26 17:29:16

好牛逼，mark一下

hymculolo · 发表于 2018-9-26 19:57:32

不明觉厉，楼主大神。

xufeng3000 · 发表于 2018-9-26 21:27:46

成本和可靠性如何？

funnynypd · 发表于 2018-9-26 21:46:08

>现在很多集成CAN控制器的Cortex-M0单片机价格都低于2美金，，
>甚至低于1美金
Microchip PIC18F26K83, $1.5 @5000 pcs.

dukelec · 发表于 2018-9-27 14:31:41

zhaogq 发表于 2018-9-26 17:04
有评估用的硬件demo吗

有很多款：
・可以用免焊接人頭板，通過杜邦線連接第三方的 STM32 開發板／核心板，或其它非 STM32 都可以通過此方法，也可以用 FT232H 等 USB 轉 SPI / I2C 的方式通過 PC 測試。
・要一體化的也可以通過 CDBUS Bridge 這個小盒子中的板子來評估，可以把板子當作開發板，上面用的 MCU 是 STM32F105.

人頭板和 Bridge 都可以在第一頁找到圖片。

zhaogq · 发表于 2018-9-27 14:53:34

dukelec 发表于 2018-9-27 14:31
有很多款：
・可以用免焊接人頭板，通過杜邦線連接第三方的 STM32 開發板／核心板，或其它非 STM32 都 ...

你们有评估套件购买的链接吗

dukelec · 发表于 2018-9-27 15:06:04

zhaogq 发表于 2018-9-27 14:53
你们有评估套件购买的链接吗

歡迎訪問我的九年老店：https://dukelec.taobao.com
Bridge 不要外殼的話可以便宜一些。

dukelec · 发表于 2018-9-27 15:16:41

xufeng3000 发表于 2018-9-26 21:27
成本和可靠性如何？

成本第一頁可以找到階梯報價，等做出專用芯片價格會大幅度降低，歡迎芯片行業的朋友一起合作。

可靠性方面，之前做壓力測試，兩個 CDBUS Bridge 盒子之間互傳幾億個包，成功避讓衝突幾萬次，無任何丟包。
接下來還會做更多壓力測試。

yufeistudio · 发表于 2018-11-16 13:08:25

shiva_shiva 发表于 2018-6-6 08:45
RS485 的 CDBUS 协议可以使用独立控制器实现按位仲裁，跟 CAN 的原理一样，但性能、易用性貌似都比 CAN 要 ...

不是吹牛看看西门子的DP总线

xyhh4 · 发表于 2018-11-18 19:27:11

mark 通信协议

dukelec · 发表于 2018-12-5 16:28:30

本帖最后由 dukelec 于 2018-12-5 20:52 编辑

同步更新一下，CDBUS 推出了一个变种 CDBUS-BS (break sync)

同样是对等通讯，无冲突，且不需要仲裁，单速率，可以实现更高的总线效率。

比较适合节点数较少的应用，同时也更加方便软件模拟（STM32 纯软件模拟的版本很快也会给出）。

klander · 发表于 2018-12-26 11:17:22

楼主，请教一下，同一个板上，多个芯片主动通讯，用什么协议好？

dukelec · 发表于 2018-12-26 11:51:45

本帖最后由 dukelec 于 2018-12-26 11:56 编辑

klander 发表于 2018-12-26 11:17
楼主，请教一下，同一个板上，多个芯片主动通讯，用什么协议好？

可以用我這個帖子的 CDBUS （可以軟件搭配 UART 硬件實現 CDBUS-BS; 也可以不加接口芯片，用電阻上拉的單線串口），如果不差錢和空間，同樣可以上硬件控制器和 485 接口芯片，最簡單高效。

另外就是用 I2C 硬件，STM32 的 I2C 是支持多主仲裁的，但主主之間能否通訊，以及主主通訊遇到仲裁，棄權者是否能正確接收我不太清楚，如果可以的話，數據格式同樣可以用 CDBUS, 這樣上層代碼就比較通用了。
（I2C 事比較多，配置麻煩，還有鎖死的問題，遇到後要發多個 SCK 退出鎖定。）

CAN 也可以考慮，如果不介意 8-byte 限制的話。

Seven-007 · 发表于 2019-4-7 14:35:00

dukelec 发表于 2018-6-6 12:00
是的，如果你的产品本来就有用 FPGA, 那么直接用开源免费的 IP 核就好。
如果是 MCU 用，需要实现仲裁的 ...

你好，楼主，
软件模拟的仲裁，可以开放出来参考下吗。
对软件模拟这个比较感兴趣。

dukelec · 发表于 2019-4-17 03:30:37

Seven-007 发表于 2019-4-7 14:35
你好，楼主，
软件模拟的仲裁，可以开放出来参考下吗。
对软件模拟这个比较感兴趣。 ...

对于仲裁模式（CDBUS-A），我很久以前写了一个通过 GPIO 端口实现协议的测试软件。它效率低下而且已经过时了，我都懶得整理代碼了，僅供參考。

现在，我认为我们可以直接使用 HW UART，它可以简化很多并且更加高效。
不過，我们需要通过硬件将 TX 的信号反向接到 DE 引脚。
流程是：同时启动发送和启动定时器，确保在第一个字节的每个位的中间位置产生中断，在中断服务程序中检查是否存在冲突。如果存在冲突，则通过将 TX 引脚更改为输入来中止发送。

性能沒有要求的場合，傳統的隨機延時退讓的方法也不錯。
對於性能要求高的場合，還是建議使用 CDCTL-Bx 硬件控制器。

lihui_mc · 发表于 2019-4-30 06:26:57

可以做出一个demo，在一根总线上传输几路摄像头视频，这样这个方案的优势就体现出来了。相对485，具有多主机特性。相对以太网，成本低。应该会吸引人找你。

kinsno · 发表于 2019-5-7 21:54:08

dukelec 发表于 2019-4-17 03:30
对于仲裁模式（CDBUS-A），我很久以前写了一个通过 GPIO 端口实现协议的测试软件。它效率低下而且已经过 ...

MCU软件模拟这个，需要普通485芯片在硬件上的配合吧，需要多余的IO，或电阻上，或别的变形用法，这部分硬件能分亨一下吗？

kinsno · 发表于 2019-5-7 22:33:33

dukelec 发表于 2018-6-13 14:01
给你一个实际控制接口芯片发送数据的时序图：

正好是今天看到了你在另外一个贴子里秀你的手电简，于是跟进了这个贴子。。请教几个问题如下。我们先按正常的RS485，不作任何硬件上的改动，如何能解决这几个问题呢，

1. 弱1的上拉电阻取多大：弱1的时候，实际上就是强行TXD发1，而RE脚下拉（拉收状态），这个时侯A脚电平为弱1，实际上靠上拉电阻来现实的，关键在于上拉电阻家接在一起的时候，这是并联的，那么取多大的电阻值，此时弱1才能被识别成1，而不是中间态。

2. 光看到有回读，所谓的回读，总不会是靠UART的RXD来回读吧，是不是应该还要一个第3方IO接到哪里去，依赖于它读取的电平，与TX发出去的电平作比较呢？

谢谢。。

kinsno · 发表于 2019-5-7 22:58:48

dukelec 发表于 2018-6-13 14:01
给你一个实际控制接口芯片发送数据的时序图：

我又来了，上面2个贴子，也请麻烦答复下，今天正好兴致起。。

我去GITHUB上看了下，对于头3个字节以及寄存器不是很明白，继续请教您。

1. 头3个字节，0C,0D, LEN, 前2个字节是固定的，还是有说法，还是和寄存器有关，取这2个值的目的是什么，我位般都是采用AA,55,CC,33之类的值嘛，要不就随电力跑什么 0x68之类了。。

2. 寄存器上面，我看了有好几列，其中有3列，分别为“地址访问默认” ，地址和默认分别是指？地址是不是指上面第1个问题所说的TXD发送的第1个字节，而默认则是指TXD读回的值？地址和默认，分别是指，分别怎么用呢？

dukelec · 发表于 2019-5-8 02:32:50

lihui_mc 发表于 2019-4-30 06:26
可以做出一个demo，在一根总线上传输几路摄像头视频，这样这个方案的优势就体现出来了。相对485，具有多主 ...

目前的 demo 是一路視頻 + 一路伺服電機控制，本以為可以足夠說明問題，不過估計 demo 拍攝的太花俏，很多小夥伴沒弄清楚我那個 demo 在幹啥。

dukelec · 发表于 2019-5-8 02:33:39

kinsno 发表于 2019-5-7 21:54
MCU软件模拟这个，需要普通485芯片在硬件上的配合吧，需要多余的IO，或电阻上，或别的变形用法，这部分硬 ...

可以用標準硬件，純用 IO 口模擬串口，127 樓的壓縮包代碼就是這樣操作的，但效率低，CPU 佔用多。

也可以用 MCU 的 UART 硬件，配合傳統常用的省掉方向切換的電路，電路 127 樓的文字部分有描述，485 芯片 DI 接地，DE 接 MCU TX 信號的取反，用一個 NPN 的三極管或 NMOS 取反。
（手機不太方便上圖。）

dukelec · 发表于 2019-5-8 02:47:30

本帖最后由 dukelec 于 2019-5-8 02:51 编辑

kinsno 发表于 2019-5-7 22:33
正好是今天看到了你在另外一个贴子里秀你的手电简，于是跟进了这个贴子。。请教几个问题如下。我们先按正 ...

對於接收者來說，是不存在中間態的，非 0 即 1。
485 芯片的接收使能一直有效，不用管它。

上下拉電阻大小會影響通訊速率，速率高的時候建議使用 330 歐的上拉和下拉電阻，一條總線只有一個節點接上下拉電阻，或者首尾兩台也可以。

其它節點也可以接比較大的上下拉電阻，防止沒有接總線的時候，Rx 一直為 0. 譬如 200K 歐，即使多個節點並聯，和 330 歐相比，也可以忽略不計。

終端電阻 120 歐可以不接，因為 330 歐的上下拉電阻本質上也是終端電阻。接的話也可以，靜態電流會比較大，可以考慮通過 120 歐串電容的方式避免。

MCU Rx 脚雖然是功能腳，但依然可以直接讀它的 GPIO 輸入值，就算個別 MCU 不支持，臨時切換回 IO 口再讀即可，沒必要額外佔用 IO 口。

dukelec · 发表于 2019-5-8 03:10:43

kinsno 发表于 2019-5-7 22:58
我又来了，上面2个贴子，也请麻烦答复下，今天正好兴致起。。

我去GITHUB上看了下，对于头3个字节以及寄 ...

0C 0D 只是一個例子，分別代表當前數據包的發送方地址和接收方地址。
有的時候地址可以寫死，譬如電腦和設備通過串口通訊，只有兩個節點，我一般固定電腦地址為 AA，設備地址為 55.

問題 2 的地址是指寄存器地址，默認是指硬件上電后，寄存器的默認值，和總線數據沒有直接關系。

發送數據包和讀數據包是通過訪問內存頁来實現。
每個內存頁對應一個數據包，一個內存頁 256 字節，沒用到的空着不用管。
發送數據有兩個內存頁，為了乒乓操作：正在發送的時候提前寫入下一個包的數據。
接收數據目前是 8 個內存頁，確保 MCU 沒有及時讀取接收到的數據包，也不會丟失。

具體的發送和接收操作，可以看最下方的偽代碼（python 格式）。

kinsno · 发表于 2019-5-8 09:29:37

dukelec 发表于 2019-5-8 02:33
可以用標準硬件，純用 IO 口模擬串口，127 樓的壓縮包代碼就是這樣操作的，但效率低，CPU 佔用多。

也可 ...

大概说一下思路啊，
1. 首先是总线上，大部分设备都要接10K或更大的上下拉电阻，而选择一个器件用330R的上下拉电阻，原因如你所说。
2. 其次，RO接RXD, DI接TXD， DE和RE并联接上拉，这个没问题。
3. 软件处理部分，首先DE脚长期拉低，RXD和TXD并不是功能脚，而是一个普通GPIO，类似于LED或KEY的引脚罢了，我们在低速下面，比如以100US作为间断，TXD不停按照模拟发送字节，而RXD的读IO电平然后组合成一个接收字节，
再比较这2个字节是否相等，
如果相等就XXX进行下一步，比如多来这样的几次，最后确认总线OK了，就切换到正常的串口模式，按正常的波特率发送数，
如果不等则DELAY一会。。
前面采用硬件IO的模式，就是你所说的低速模式，后面切回常的串口模式就是你说的高速模式吧。。

PS：你那个模拟软件，只是用CUBEMX生成的一个工程啊，我看了一下好象关键的代码没有似的，比如CD_485()。。。

dukelec · 发表于 2019-5-8 11:44:16

kinsno 发表于 2019-5-8 09:29
大概说一下思路啊，
1. 首先是总线上，大部分设备都要接10K或更大的上下拉电阻，而选择一个器件用330R的 ...

是的，RXD 读 IO 电平并不是读完一个 byte 才判断，而是判断每一个 bit, 遇到冲突立即取消发送。
也不需要多来几次和加 delay, 只要第一字节没冲突，后面的字节就按传统做法一直发下去，不然就失去用软件模拟和仲裁的意义了。
（因为硬件 UART 的粒度是 byte 为单位，所以才要用读 IO 的方式把粒度提升到 bit；仲裁的意义就是时间可控、冲突无害，不影响高优先级节点的传输，不需要浪费退让等待的时间。）

简单的场合，可以不上仲裁，按照传统的多主方式，总线空闲才发送，字节单位下，遇到冲突停止发送，然后等待一个随机生成的时间后再重发，唯一保留的是 CDBUS 数据包的格式定义。
更简单的是，什么都不管，直接发送，如果超时没有收到回覆，等待随机时间（或按自身地址生成一个固定时间）再重发。

再者，依然是直接使用 HW UART，不过，我们需要通过硬件将 TX 的信号反向接到 DE 引脚，原本的 DI 脚一直接地，RE 也是接地。
流程是：同时启动发送和启动定时器，确保在第一个字节的每个位的中间位置产生中断，在中断服务程序中检查是否存在冲突。如果存在冲突，则通过将 TX 引脚更改为输入来中止发送。

再者，首字节使用 IO 模拟，后续字节使用 HW UART, 这是最麻烦的做法，代码逻辑比较多。

最后，是全部使用 IO 模拟，包括后续字节。浪费 CPU 资源，不推荐。上面废弃的代码压缩包就是这种，用户代码单独放在 usr 目录了。

kinsno · 发表于 2019-5-8 11:47:33

本帖最后由 kinsno 于 2019-5-8 11:56 编辑

dukelec 发表于 2019-5-8 11:44
是的，RXD 读 IO 电平并不是读完一个 byte 才判断，而是判断每一个 bit, 遇到冲突立即取消发送。
也不需 ...

1、DI接地怎么收数据啊。。。

2、按照你这个逻辑，通过TXD发送，然后RXD引脚监控电平，判断冲线忙不忙，如果不忙，倒也好说。。仔细判断，还是有一些漏洞。
   1. 假设A设备在发数据，你B设备一直在监控，那么通过TXD发出去的弱1或强0，会不会影响A设备的正常数据？
   2. 假设有两台设备同时在查总线忙不忙，它两一直在打架。。查到忙以后，总不能一直查下去，对吧，肯定是要要等待，等待是需要时间的，100US，1MS，10MS，这个时间如何确定，是否还是通过随机时来等待。。
   3. 假设N台设备，某2个设备查总线忙之后，大家通过某个固定等待时间，再重新启动监控总线，两台设备又打架了，然后又是固定时间以后，再来监听，它两又打架了？
      如果这个等待时间，采用随机数，但随机数万一，总会有时间相等的时侯啊，总会有冲突的时候啊，肯定还需要一个优先级的问题，这个优先级何以解决？

      如果引入了优先级，又有新的问题，优先级如何配置的问题，通过拨码开关，还是通过出厂前设置，还是？一定程度鸡

dukelec · 发表于 2019-5-8 12:34:21

本帖最后由 dukelec 于 2019-5-8 13:14 编辑

kinsno 发表于 2019-5-8 11:47
晕，DI接地怎么收数据啊。。。

很多人这么用啊，刚随便在网上找的图，原本 RE 接 DE，我改动了一下，把 RE 接地。

DI 虽然接地，但 DE 无效的时候，DI 的 0 数据并不会发送出去，这种电路的效果就是：发送的数据永远是弱 1 强 0，不支持强 1 输出。

上面提到的方法可以再补充一种：

> 再者，依然是直接使用 HW UART，不过，我们需要通过硬件将 TX 的信号反向接到 DE 引脚，原本的 DI 脚一直接地，RE 也是接地。
> 流程是：同时启动发送和启动定时器，确保在第一个字节的每个位的中间位置产生中断，在中断服务程序中检查是否存在冲突。如果存在冲突，则通过将 TX 引脚更改为输入来中止发送。

在此基础上，增加一个 GPO 管脚，切换 DE 和 DI 的接法，发送首字节按照这个图的接法，发送后续数据的时候，再切换为标准强 0 强 1 的接法。
（可以通过 MCU TX 功能脚的 REMAP 到不同 IO 口的功能来实现。）

关于问题 2：
不用主动去查总线是否忙，只要监控到上一个数据包传输完毕（该包由任意节点发出），就认为总线空闲（通常还要再等一个 byte 的时间，或者不用解析数据包，只要一个 byte 时间无人传输数据，就认为总线空闲）。
当 A 已经发送数据的时候，B 收到就认为总线为忙，等着便是。
只有很小的概率，A 和 B 同时发送，这种时候仲裁机制就起到作用了，譬如 A 的优先级更高，那么 A 是不知道 B 也在同时发送数据，B 检测到 A 的存在后退出发送，把总线让给 A, A 当前发的数据包不会被干扰。

可以不用等待，只要总线空闲就可以发送新的数据包。

仲裁的优先级就是地址，推荐软件配置（不知道地址的情况下用广播地址，且只接一台），配置好再接入总线。

如有需要，也有方法动态配置地址，动态配置的过程中，仲裁机制无法保证数据不冲突，但可以通过上层专们的分配地址命令来减少冲突概率，配合多次扫瞄可以确保动态配置无误。
可以参考 https://github.com/dukelec/cdnet#port-1 这个 port-1 命令的定义，它使用过滤和指定随机时间回覆数据防止冲突。

kinsno · 发表于 2019-5-8 13:14:58

dukelec 发表于 2019-5-8 12:34
很多人这么用啊，刚随便在网上找的图，原本 RE 接 DE，我改动了一下，把 RE 接地。

DI 虽然接地，但 DE ...

明白了，需要一个比较完美的协议栈类东西来配合，如果做成标品，确实需要你那个小模块出来，要不然这个要搞的很烦。。
标准的485电路其实也可以搞的啊。。DE置成接收功能，此时RXD读总线数据，但奈何TXD发数据出去，RXD应该是能读回来的，类假串口回弹效果。。

dukelec · 发表于 2019-5-8 13:41:52

kinsno 发表于 2019-5-8 13:14
明白了，需要一个比较完美的协议栈类东西来配合，如果做成标品，确实需要你那个小模块出来，要不然这个要 ...

是的，也可以。

是比较麻烦，所以我现在不追求效率的场合，用单主轮询，或者多主的时候有数据直接发，超时重传。
追求效率和实时性的场合，用模组。

kinsno · 发表于 2019-5-8 13:54:16

本帖最后由 kinsno 于 2019-5-8 13:55 编辑

dukelec 发表于 2018-6-13 13:53
半驱指的就是弱 1 强 0：

弱 1 由 A B 线上的电阻提供，此时 DE 脚为低电平不使能输出即可（DI 虽 ...

特地回过来看了一这个位置，
因为没有测试过，所以对此存有一个疑虑：我说的前提是指标准485，DE接地的时候，你TXD发1，你说这是弱1，实际上TXD发1，根本也发不出去，没有意义啊。。反正总线是挂在3.3V上拉上，你读回来它也是1啊。。

这里是不是可以改为，
100US，不操作TXD，RXD直接读回来1
200US， DE置1，然后TXD发0，RXD读回来0，
300US，不操作TXD，RXD直接读回来1
400US， DE置1，然后TXD发0，RXD读回来0，
。。。。
如此若干回之后，就认为总线是空的，没人来抢了，高优先级的设备开始发送数据。。

为什么不说去操作TXD，因为TXD操作无意义啊。。弱1 不需要去TXD发送高电平的，反正你发了1，它也不出去，这是无用功啊。。所以干脆直接读RXD吧。。省了这一步。。

dukelec · 发表于 2019-5-8 14:52:01

本帖最后由 dukelec 于 2019-5-8 14:55 编辑

kinsno 发表于 2019-5-8 13:54
特地回过来看了一这个位置，
因为没有测试过，所以对此存有一个疑虑：我说的前提是指标准485，DE接地的 ...

> 特地回过来看了一这个位置，
> 因为没有测试过，所以对此存有一个疑虑：我说的前提是指标准485，DE接地的时候，你TXD发1，你说这是弱1，实际上TXD发1，根本也发不出去，没有意义啊。。反正总线是挂在3.3V上拉上，你读回来它也是1啊。。

根本没发出去 != 没有意义，读回来它也不一定是 1，譬如其它节点在发送强 0.

> 这里是不是可以改为，
> 100US，不操作TXD，RXD直接读回来1
> 200US， DE置1，然后TXD发0，RXD读回来0，
> 300US，不操作TXD，RXD直接读回来1
> 400US， DE置1，然后TXD发0，RXD读回来0，
> 。。。。
> 如此若干回之后，就认为总线是空的，没人来抢了，高优先级的设备开始发送数据。。

不需要这样主动测试，其它节点不知道你是在测试还是在发数据。
刚已经说了，总线空闲一段时间，譬如 1 个 byte 的时间，就认为空闲，不用主动测试，不用主动测试，不用主动测试。

> 为什么不说去操作TXD，因为TXD操作无意义啊。。弱1 不需要去TXD发送高电平的，反正你发了1，它也不出去，这是无用功啊。。所以干脆直接读RXD吧。。省了这一步。。

本来就是直接读 RXD，看你怎么理解。TXD 跟随数据位变化方便抓波形观看更直观，也方便其它应用：譬如单线串口总线。

ruzi · 发表于 2019-7-22 20:05:18

收藏备用！谢谢！

armstrong · 发表于 2019-8-11 10:14:02

dukelec 发表于 2018-6-10 04:55
串口通讯完整是异步串行通信，英文是 Asynchronous Serial Communication;
USART 是 UART 的所谓高级版 ...

如果有哪家MCU公司愿意集成CDNET控制器就好了，我也喜欢RS485。用CAN做过个把产品，对线缆要求太高了。到现在，用得最多最稳的还是RS485.

luweiqi1995 · 发表于 2019-11-29 15:18:13

dukelec 发表于 2018-6-13 11:46
只有第一个字节（发送方地址）需要按位回读检测（半驱），过了第一个字节就不再回读检测，切换为传统推挽 ...

楼主你好，如果正在仲裁过程中有其他设备在总线上通讯，如果仲裁过程中总线是强1，此时仲裁设备输出了强0，这种情况干扰了正常通讯，这个是如何解决的？正常通讯的设备是需要重发这一帧数据吗？

dukelec · 发表于 2019-11-29 15:34:01

本帖最后由 dukelec 于 2019-11-29 15:40 编辑

luweiqi1995 发表于 2019-11-29 15:18
楼主你好，如果正在仲裁过程中有其他设备在总线上通讯，如果仲裁过程中总线是强1，此时仲裁设备输出了强0 ...

仲裁模式下，「仲裁过程中总线是强1，此时仲裁设备输出了强0」不会发生，因为首字节仲裁只有弱1 和强0.
侦测到已经有设备通讯的时候，其它想发送数据的设备会等它发送完。
只有大家认为总线空闲的时候，才有可能同时发送数据。

luweiqi1995 · 发表于 2019-11-29 16:40:28

dukelec 发表于 2019-11-29 15:34
仲裁模式下，「仲裁过程中总线是强1，此时仲裁设备输出了强0」不会发生，因为首字节仲裁只有弱1 和强0. ...

好的，明白。

alan8918 · 发表于 2020-2-8 22:27:35

有想法，确实实际应用中需要有485的升级应用，但是CAN的复杂度又高出太多

boceyibiao · 发表于 2020-2-9 09:47:05

价格是个硬伤，国产arm芯片5块钱以内的支持can的多的是，你这个价格可是几倍，可靠性还得验证，也就小众玩玩可以，大批量估计也没敢用的。除非你把价格降到合理的范围内，没办法，国内环境就是这样

pldjn · 发表于 2020-3-7 01:14:34

刚看到这个，感觉思路很好，只不过纯软件IO模拟的话速率太低了。FPGA的话，成本是个问题。如果有更简单的方式就好了。

isakura · 发表于 2020-3-14 00:25:16

看了下，楼主如果推广开了市场很大......

看完后，第一印象就是怎么跟LVDS类似，但是其中又有不一样的地方....

目前LVDS 主要用于视频，有些LVDS里面也有通信数据，但数据量不大，

而楼主的这个既可以用于通信，也可以传输视频，可以类似CAN组网，几乎可以用于整个系统了。。。。。

楼主的这个跟LVDS视频也是需要一个外部收发芯片，不知道楼主可以做到多低的成本
目前市面上的LVDS收发芯片，低至三五元，高至上百都有可能

估计唯一的缺陷可能就是速率方面还有可靠性比LVDS差些，但是从应用场景上来看，多功能兼职无敌了

dukelec · 发表于 2020-3-14 01:15:44

isakura 发表于 2020-3-14 00:25
看了下，楼主如果推广开了市场很大......

看完后，第一印象就是怎么跟LVDS类似，但是其中又有不一样的地方 ...

LVDS 适合高速，距离相对短一点的场合。
而且 CDBUS 控制器接的 PHY 也可以用 MLVDS，不一定要用 RS485.

成本方面，ASIC 开始弄了，应该能做到中国特色芯片格价。

wgainn · 发表于 2020-4-6 16:54:30

mark 带仲裁的485

chendaon · 发表于 2020-4-24 15:27:07

哈哈，用半驱的方式实现总线仲裁，很有创意的做法。

am_shui9jing · 发表于 2020-5-8 15:47:29

MARK,支持仲裁的CDBUS协议

nedly · 发表于 2020-9-1 11:21:50

MARK,支持仲裁的RS485 CDBUS协议

leifeng · 发表于 2020-9-2 10:25:11

dukelec 发表于 2020-3-14 01:15
LVDS 适合高速，距离相对短一点的场合。
而且 CDBUS 控制器接的 PHY 也可以用 MLVDS，不一定要用 RS485.
...

电力载波是否可以考虑搞一下，这个目前做的不怎么好，如果有类似的产品，应该比这个CDBUS更好卖，IoT，智能家居都可以用

lhaoyue · 发表于 2020-9-4 14:55:55

看帖子后，有2个疑问：
1. 如果485总线上，既有485节点，又有cdbus节点，那么cdbus节点是不是可以作为一个485节点，进行如modbus通讯，也就是和老的485设备可以通讯，而cdbus节点之间可以通过cdbus/cdnet协议通讯，也可以用modbus协议通讯？
2. 硬件方面，我的理解是485 PHY + CDCTL 的节点和只有485 PHY的节点是可以正常通讯，对于330R 不太理解，想问下485 PHY需要有特殊改动吗？

dukelec · 发表于 2020-9-4 15:41:52

lhaoyue 发表于 2020-9-4 14:55
看帖子后，有2个疑问：
1. 如果485总线上，既有485节点，又有cdbus节点，那么cdbus节点是不是可以作为一个 ...

基於 485 的 cdbus 本身就是標準 485 通訊，用 485 節點和 cdbus 節點來區分不太合適。

可以用「傳統 485 軟件節點」和「cdctl 硬件控制器」節點來區分，簡稱「軟節點」和「硬節點」。

其中，硬節點只能收發 cdbus 幀格式的數據包。
軟節點即可以收發 cdbus 幀格式的數據包，也可以收發其它格式，譬如 modbus 格式。

如果一條總線上，有多個幀格式，會比較亂，一般不會這樣弄，如果非要這麼弄，只能說，相同格式的節點之間可以正常收發，異己的包丟棄。
cdbus 和 modbus 幀格式不能直接兼容。

硬件方面，cdbus 使用的是標準的 485 電路，傳統的 485 就規定有上下拉電阻，這裏用 330R 只是個人習慣，可以大一些也可以小一些。

xxc007 · 发表于 2020-9-5 08:37:11

正好要用485

lhaoyue · 发表于 2020-9-7 09:49:57

dukelec 发表于 2020-9-4 15:41
基於 485 的 cdbus 本身就是標準 485 通訊，用 485 節點和 cdbus 節點來區分不太合適。

可以用「傳統 48 ...

谢谢您的回复!
这样的话用CDBUS要兼容以前的项目就会遇到问题，CDBUS作为内部总线还不错，对外与其他module或者设备通讯，就不好用了，不知道您这有兼容方案吗？

dukelec · 发表于 2020-9-7 11:39:07

lhaoyue 发表于 2020-9-7 09:49
谢谢您的回复!
这样的话用CDBUS要兼容以前的项目就会遇到问题，CDBUS作为内部总线还不错，对外与其他modu ...

一般自己選擇的話，是優先使用 cdbus，把其它協議轉換爲 cdbus：
可以隨便用一個 MCU 做一個轉發器，把任意 232、485 接口的數據（也可以只轉發特定協議，e.g. modbus），轉換成 cdbus 格式。
我上面有提到 cdbus bridge 的功能之一就爲此。（另一個功能是 usb 轉 cdbus.）

如果是目標是使用 modbus，我一般的方案是，mcu 單獨接一路 ttl 串口到 485 芯片（和 cdctl 使用同一個 485 芯片），把 cdctl 不貼，或者一直讓它處於復位狀態，就可以用傳統的 ttl 轉 485 了。
或者，也可以外用一個 MCU 把 cdbus 再轉回爲 modbus。

yanyanyan168 · 发表于 2020-10-26 01:26:22

关注，不知道专用芯片出来了没有

dukelec · 发表于 2020-10-27 14:42:56

yanyanyan168 发表于 2020-10-26 01:26
关注，不知道专用芯片出来了没有

已經跟一家上市芯片公司合作，已經在進行當中，不僅會有獨立的控制器，還會有內置 cdbus 控制器的 MCU 同步推出，估計需要一年左右時間才能正式出來。

xxlin · 发表于 2020-11-18 15:41:57

关注，总线仲裁485

zhiyuanzhitian · 发表于 2021-7-3 19:20:21

MARK,支持仲裁的CDBUS协议

qtechzdh · 发表于 2021-9-5 00:52:26

楼主，有没有测试过 CDBUS在4-6Mbps下通信距离？我有个应用24个节点向集中器发送数据，总带宽4Mbps，距离大概30米。如果可以，我考虑用国产的高云小蜜蜂带M3的FPGA做个测试demo。

trigrass12 · 发表于 2021-9-5 12:03:58

can 现在有高速的，多字节的 fdcan

qtechzdh · 发表于 2021-9-5 14:17:11

trigrass12 发表于 2021-9-5 12:03
can 现在有高速的，多字节的 fdcan

小封装的带CANFD嗯MCU又不好找

dukelec · 发表于 2021-9-5 18:52:39

qtechzdh 发表于 2021-9-5 00:52
楼主，有没有测试过 CDBUS在4-6Mbps下通信距离？我有个应用24个节点向集中器发送数据，总带宽4Mbps，距离大 ...

因爲速度和距離取絕於接口芯片，和控制器無關，所以我沒做太多測試，你要自己試試，先試傳統通訊，可以的話就可以，然後再移植 fpga

我前兩周測試我的動力傘，故意找了一根稍微長一點的線，單芯 0.15 mm² 的線，接口芯片 sn65hvd75
剛量了一下，共 9 米，速率是 1Mbps 仲裁、10Mbps 通訊，沒終端電阻，pc 端主機 330R 上下拉，電機從機 4.7k 上下拉

我這是兩機通訊，你節點比較多，要注意中間抽頭儘量短，建議兩端都 330R 上下拉（其餘不加上下拉），先不接終端電阻，接口芯片和線材也選好點，估計問題不大

dukelec · 发表于 2021-9-5 18:53:57

qtechzdh 发表于 2021-9-5 14:17
小封装的带CANFD嗯MCU又不好找

其實 stm32g0 系列，qfn32 小封裝的都帶 canfd

dukelec · 发表于 2021-9-5 18:59:17

本帖最后由 dukelec 于 2021-9-5 19:19 编辑

trigrass12 发表于 2021-9-5 12:03
can 现在有高速的，多字节的 fdcan

canfd 實踐最高好像是 8 Mbps，cdbus 可以超過 50 Mbps，canfd 64 字節，cdbus 253 字節，爲了日後可以覆蓋更多場景而不改方案，還是選 cdbus 比較一勞永逸
（譬如傳輸 printf 調試打印，一行打印用一個包傳輸，253 字節足夠，64 字節就要拆包，很麻煩）

用 cdbus 格式，rs485、uart 串口、usb cdc 串口、rs232 接口、藍牙 ble 通訊等，都可以統一協議

canfd 字節數有階梯限制，不超過最大字節數的前提下，不能想用多少用多少，用 canfd 還要考慮上層協議是否要兼容 can2.0，歷史包袱重

can / canfd 不是推挽輸出，不適合遠距離傳輸

alding123 · 发表于 2021-9-14 10:54:12

CDBUS实际现场做工程，稳定性搞死你！

dukelec · 发表于 2021-9-14 11:10:59

alding123 发表于 2021-9-14 10:54
CDBUS实际现场做工程，稳定性搞死你！

CDBUS 是標準 485，至少 BS 模式完完全全是標準 485，不知道你在擔心什麼

LM5017 · 发表于 2021-9-14 11:33:31

NXP家的通用CAN收发器共模电压都已经做到-58V~+58V了，正常时候价格也才2块钱人民币。

485的共模电压是硬伤，一直是-7~+12V，应用于大功率电机场合的时候，随便一个主线大电流就罢工了。

LM5017 · 发表于 2021-9-14 11:52:36

不懂楼主从哪里得出的结论说can在走下坡路，
可能是开源工作者热衷于arduino、树莓派之类的东西才得出的结论？

我反而觉得近年用CAN的群体用来越大，在STM32之前，或者说是CM3之前，
单片机还是51、AVR、MSP430、PIC等8位机或者16位机时代，
单片机上基本上没有集成CAN控制器，那个时候CAN的确没有在民间普通应用推广开。

但STM32的长达10多年的霸榜之后，几乎每个STM32开发板都会带CAN收发器，
目前CAN的普及度可以说是非常好了，而且也没有楼主说的所谓“不易用”

dukelec · 发表于 2021-9-14 12:10:15

LM5017 发表于 2021-9-14 11:33
NXP家的通用CAN收发器共模电压都已经做到-58V~+58V了，正常时候价格也才2块钱人民币。

485的共模电压是硬 ...

同一家大廠，這個共模 can 可以做到，485 如果有需求肯定也可以做到啊，查了下，Ti 的 can 和 485 最大共模电压都是 -70V ~ 70V：

https://www.ti.com/interface/rs- ... html#sort=p1550;asc

CAN 的死穴：不是推挽輸出，不適合遠距離傳輸，
這也是爲何車用 can 比較多，485 工業用的比較多的原因之一，車的距離再怎麼也長不到哪去

CAN 比串口通訊複雜 N 倍也是衆所周知的，不用爭辯

CAN 的下坡是指：主要是高階應用被 EtherCAT 等工業互聯網取代，然後低端又有 UART 485 盤踞，所以 CAN 的市場份額長期看不會太好

STM32 雖然現在讓 CAN 再火了一把，也不代表永遠火下去，反觀串口，因爲太基礎，幾乎永遠不會被淘汰

LM5017 · 发表于 2021-9-14 12:23:32

dukelec 发表于 2021-9-14 12:10
同一家大廠，這個共模 can 可以做到，485 如果有需求肯定也可以做到啊，查了下，Ti 的 can 和 485 最大共 ...

你列举的ti的那些，基本都不是目前常用的。
本贴甚至本论坛列举的485收发器，每个数据手册都翻过去，基本都是-7V ~ +12V
ti的那些，虽然可以在国内的芯片售卖网站可以查到库存，但价格都保持了ti冷门芯片一贯的不友好，基本在6-20元单片，
而烂大街的485收发器通常价格在5毛钱-2块钱，基本不属于一个东西了。

楼主可能不知道的是，国内USBCAN调试器的通常价格，也从10年前的几千块大几百，降到了现在的一两百块钱，更加促进了CAN的推广。

另外，实际上，在初学者的程序应用里面，解析CAN报文的难度要远低于通用串口，可靠性也远高于通用串口。

alding123 · 发表于 2021-9-14 12:45:25

RS485自由度太高，产品卖不出价，楼主提的耐压高的不好买而且贵。。。。。。楼主估计是大公司干多了，小公司工程师和农民工一个性质

dukelec · 发表于 2021-9-14 12:45:39

本帖最后由 dukelec 于 2021-9-14 13:03 编辑

LM5017 发表于 2021-9-14 12:23
你列举的ti的那些，基本都不是目前常用的。
本贴甚至本论坛列举的485收发器，每个数据手册都翻过去，基本 ...

大型伺服場合用的更多的是隔離通訊方案，而不是靠提升共模範圍，你提的是小衆的，自然就貴一點咯

> 降到了现在的一两百块钱
調試軟件也不怎麼通用，大多還要用盜版軟件，對 canfd 支持也不好
而且除了調試，更麻煩是二次開發，你寫一個 pc 軟件給客戶，是否要去兼容市面所有 usb 轉 can 工具以及不同固件？

你不信可以調研一下，你做一個板子，對外只有 canfd 接口，你看一下廣大用戶，有幾個可以很順手的用起來
（8 字節、1Mbps 最多的 can 2.0 不用提了，太受限，根本不在我的考慮範圍，cdbus 最高 >= 253 字節，>= 50 Mbps）

用 uart、485，隨便搞一個串口助手就可以控制，難度肯定比 can 小

關於協議可靠性，我這個 cdbus 不就是爲了增強 485，提升可靠性之類的嗎

LM5017 · 发表于 2021-9-14 17:37:16

dukelec 发表于 2021-9-14 12:45
大型伺服場合用的更多的是隔離通訊方案，而不是靠提升共模範圍，你提的是小衆的，自然就貴一點咯

> 降到 ...

你拿CAN总线用来传图像传大型数据包，受限于每个报文只有64bit，它当然没有串口有优势，

但传图像，传大型数据包，有更好的选择，比如网线，wifi，或者自定义协议的高速串口

但除了传图像传大型数据量外呢？尤其是简短命令控制和短数据回传上

CAN是具有无可比拟的优势，不需要考虑协议兼容性，接入时只要id冲突避开就可以了，

还有它自带的硬件过滤器，从硬件上就避开了其它数据包带来的CPU的中断，全程不需要软件干预。

dukelec · 发表于 2021-9-14 18:31:32

本帖最后由 dukelec 于 2021-9-14 19:25 编辑

LM5017 发表于 2021-9-14 17:37
你拿CAN总线用来传图像传大型数据包，受限于每个报文只有64bit，它当然没有串口有优势，

但传图像，传大 ...

> 简短命令控制和短数据回传上

有些場合，雖然數據短，但是追求控制頻率高，譬如 EtherCAT 廣告詞就說了能在多短時間內同步多少軸的數據

用 uart / 485 / cdbus，高速、低速、小數據包、大數據包通吃不更爽嗎？
而且走不同物理層，協議也可以統一，譬如不需要上 485 的時候，我對外用 uart 口，協議不變，
甚至我做的一款 BLE 藍牙產品也是用同一套協議（cdnet）

帶 can 的產品往往還要留 485 / uart（或者搞兩個版本給用戶選擇）, 然後至少維護兩套協議
用 cdbus，一個產品一般只留一個接口就夠用，連調試口都省掉了，因爲既可以通訊，也可以調試，參見 CDBUS_GUI 工具
（當然，用 can 有些時候是客戶指定，接入現有 can 系統，如果哪天 cdbus 可以發揚廣大，用的人更多，那需要照顧 can 的場合自然就少了）

can 的 id 字段通常會用來做協議的一部分，不同協議對 id 字段的定義不同，其實很容易衝突
反而是 cdbus 只要設備地址不同就不會衝突，哪怕是 cdbus、modbus 等不同協議混用，基本的通訊也能正常

cdbus 控制器也有硬件過濾器，支持單播、組播、廣播，更接近主流且成功的以太網
（其實 stm32 內置的 uart 也有硬件過濾器）

> 但传图像，传大型数据包，有更好的选择，比如网线，wifi，或者自定义协议的高速串口

某些傳圖像的場合，還真沒比 cdbus 更合適的選擇了，譬如 CD-PnP 貼片機，日後會有 2 個或更多個攝像頭，
但是同一時間只有一個攝像頭需要工作，也就是說可以共享帶寬，哪怕接 40、50 個攝像頭，帶寬都夠，
如果用 usb、ethernet，需要接很多線、需要 hub，走線會很麻煩，用 wifi 配置麻煩、實時性也沒保障

工業領域，邊緣計算越來越火，機器視覺算法很多都可以在攝像頭端運行，攝像頭直接輸出識別結果就好，
這種場合，不需要傳輸高分辨率的視頻流，用 cdbus 總線傳輸多路、稍微低一點分辨率的預覽畫面，會是一個非常好的方案

solojimes · 发表于 2021-11-5 14:09:59

想请教下楼主还在推进这个吗爬了所有的楼发现资料比较多，有从0开始入门的吗，目前手上有个项目应该可以用得上，目前初步打算用modbustcp，can比较复杂，也想攻克，但是觉得楼主的这个好像更加适合。

楼主一个人做了这么多年，非常钦佩。

yangpeng012 · 发表于 2022-2-22 17:15:14

dukelec 发表于 2018-6-10 00:01
首先是用画矢量图的开源工具 Inkscape 画好每一帧，每一帧只要 copy 上一帧然后加以修改就可以，最后用一 ...
(引用自34楼)

学习了！

Alex_HBL · 发表于 2022-3-1 14:03:34

看了楼主的网店上面的实物照片了，觉得真心不错。顺便请教下楼主，不知道用STM32F4测试过，通讯速率能否上5Mbps？

momo_li · 发表于 2022-3-1 14:15:41

感觉本质就是用fpga魔改了一个可以超长帧的CAN总线. 然而现在CAD_FD出来了.
倒是可以更进一步,将最大包改到65535, 如果可以, 就提高到10M以上, 将以太网变压器的那一套接口用上
这样就可以和以太网竞争了, 毕竟添加以太网接口的成本不低.
向下, 可以利用以太网变压器低成本的隔离优势,和隔离的485 CAN竞争, 大型数据包的优势和CAN fd竞争, 仲裁和自动双工的优势和485竞争,
向上, 手拉手级联, 省掉以太网每个节点都需要的集线器芯片, 基于串口省掉以太网专门的PHY和MAC控制器, 少资源降低MCU的成本.
总体的成本和性能都是一个不错的选择, 如果再能支持光接口, 那就更好了

sddzycnq · 发表于 2022-11-1 23:18:32

请问楼主，ASIC是不是快出来了？

sddzycnq · 发表于 2022-11-5 23:58:39

dukelec 发表于 2018-6-6 12:00
是的，如果你的产品本来就有用 FPGA, 那么直接用开源免费的 IP 核就好。
如果是 MCU 用，需要实现仲裁的 ...
(引用自17楼)

是的，如果你的产品本来就有用 FPGA, 那么直接用开源免费的 IP 核就好。

楼主，你说的IP核心，是你github上的cdbus_ip吗？
直接可以用在FPGA为主芯片的项目中吗？

chendaon · 发表于 2022-11-6 07:20:17

momo_li 发表于 2022-3-1 14:15
感觉本质就是用fpga魔改了一个可以超长帧的CAN总线. 然而现在CAD_FD出来了.
倒是可以更进一步,将最大包改到 ...
(引用自187楼)

现场总线，如果支持500米距离，64个对象，100kbps速率，已经竞争力爆表了。

dukelec · 发表于 2022-11-7 11:26:48

sddzycnq 发表于 2022-11-5 23:58
楼主，你说的IP核心，是你github上的cdbus_ip吗？
直接可以用在FPGA为主芯片的项目中吗？ ...
(引用自189楼)

是的，可以

芯片后端基本上做完了，正在准备安排晶圆付款

wxws · 发表于 2022-11-7 14:36:00

可以用rp2040跑跑试试

蓝蓝的恋 · 发表于 2022-11-7 15:55:30

这个要出来一个类似RS485的专用芯片？

sddzycnq · 发表于 2022-11-10 10:09:52

dukelec 发表于 2022-11-7 11:26
是的，可以

芯片后端基本上做完了，正在准备安排晶圆付款
(引用自191楼)

谢谢，有个方案（MCU+CDCTL与fpga一主多从通信）。后面试试你们的CDCTL。

Xujuango · 发表于 2022-11-10 10:51:57

chendaon 发表于 2022-11-6 07:20
现场总线，如果支持500米距离，64个对象，100kbps速率，已经竞争力爆表了。 ...
(引用自190楼)

有这样的方案？

sddzycnq · 发表于 2022-11-25 15:10:48

qtechzdh 发表于 2021-9-5 00:52
楼主，有没有测试过 CDBUS在4-6Mbps下通信距离？我有个应用24个节点向集中器发送数据，总带宽4Mbps，距离大 ...
(引用自168楼)

请问，你有在高云的FPGA上测试吗？需要消耗多少逻辑资源？

16312610 · 发表于 2023-11-6 15:20:35

煤矿应用尾端应用非常好，数字电话，手接手通信，对讲广播。

dukelec · 发表于 2023-11-6 16:31:04

蓝蓝的恋发表于 2022-11-7 15:55
这个要出来一个类似RS485的专用芯片？
(引用自193楼)

是的，已经出来了：
贴片机用的通讯模块将升级成 ASIC 芯片 CDCTL01A
https://www.amobbs.com/thread-5782436-1-1.html

大家觉得 CDBUS 这个带仲裁的 RS485 怎么样？跟 CAN 比呢？

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源