动手做一个自组网的网络 - 硬件开发板

因为卡农

已于 2023-04-06 17:42:53 修改

阅读量1k

点赞数

分类专栏：自组网文章标签： mesh 网络协议嵌入式硬件

于 2022-12-08 19:00:00 首次发布

本文链接：https://blog.csdn.net/cuzcanon/article/details/128235686

版权

4 篇文章 1 订阅

订阅专栏

一开始使用的是NRF24L01，然后用替代版本SI24R1，因为这颗芯片比前者的发射功率和通信速率更高，用来做组网只能舍弃内部的自动收发状态机，所有节点都使用相同的地址，他有三个32 Bytes的FIFO，当时协议栈的头部占用比较多，除去协议栈的损耗好像只剩下16个字节了，后来协议栈占用精简到8个字节才有所改善。
后来发现了TI系列的收发器，有CC1101和CC2500两种，CC1101频率在387 ~ 928Mhz在之间，CC2500是2.4G的收发器，频率在2400 ~ 2483.5Mhz之间，两者速率最大只有500Kbps，64字节FIFO，带CCA和8位的RSSI，能实现更多有意思的功能。CC1101因为是低频段，所以穿墙能力会更强，这在以智能家居为应用的项目上很有吸引力，可以少一级中继，后来还是选了CC2500，主要考虑几个方面
2.4G天线长度大约在17 ~ 31mm之间，915Mhz天线长度大约在45 ~ 82mm之间，即使螺旋缩小体积区别也会比较明显，这对设计一个小型的外壳来讲尤为重要，二是高频在通信中应该会更省能量(不清楚是否正确)，有利于低功耗的进一步优化。
后续有时间了再考虑市面上的更高数据速率的2.4G收发器

之前用STM32F411做过产品，这个熟悉，可以减少学习成本，具体型号在STM32L051K8和STM32L432KC之间做了权衡
价格的话432比411贵一些，芯片荒的当下谁也不要预测谁比谁贵，先用起来再说，毕竟代码和芯片平台没有依赖。
仅仅运行协议栈的话，STM32L051完全够用，操作系统勉强能跑起来，但是额外实现OTA和运行lua脚本就心有余而力不足了，最后选了STM32L432KC，这个片子还是主打低功耗的，256KFLASH + 64KRAM完全没压力，在设计时将所有GPIO都利用了起来，LQFN32的体积也比较友好。

调试用的是中景园的1.3寸LCD，驱动芯片ST7789使用SPI就可以驱动比较省引脚，唯一遗憾就是他家的小屏幕都没有触摸屏（20220304），为了缩小体积使用了可以插拔的1.14寸LCD，只需要占用一个8P的FPC座子就可以。

打样次数	实现功能	改进优化	改版原因
1	全部，带`G-sensor`	`TYPE-C` 延长PIN脚焊盘	改进优化
2	全部，无`G-sensor`	`FPC` 座子延长PIN脚焊盘	改进优化
3	全部，现版	不同时使用`PA0`&`PB0`，不利于中断触发电池座不耐高温，不能使用风枪加热充电芯片由`TP4054`更换为`BQ21040`,带外部NTC	暂不考虑

硬件上，比如丝印位置不美观、PCB外框和屏幕外框不协调，封装未验证（可能和低温锡有关）
板载LCD和CC2500使用AO3401(PMOS)来控制电源，CC2500的有些引脚在切断电源后会从MCU的GPIO上取电(现象就是CC2500断电后电压依旧在2.4V左右)，一度以为我的MOS设计失败，查找了很久才发现问题。
CC2500的CCA不是很好调试，实际速率最快也就3 ~ 5 KiB 每秒（带双向确认的协议收发）。
简单跑了一下协议，六级多跳转发，每秒大约10~20个数据帧（单跳大约100个数据帧。一帧40字节，四次收发完成一个帧传递)，很难跑满带宽，除非有更合适的算法支持，或者针对硬件做专门优化 (不想过度依赖硬件，或者说不依赖硬件能否做到更高效的利用带宽)，这个问题大约无解。
多个设备聚集在一起会增加碰撞概率，导致CRC错误暴涨20% ~ 60% 。