原文链接：
https://www.cnblogs.com/JayWellsBlog/p/16814603.html
沁恒的组网方式主要有2.4G私有协议组网和BLE mesh组网两大类。2.4G私有协议组网灵活性相对较高，对开发者的要求也相对较高。mesh组网本身有一系列规范，考虑到了可靠性、安全性、功能性等等方面，分了网络层、上下传输层、接入层、模型层，层层封装，各司其职，但同时也是一种限制，发包速率远不如2.4G私有协议组网。就好比吃面，懂厨艺的可以买面粉做拉面、炒面、手擀面，没那手艺的做出来的面还不如方便面的，也可以就吃方便面，至少稳定、实惠又安全，加点蔬菜肉类也能照顾到营养。想做密钥验证、转发中继、降低功耗等等功能吗，mesh协议栈里有规定好的的，用2.4G私有协议需要自己写。
评估是否使用mesh组网，主要有两个局限，一个是发包频率/实时性问题，另一个是低功耗节点的支持问题。
发包频率/实时性：mesh底层发包需要重传，默认重传7次，每次间隔10ms，这样就占用近70ms，再加上数据加密等等过程，发送一则消息大概需要开销100ms，故一个节点往外发送消息的频率最高即为1s10则消息，这是协议限制。若只用2个节点在广播范围内进行应答测试，那100+ms后，发送方也能收到回包了，但在大范围使用中，消息的中继也是由节点转发消息，也是如上的发包流程，故建议整个mesh网络中，1s内最多产生10则消息。某1s内产生超过10则消息也不是不行，需要调整应用层重传次数、重传间隔、随机时长等等来确保接收方能收到消息，可以以时间换取丢包率，但实时性就无法保证。
如果要求每一秒都要产生超过10则消息，且这10则消息都需要跨越整个网络，那蓝牙mesh不太适用。发包频率固然也影响到了实时性，如果期望每秒内发更多的包，或传输延迟在100ms以内，建议用2.4G组网。在2.4G私有协议组网中，做好收发切换，不考虑收包方的话1ms发一包都行，发包频率、实时性和丢包率可以自行平衡，加密、转发等功能需要自己做。
针对低功耗节点，发消息与一般节点一致，工作状态下往外发就行了，有常供电节点进行接收和转发；接收消息的实时性则取决于低功耗节点多久向朋友节点POLL一次数据，若设置为10sPOLL一次，那发送方就只能期待10s内收到低功耗节点的回复。想要1s内就收到低功耗节点的回复，那么至少需要将低功耗节点POLL消息的频率设置为1s，且需要与接收方在广播范围内直连（转发一次消息也需要开销100+ms），代价就是功耗要更高、分布距离要更近。
低功耗节点的支持：消息的接收方是不知道消息什么时候过来的，而一直开着接收扫描等待，功耗会很高，故mesh协议将“接收”的功能分配到了朋友节点上，由低功耗节点轮询朋友节点，查看有没有低功耗节点的消息。发送消息发完就休眠，故不太影响功耗。低功耗节点本身是可以电池供电的，但是朋友节点仍需要常供电以维持接收扫描。这一点没办法规避，总有人需要付出“中继”的代价，没有供电让芯片启用中继转发或是朋友功能，就需要用到已经搭建好的通信平台。如果应用场景是在缺少供电的地方，有手机基站支持则建议用4G/5G通信模块，连手机基站都没有，那甚至需要用到卫星通信模块。
适合mesh的典型场景例如楼宇内的灯控，其有市电供电、节点密度高等特点。mesh灯控可以提供良好的转发中继和朋友功能的支持，在楼宇内加装一般节点和低功耗节点比如说加装智能家居类的设备——智能插座、智能窗帘等，加装低功耗设备——温湿度传感器、烟雾传感器等，都可以走灯控网络来通信。
沁恒的RISC-V BLE芯片主要有CH573/571，CH583/582，CH32V208这几款。mesh协议栈是纯软件的，这几款芯片走mesh都能互通，对于mesh的应用来说，差别只在falsh与ram的大小上。
571的局限在于codeflash为192K，ram为18K。BLE库+mesh库需要占用大概200K的codeflash，故不支持在跑mesh的同时走BLE连接手机。如果作为中心节点，最多支持100个节点。
573的codeflash为448K，足够存放BLE库和mesh库。带BLE功能的节点代码编译后，占用ram大小为16K+，作为一般节点是能跑的。编译时ram没有计算局部变量、动态申请的内存等空间，加上用户层代码的ram开销，若占用ram总量的95%以上很有可能会影响到使用，故用户层做的功能也不能太多。对于OTA升级功能，ram的利用率相对较低，需要挖掉4Kram以供BLE固定库使用，留给mesh的ram就只剩10K。然而只提供mesh透传模型，不带BLE的一般节点，默认代码编译之后都需要占用14K+的ram，故不支持OTA。对ram大小要求比较高的需求，包括朋友节点功能和管理网络的配网器，都不建议用571/573来进行。573的ram资源与571一致，如果作为中心节点，最多支持100个节点。
583相较于582，优势在于低电压供电，其他功能是一致的。582的codeflash为448K，ram为32K，可以支持OTA功能（参考最新EVT中的手机配网例程），是沁恒的蓝牙mesh方面主推的mcu。如果作为中心节点，最多支持200个节点。若用作自配网的一般节点，582这颗MCU是足以胜任的。如果涉及到用作朋友节点（FN），在最新EVT中，支持的低功耗节点（LPN）的个数上限由RAM的大小决定，每一个LPN会占用FN332字节的RAM以及CONFIG_MESH_UNSEG_LENGTH_DEF*CONFIG_MESH_LPN_REQ_QUEUE_SIZE_DEF字节的缓存（BLE_MEMHEAP_SIZE）。目前测试，能够实现支持10个LPN，每个LPN每隔2s向FNPOLL一次数据。
CH32V208这款芯片的flash标注为128K，是特指用户层APP占用的快速flash，库可以后置到320K的相对慢些的flash中，也能实现mesh和BLE从机功能同时运行，能够支持OTA。208的ram大小为64K，按照573和582的ram来估算，用作配网器能够支持500个节点，用作朋友节点也能支持更多低功耗节点。
注：最新EVT中582的支持OTA代码，是走BLE直连某个节点，可走mesh网络转发OTA升级数据到指定节点进行升级的，使用了固定库+备份用户代码（用户层代码中包含有实现mesh功能的代码，故需要备份以保持mesh通信，新代码校验完成后再把老代码擦除誊写）的方式升级，占用的codeflash比较多。仅走BLE升级就不支持mesh网络转发OTA升级数据的功能，适合用户代码占用codeflash很多的情况，使用固定库升级，在IAP中由BLE接收升级数据，不备份用户代码，这样就能够留出更多空间给用户层代码。
