目录
前言
我不知道会用多长时间读完这篇,我知道的是将一些设计时的考虑想法落实到文字上是多么费时多么费精力的一件事
蓝字我觉得是最概括性的,红字是我认为最重要的,绿字是我写完这篇之后自己不能解答的,希望阅读者能在评论区留下宝贵意见,
同时关于程序上有什么不当的地方,也希望阅读者能在评论区留下宝贵意见--------渴望能得到提升的拳拳小布
为什么要写这篇
先从要实现什么功能说起吧,要实现十五分钟未收到蓝牙报文则关机(为了省电),按照我的想法,应该十五分钟内就能写完该函数,然后5分钟来烧录验证(验证时设置为一分钟未收到蓝牙报文则关机)。但实际用时比这多不少,我感觉自己还是太嫩了,因此有必要记录一下。同时工程师的自我修养就该写出明显没有bug的代码,既是对自己代码的一种审视和公开挑错,也是一种记录和积累。
设计考虑因素
考虑收到蓝牙报文
接收报文分为两种情况,BLE接收回调 和 mesh接收回调,是单指BLE接收报文,还是BLE接收和mesh接收报文 呢?针对最终产品的功能会是通过BLE连接到一个mesh节点控制灯板动作,同时该mesh节点也会通过mesh发送到另一个mesh节点,实现两块灯板同时动作。那么就清楚需求是针对两种接收回调了,因为不可能是其中BLE连接的mesh节点关机了,另外一个没有关机。因此是指BLE接收和mesh接收两种报文接收方式,那就对两个接收回调的公共部分(报文解析函数)做处理,因为接收到报文后都需要做处理
考虑判断 接收/未接收
其实这问题已经解决了,当接收到蓝牙报文就会执行报文解析函数,反过来也是成立的,若没接收到蓝牙报文就不会执行报文解析函数。
考虑定时的实现方式
十五分钟未接收到,那就是超出 规定的时间。关于实现方式:首先排除延时实现,因为会阻塞其它功能执行,比如蓝牙协议栈,后果会很严重。定时器实现,或者软件定时器实现,或者查询系统时钟计时(滴答计数)。软件定时器和查询系统时钟计时本质上是一样的,都是通过一个精准的定时基准,然后计数,主循环中查询定时是否溢出,然后执行相应程序。我了解的硬件定时器只是用于单一功能的定时,之前写的不多的程序也没遇到过资源很受限的情况,其它功能很可能是放在while死循环里了。有对硬件定时器有深入使用的,望在评论区留言赐教。 该芯片有三个定时器,timer2可以被配置为看门狗模式,不能占用,timer0 和 timer1倒是可以用,但是上级告诉我使用定时器可能会导致些问题,没有说明会导致什么问题自己也不清楚那岂不是定时器从此都不能用,总要用的,自己知道有坑,知道坑在哪儿才是我该做的,之后才能慎用定时器,后来发现导致mesh发送和接收有问题