上一篇博客【msp430 launchpad、RF模块】调制、解码无线信号中，调制、解码是不同的程序。这篇博客是把两个功能糅合到一起，通过按键进行功能切换。
糅合到一起的过程遇到了一些问题，在此记录一下。
①从发射模式切换到接收模式功能程序会有一点紊乱
原因：
发射函数running时，发生按键中断，转入按键中断处理函数，此时将模式转换为接收模式，跳出中断处理函数。接着，程序会恢复中断现场继续执行之前没执行完的发射函数，而此时程序已经切换为接受模式，随时会响应信号接收中断，不论是信号接收中断处理函数还是信号发射函数，都会用到door_signal_buffer，而且二者都会控制led进行状态显示，于是程序就发生紊乱了。
解决办法：
不由按键中断处理函数打开接收中断控制位，而由信号发射函数打开。设立一个标志位need_open_dump_signal，而按键中断处理函数只变更这个标志位的状态，由信号发射函数的结束部分根据这个标志位的状态来决定是否打开接收中断控制位。而这个标志位就像一张传话纸条。用户想要切换为接收模式于是按下按键，按键中断处理函数便在给发射函数的传话纸条上写“等你执行完了把接收中断打开哈”，然后按键中断处理函数就走了，发射函数继续运行，当它发完信号后看到传话纸条就顺手把接收中断打开了，然后它就走了。接下来接收函数就上场了。
启示：
利用中断实现相应功能时，务必注意【中断处理函数中的相应操作】与【中断返回后接着执行的代码】有无冲突、以及如何避免冲突。
②关于信号接收功能的一点矛盾之处
关于这个程序，我有不得不正视的现实：
- 如果开启了接收模式，那么程序几乎会一直处于【处理信号接收引脚上升沿中断】的过程中，这会给按键中断检测带来不小的困扰
- 如果信号缓冲区的存储采用循环队列的方式，那么异常信号（由信号源发射的有正确同步位但数据位畸形的信号、其他的一些符合格式的干扰信号）会把正确的信号覆盖掉
所以哪怕开启了接收模式，也不能让程序真的一直接收！
但我又有如下期望：
- 至少要采集n个信号才可以进行发射 <== 毕竟不可能发射空信号吧
- 得到的信号能最大程度的精简，最好缓冲区里没有重复的信号 <== 毕竟内存宝贵，都存同样的信号好像感觉有点浪费 <== 需要进行冗余处理，即接收信号时检测到缓冲区已有相同信号，则弃之
分析可得，期望1和期望2在一定程度上互相矛盾！如果进行了冗余处理，那很可能一直采集不够n个信号（除非发生干扰太多的情况），那么程序就会一直处于接收状态，直接导致现实1.
所以，程序里我注释掉了冗余处理函数。程序不做信号冗余处理，缓冲区满了就停止接收信号。
③关于标志位的使用
起初没怎么注意这个问题。要使用某个标志位时，直接0x00或0x01，判断是否为真采用if(flag)形式，判断是否为假采用if(!flag)。可是程序执行过程中两个led的状态很紊乱。所以在确定led切换代码无误后，我开始怀疑程序的流程出现了紊乱。果不其然，当flag为0x01时，不管是if(flag)还是if(!flag)都为真！
启示：
想要的功能决定对应的判断条件，也决定了判断条件之间的关系。写代码的过程中，一定要把控好这个关系。
最终程序效果：上电执行默认是接收模式，当信号缓冲区满时led1会有规律地闪烁若干次。按下按键切换到发射模式，发射模式下led2闪亮(因为闪亮次数频繁所以肉眼感觉是常亮)。再次按按键回到接收模式，此时会清空信号缓冲区，重新记录信号。从接收模式切换到发射模式，如果缓冲区未满是不会切换成功的。
My codes are here.