CANFD转WIFI

admindxfds

目前市场上CANFD转WIFI都非常昂贵，动辄千元以上的价格，使大学生、初学者望而却步，为此我们使用GD32E(C)103芯片和ESP8684模组开发了世界上最具性价比的CANFD转WIFI模块，其性能不输千元产品，不足百元的价格为大学生、初学者开启了学习体验之门。模块中的CANFD功能由GD32E(C)103单片机完成，WIFI功能由ESP8684模组完成。单片机与模组之间采用SPI对接。模块WIFI工作于AP_server模式使用TCP通讯协议IPv4，CANFD最高速率为6M，模块支持手机、平板、专用手持设备、笔记本等终端设备的接入，支持多种操作系统 WIN UNIX LINUX 安卓和鸿蒙等，用户可以使用普通串口或网络调试助手进行调试，也可以使用MYCANFD上位机工具进行调试。为了最大限度的降低大学生、初学者学习成本，模块将CANFD转WIFI、转USB、转TTL 三种功能三体合一，可满足初学者多种应用场景。

在这里特为DG32和ESP32两颗中国芯点赞！！！

CANFD转WIFI主板(GD32)固件、使用说明书和上位机下载见“消费类模块总汇”，这里仅提供ESP32固件。

admindxfds

在这里需要特别提醒初学开发者的是不要迷信厂家提供的库函数，对于您需要使用的每一个关键库函数，都要认真的阅读了解。因为厂家提供的库函数可能也会出现一些错误，甚至是低价错误！我们在开发CANFD功能的时候，就发现GD32提供的库函数有两处低级致命的错误，现已经提供给GD32厂家进行了修正。具体内容大家可以到GD32论坛上去查找。对于ESP32其ESP-IDF开发环境中其non-blocking socket example样例代码中的socket_send()函数亦有致命的低级错误。该函数错误从其最初版本一直延续到其最新版本2024年底的V5.4.0中都有体现，现将该函数截图展现给初学者，请大家斟酌。

admindxfds

下面是CANFD转WIFI之II型的相关内容，

II型是提供给有特殊要求的用户DIY使用的。对于普通用户使用上面I型是基本够用的。我们的产品大多都提供了硬件、PCB图和程序固件，方便用户非商业性DIY。II型和I型的GD32单片机主控是一样的，不同的是ESP32选用了C3 pro mini开发板，C3较8684有更高的运行速度和更大的内存和flash运行空间。C3 pro mini开发板较8684模组更适合用户DIY焊接组装。（当有持续大量的wifi发送时，建议加装散热片）我们将为II型用户提供 “多TCP接入”  “SAT-AP模式”  “超低延时响应” “UDP”等多种应用场景。敬请期待！！！

admindxfds

TCP多客户端接入需求
我们知道TCP是支持多客户端的接入的，与UDP不同的是，TCP每多接入一个客户端其WIFI收发流量、内存使用空间和所耗机时都要加倍。在大多数的应用环境中用户通常都是单接入的，用I型即可满足用户需求。但也会有一些用户有多接入的应用场景。为此我们在II型中给用户提供了可接入两个TCP客户端的应用，满足5M CANFD满载时不丢帧的性能指标（wifi良好不受干扰和客户端接收能力优异的条件下），当用户接入3个或3个以上TCP客户端时，需要适度降低CANFD的信息密度，才能保证不丢帧。目前II型的wifi发送持续总量不应超过10Mbps。除了支持多接入，其它与I型基本相同。有需求的用户可以下载下面固件烧录到ESP32C3 pro mini开发板中，测试验证。

admindxfds

STA or AP模式 (华丽转身)

通常我们使用AP模式，都是在近场应用中，将现场CAN总线信息通过WIFI传递到笔记本客户端软件中，进行监控和调试。而STA模式则可以让我们通过WIFI路由器，实现对CAN总线信息的远场监控和调试，从而拥抱物联网世界。我们在上面AP模式的基础上，进行了升级，实现了STA模式的接入。具体是，当模块上电后，会自动搜索附近有没有名为 ttcanopen_ap(密码：ttcanopen) 的WIFI路由器存在，如果有，则接入该路由器，然后等待连接在同一路由器上的有线或无线的客户端设备接入，模块作为服务器的相关信息参看《CANFD转WIFI使用说明书》；

如果附近没有名为 ttcanopen_ap(密码：ttcanopen) 的WIFI路由器存在3秒钟之后，模块会自动进入AP模式。

下面是升级后的ESP32C3 pro mini的烧录固件。

admindxfds

超低延时模式

我们知道大多数TCP通讯，默认都是开启Nagle算法的，该算法会将小包数据收集聚合成一个大数据包进行发送。这样就极大的提高了通讯效率，避免网络堵塞。举例讲，从CAN总线上转换传递过来的小包可能只有十几个字节，TCP通讯却要为其套装上一个40个字节的包头信息方能通讯。Nagle算法会将几十上百的小包合并成一个1.4k左右的大包并套接一个40个字节的包头信息进行通讯，显而易见，Nagle算法在WI-FI TCP通讯中的作用是至关重要的。然而，事物总是具有两面性的，Nagle算法在提高TCP通讯效率的同时，却牺牲了通讯的实时性。而在我们的一些应用环境中，对通讯的实时性要求比较高，这样我们就不能启用Nagle算法，在TCP通讯中有一个NODELAY选项，用于屏蔽Nagle算法，以提高通讯的实时性，在选择NODELAY选项后，用户一定要适当降低信息的通讯密度。在一个普通TCP通讯案例中，选择NODELAY选项后，其平均延时由40ms降低到10ms左右，而其通讯平均速率也由4Mbps降低到只有1Mbps左右。鱼与熊掌不可兼得。


在我们的模块上，将esp32c3开发板中的IO_0管腿接地，设备上电后，模块运行会使用NODELAY选项，屏蔽Nagle算法。

admindxfds

UDP模式
与TCP不同。。。。敬请期待。。。
。。。。。。。。。。。。。。。。。。
经历了漫长的等待，CANFD转WIFI之UDP终于完成了测试。
展开论述前，先说结论：我们认为 UDP协议不适用CANFD转WIFI。
如有其他备选方案，尽量不要采用！！！


UDP是一个简单高效的通讯协议，一般分为点对点通信方式和组播（或广播）通讯方式，没有TCP的握手重传机制，但其通讯效率在CANFD转WIFI应用中体现的并不明显，与不采用Nagle算法的TCP相当，在通常的WIFI通讯条件下UDP点对点实测会有0.01%至1%的丢包率，而TCP则可做到不丢数据。
使用UDP的用户大多是看中了其组播方式，但测试的结果可能会让大家失望了。我们的模块组播方式有两种，一种是在AP模式的组播方式，另一种是在STA模式下的组播方式。在AP模式下组播方式在通讯平均速率大于1Mbps时会出现队列复制内存匮乏的错误，在STA模式下，该问题会转移到路由器端，通常情况下，路由器本身也有对组播包使用带宽的限制，就我们自在的测试结论UDP组播被限制在1Mbps左右，不能满足目前我们CANFD 6M的使用要求。另外一个问题就是，在组播方式下，由于缺少了MAC层确认机制的加持，其丢包率大幅提升，通常在0.5%至5%之间，几乎无法使用。

admindxfds

CANFD 转 nRF24L01+ 2.4G无线通讯模块
在低成本短距离无线通信领域，除了各种wifi模块外，有一个2.4G nRF24L01+无线通讯模块是不容忽视的。尤其是在低信息密度的应用场景中，有着庞大的用户群体。为此我们准备为用户开发一个几近魔幻般的转换模块，它将CANFD转2.4G无线、CANFD转USB、CANFD转TTL串口、USB转2.4G无线、TTL串口转2.4G无线、五种功能模块集为一体，以最大限度的适配用户的应用场景。

敬请期待。。。。。。


我们知道2.4G nRF2401L+ 是一个半双工无线通信模块，主要应用于“主从应答”应用系统中，而我们需要的却是一个“点对点随机通信”应用系统，因此我们需要完美的解决三个主要难题：1）两端设备同时发送数据产生对撞问题；2）两端设备同时有大量数据进行对传时，合理有序高效完成“收”“发”状态循环切换；3）需要制定一个类似TCP的可靠通信协议，完成握手和数据重传，确保传输信息的完整性。

如何完美的解决这三个主要问题，我们拭目以待。。。。。。

经历三个月的开发研制，目前进入到测试验证阶段。现在简单的汇报一下，初步的测试结果，前面提出的三个难题逐一的进行了攻克。

我们知道nRF2401L+空中通信位速率分为三挡，分别是2Mbps、1Mbps和250kbps，但其实际有效信息的通信速率却是远低于位速率的，这是因为每一帧的通信流里不仅有我们需要传输的有效字节流，另外还携带有地址字节、校验字节和流控字节等，为了可靠，我们选用了应答方式，应答帧同样注入有流控字节等信息，因此实测有效信息的通信速率只有其位速率的1/5到1/3。直接对应三种位速率测试结果是45KB/s、32KB/s和12KB/s。考虑到协议开销，上述指标基本达到其“点对点随机通信”的最高水准。