RF/无线
几天前一个Bug,调试了2天才解决(已经有几年没有遇到过了),为此将该问题的原因和解决思路记载,以备忘和共享。生命有限,错误不能重犯。欢迎讨论,更欢迎您共享经验和智慧给我们。
需求引入:在无线组网通信中,为充分节能,Node一般需要深度睡眠,4秒内唤醒。Sink和Node通信时序如下
实现代码:基于Contiki操作系统的进程实现代码如下,其中PROCESS_YIELD()用于阻塞进程,等待信号。
/* Turn on RF to listen awake tone. */
NETSTACK_RADIO.on();
temptimer_Start(s_wWaitAwakeTime, InformTimeout);
PROCESS_YIELD();/* #1 阻塞进程,等待超时或接收到唤醒信号 */
if (PROCESS_EVENT_RX_AWAKE_TONE == ev) /* RX awake tone */
{
/* EXPLAIN: TIM is turned off by ISR of RF. */
temptimer_Start(s_wWaitDataTime, InformTimeout);
PROCESS_YIELD();/* #2 阻塞进程,等待超时或接收到数据帧 */
......
}
else /* Rx data that not to us */
{
......
}
错误原因:如下图所示,当node_process同时接收到2个信号时,上面代码的#2无法阻塞进程,导致出错。
TIM和RF中断“竞态”导致node_ process接收到2个信号
解决方法:当TIM和RF中断“互斥”时,node_process只能接收到1个信号,它就能阻塞在#2语句上,时序正确。
TIM和RF中断“互斥”使node_ process只接收到1个信号
经验总结:
1. 思维路线错误:进程与中断的时序出错,本人总是怀疑“定时器中断异常爆发”导致#2阻塞语句失败,然后一路 错下去:做定时器中断实验,查数据手册,测试库函数,到网上搜索文章,问询STM8L开发的人员...... 没有隔离错误源,应该一开始就编写测试用例,查明是不是“定时器中断异常爆发”.
2. 没有彻底测试TempTimer驱动模块,人们对于怀疑的东西,思维上容易更怀疑它,尽管它可能是对的。开发时,还是要模块化测试,尤其是底层驱动。
3. 像上述比较复杂的时序和进程开发,一定要画出时序图,写出逻辑流程图。“进程竞态”的错误,容易发生,再加上它偶尔才爆发,难以调试。对付它的良药是:时序图+逻辑流程图。
附:逻辑流程图:
全部0条评论
快来发表一下你的评论吧 !