程序是什么?程序便是个流程，许多人对着协议栈，不知道从哪下手，然后哪里出了问题也不知道怎样改，提出问题，他人说原理，又觉得自己用不上，实践上，原理便是流程，顺着原理去读程序，就很顺利。
先解说几个根本点：
一、低功耗的思路。这个概念，许多人不明白，先解说这个，懂了这个，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层里有个读写回调程序，如下图：
写回调
读回调
要千万记住，这两个程序，是运转在咱们前面所说的窗口时刻内的，所以这两个程序的主要内容，是把主机要读的内容传递出去，以及把主机要写的内容保存下来，终究再发动一个运用层的写回调（读回调没有，因为数据传递出去就行了；写回调，因为新的内容写进来，需求经过回调告诉运用层）。许多人直接在这个子函数里写程序，直接导致BLE断线。这个状况就好像，咱们坐火车相同，路过上饶，停靠5分钟，这个时分听到上饶鸡腿的叫卖， 你下火车买了个鸡腿，然后回火车上，火车开动了开吃，谁知道或人，买了鸡腿直接吃，吃完了才上火车，成果你吃鸡腿花了6分钟时刻，火车开走了！这段程序的流程就相似这样，写了个数据进来，保存下来，告诉运用层，然后完结余下的操作（收到了数据，要回一个回执给主机），本次数据交互完毕。你在这儿加程序，那等所以在上饶下火车吃鸡腿。
2，因为BLE的数据，只在衔接距离时刻到的时分交互，所以，你写的处理程序，不能长时刻的占用CPU，假如你占用CPU的时刻大于了这个衔接距离，那你会大概率BLE掉线。那些写程序喜爱加delay很长时刻的朋友，重新学习下编程思想，程序真不是这样写的。
3，CC2640R2F的重复进事情，会导致体系溃散。这是什么意思呢？便是触发一个event，然后进入event，你的程序是先发动这个event的守时器，比方下个10ms持续触发这个event，然后鄙人面的程序中，你delay了10ms，便是说，你还在这个event的处理程序中，体系又触发这个这个event，这样构成嵌套，就会导致溃散。这个碰到的人也比较多，要引起留意，最好是重新发动守时器的指令，放在这个事情子函数的最终方位。
不会弄一些动图，所以字多，估量能耐性开的人少。假如你看了，期望你有所得。
