蓝牙mesh组网实践（①mesh组网的评估与沁恒蓝牙芯片选型）

在选型之前先要初步评估一下项目是否需要用到BLE mesh。

沁恒的组网方式主要有2.4G私有协议组网和BLE mesh组网两大类。2.4G私有协议组网灵活性相对较高，对开发者的要求也相对较高。mesh组网本身有一系列规范，考虑到了可靠性、安全性、功能性等等方面，分了网络层、上下传输层、接入层、模型层，层层封装，各司其职，但同时也是一种限制，发包速率远不如2.4G私有协议组网。就好比吃面，懂厨艺的可以买面粉做拉面、炒面、手擀面，没那手艺的做出来的面还不如方便面的，也可以就吃方便面，至少稳定、实惠又安全，加点蔬菜肉类也能照顾到营养。想做密钥验证、转发中继、降低功耗等等功能吗，mesh协议栈里有规定好的的，用2.4G私有协议需要自己写。

评估是否使用mesh组网，主要有两个局限，一个是发包频率/实时性问题，另一个是低功耗节点的支持问题。

发包频率/实时性：mesh底层发包需要重传，默认重传7次，每次间隔10ms，这样就占用了70ms，加上数据解析等等过程，传输一则消息大概需要开销100+ms，故建议整个mesh网络中，1s内最多产生10则消息。如果1s内产生超过10则消息，很容易丢包，需要调整应用层重传次数、重传间隔、随机时长等等来确保接收方能收到消息。发包频率固然也影响到了实时性，但是对于低功耗节点来说，发消息没有影响，与一般节点一致，往外发就行了，有常供电节点进行接收和转发；接收消息的实时性需要关注一下，其主要取决于多久向朋友节点POLL一次数据，设置为10sPOLL一次，那发送方就只能期待10s内收到低功耗节点的回复。想要1s内就收到低功耗节点的回复，那么至少需要将低功耗节点POLL消息的频率设置为1s，且需要与接收方在广播范围内直连（转发一次消息也需要开销100+ms），代价就是功耗要更高、分布距离要更近。而在2.4G私有协议组网中，做好收发切换，可以达到5ms传输一包，实时性和丢包率可以自行平衡，转发功能也需要自己做。

低功耗节点的支持：消息的接收方是不知道消息什么时候过来的，而一直开着接收扫描等待，功耗会很高，故mesh协议将“接收”的功能分配到了朋友节点上，由低功耗节点轮询朋友节点，查看有没有低功耗节点的消息。发送消息发完就休眠，故不太影响功耗。低功耗节点本身是可以电池供电的，但是其朋友节点仍需要常供电以维持接受扫描。

适合mesh的典型场景是楼宇内的灯控，其有市电供电、节点密度高等特点。mesh灯控可以提供良好的转发中继和朋友功能的支持，在楼宇内加装一般节点和低功耗节点比如说加装智能家居类的设备——智能插座、智能窗帘等，加装低功耗设备——温湿度传感器、烟雾传感器等，都可以走灯控网络来通信。

沁恒的RISC-V BLE芯片主要有CH573/571，CH583/582，CH32V208这几款。mesh协议栈是纯软件的，故这几款芯片走mesh都能互通。

571的局限在于codeflash为192K，ram为18K。BLE库+mesh库需要占用大概200K的codeflash，故不支持在跑mesh的同时走BLE连接手机。

573的codeflash为448K，足够存放BLE库和mesh库。带BLE功能的节点代码编译后，占用ram大小为16K+，勉强能跑。加上用户层代码的ram开销，若占用ram总量的95%及以上会影响到使用，故用户层做的功能也不能太多。对于OTA升级功能，ram的利用率相对较低，需要挖掉8Kram以供BLE固定库使用，留给mesh的ram就只剩10K。然而只提供mesh透传模型的一般节点，默认代码编译之后需要占用14K+的ram，故不支持OTA。

583相较于582，优势在于低电压供电，其他功能是一致的。582的codeflash为448K，ram为32K，可以支持OTA功能（参考最新EVT中的手机配网例程），是沁恒的蓝牙mesh方面主推的mcu。若用作自配网的一般节点，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，库可以后置，也能实现mesh和BLE从机功能同时运行，能够支持OTA。208的ram大小为64K，按照571和582的ram来估算，用作配网器最多能够支持500个节点，用作朋友节点也能支持更多低功耗节点。