281|0

4796

帖子

0

资源

纯净的硅(中级)

TI CC2640R2F献给初学者的文档

     程序是什么?程序就是个流程,很多人对着协议栈,不知道从哪下手,然后哪里出了问题也不知道怎么改,提出问题,别人说原理,又觉得自己用不上,实际上,原理就是流程,顺着原理去读程序,就很顺畅。
先解释几个基本点:
一、低功耗的思路。这个概念,很多人不懂,先解释这个,懂了这个,BLE很多事情就清晰很多。
人的低功耗,就是躺着比走路省卡路里,走路比跑步省卡路里。这个很容易懂吧?
然后切换到芯片,芯片的功耗,由晶振决定,晶振的频率决定了单位时间里的功耗。
晶振,就是给处理器提供时序信号的,RISC指令集,一个时序触发一条指令,于是可以得出,晶振的频率,与功耗成正比,跟处理速度也成正比。
回看CC2640R2F,有2个晶振,1是32768HZ,2是24MHZ,在芯片中倍频成48MHz的晶振。现在来分析3个情况:
1、2个晶振都不工作,那么功耗非常低,程序处于停止状态,不会跑。
2、32768Hz晶振工作,48MHz不工作。功耗就比较低,但是处理速度很慢,一般仅用于定时。
3、24MHz晶振工作,32768Hz晶振不工作。功耗很高,但是处理速度非常快。
由上面3个结论,我们延伸出这么一个思路,一般我们实际应用场景,都是很快处理完一段程序,然后大部分时间在等待。
比如,按键扫描,一次处理10来条指令去判断有无按键,然后等待10-40ms(一般的按键扫描间隔),再扫描一次。按照48MHz晶振,我们计算下,算20条指令,只需要花20/48000000秒的时间,就是0.416uS时间处理,然后等待的时间,我们按20ms计算,我们实际上只用了十万分之一的时间在工作,剩下的全部是在等待。这个效率是不是很低?其他的如ADC(就算1kHz的采样频率,大部分时间也是在等待),液晶显示(一般都24Hz-60Hz)等等,都是类似的。
那么,我们能不能,用32768Hz去定时,定时时间到了,启动48MHz的晶振去飞快的处理完,然后又切换到32768Hz去计时下一次任务时间的到来。如此一来,可以将功耗降下来很多。
所有MCU的低功耗设计,都是这么个思路,在CC2640R2F这里,32768Hz做定时,48MHz晶振全速处理,在这个工作状态下,TI称之为PM1或者PM2(PM1和PM2的区别是一些内部电压开不开启而已。)。上诉1的状态,称之为PM3,就是完全停止,只能靠外部中断去重新启动晶振(类似施密特触发器)。上诉3的状态,称之为PM0,就是全速工作状态。
这是基本的低功耗知识,不论你使用不使用CC2640R2F,对于所有其他MCU,思路是一样的。
二、延伸到BLE协议栈,BLE为什么省电?也是用这个思路。首先,射频电路的耗电,产生于电路振荡,这个自己搜索下,不细讲,发射和接收,都是需要开启电路振荡的,这个时候功耗很大,但是实际上我们没必要一直开着发射或者接收,是吧?我们可以参考地铁或高铁的模式,是不是更容易理解:
地铁是规定了几个站停靠(在地铁里,是空间上的间隔,在BLE里,是时间上的间隔。),只有到站了可以上下客,而且上下客的时间定死了(在BLE里也有这个窗口时间,双方只在这个窗口时间内进行数据交换,过时不候)。只要定好了这几个参数,地铁就可以很顺畅的运行了:到站点,定时上下客,两个站点中间路程全速运行,这样就大大提升了效率。
再反过来解释BLE,其实就是,定一个大的时间间隔,然后用一个很短时间的窗口,进行数据交换,就这样,在很小的时间窗口内,双方全速工作,把数据交互做完,然后在大的时间间隔内,双方都休息,达到了低功耗的效果。
这个大的时间间隔,就叫做连接间隔,做BLE的应该非常清楚这个参数。这个参数决定了你的功耗。这个时间间隔越大,功耗越低,能交互的数据越少;这个时间间隔越短,功耗就越高,能交与的数据就越多。
三、已经了解了BLE协议的基本工作情况,我们就要理清,我们的应用(APP)应该怎么配合BLE的协议栈(stack)。下面分析几个大家特别容易出问题的点。
1、CC2640R2F的协议栈,在GATT层里有个读写回调程序,如下图:
写回调

image.png
读回调

image.png
要千万记得,这两个程序,是运行在我们前面所说的窗口时间内的,所以这两个程序的主要内容,是把主机要读的内容传递出去,以及把主机要写的内容保存下来,最终再启动一个应用层的写回调(读回调没有,因为数据传递出去就行了;写回调,因为新的内容写进来,需要通过回调通知应用层)。很多人直接在这个子函数里写程序,直接导致BLE断线。这个情况就好像,我们坐火车一样,路过上饶,停靠5分钟,这个时候听到上饶鸡腿的叫卖, 你下火车买了个鸡腿,然后回火车上,火车开动了开吃,谁知道某人,买了鸡腿直接吃,吃完了才上火车,结果你吃鸡腿花了6分钟时间,火车开走了!这段程序的流程就类似这样,写了个数据进来,保存下来,通知应用层,然后完成余下的操作(收到了数据,要回一个回执给主机),本次数据交互结束。你在这里加程序,那等于是在上饶下火车吃鸡腿。
2,由于BLE的数据,只在连接间隔时间到的时候交互,所以,你写的处理程序,不能长时间的占用CPU,如果你占用CPU的时间大于了这个连接间隔,那你会大概率BLE掉线。那些写程序喜欢加delay很长时间的朋友,重新学习下编程思维,程序真不是这样写的。
3,CC2640R2F的重复进事件,会导致系统崩溃。这是什么意思呢?就是触发一个event,然后进入event,你的程序是先启动这个event的定时器,比如下个10ms继续触发这个event,然后在下面的程序中,你delay了10ms,就是说,你还在这个event的处理程序中,系统又触发这个这个event,这样形成嵌套,就会导致崩溃。这个碰到的人也比较多,要引起注意,最好是重新启动定时器的指令,放在这个事件子函数的最后位置。
不会弄一些动图,所以字多,估计能耐心开的人少。如果你看了,希望你有所得。

此帖出自无线连接论坛

回复
您需要登录后才可以回帖 登录 | 注册

关闭
站长推荐上一条 1/5 下一条

About Us 关于我们 客户服务 联系方式 器件索引 网站地图 最新更新 手机版

站点相关: 安防电子 汽车电子 手机便携 工业控制 家用电子 医疗电子 测试测量 网络通信 物联网

北京市海淀区知春路23号集成电路设计园量子银座1305 电话:(010)82350740 邮编:100191

电子工程世界版权所有 京ICP证060456号 京ICP备10001474号 电信业务审批[2006]字第258号函 京公海网安备110108001534 Copyright © 2005-2020 EEWORLD.com.cn, Inc. All rights reserved
快速回复 返回顶部 返回列表