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层里有个读写回调程序，如下图：
写回调

读回调

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