程式是什麼?程式就是個流程，很多人對着協定棧，不知道從哪下手，然後哪裡出了問題也不知道怎麼改，提出問題，别人說原理，又覺得自己用不上，實際上，原理就是流程，你順着原理去讀程式，就很順暢。
先解釋幾個基本點：
一、低功耗的思路。這個概念，很多人不懂，先解釋這個，懂了這個，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，這樣形成嵌套，就會導緻崩潰。這個碰到的人也比較多，要引起注意，最好是重新啟動定時器的指令，放在這個事件子函數的最後位置。
不會弄一些動圖，是以字多，估計能耐心開的人少。如果你看了，希望你有所得。
————混在金華的一電子小民工