发表于：2013/8/24 10:51:15
#0楼
/********************************************************************
* Filename: 一线研发之声：嵌入式C编程www.gec-edu.org经验 之 只有一条清狗语句
* key: 看门狗 系统架构 os-less 嵌入式
********************************************************************/
一个好的os-less系统，只有一条清狗语句，它位置就固定在main函数中的
while(1) /* or for(;;;) */
{
__watchdog_reset();
}
如果你有两条以上看门狗语句，那么会有什么后果呢？ 在系统足够复杂的时候，很能引起当机，由于静电或者程序自身逻辑的原因，进入了某个思维的盲点，系统进入一个有清狗语句的死循环里面，退不出来。这是最危险的，尴尬的，蒙羞的事情。
那么多出来的清狗语句，一般会用在哪里呢？
1. 系统初始化，有些设备初始化需要读取它的反馈状态，用while，担心复位，于是清狗。我一般用While (dev_read_status() && (i--))，这个i，32位顶天了。一般mcu没这么快法。
2. mcu睡眠前清狗。有些人喜欢在系统进入睡眠前清狗一下，担心系统刚好在那一刻复位。这只能说明你对自己的程序不了解，主回圈程序一圈下来，最大执行时间其实心中有数。函数多少深度宽度心中要有低。如果刚好睡眠前一刻复位，那也有可能在跑别的函数过程中复位。
3. 某些应用逻辑貌似要需要hold住，比如屏幕的暂停显示2秒钟等。许多人生生地把这种逻辑做成“硬延时”，就是死等。这是一个令人戚眉的做法，因为这意味麻烦的开始。在你需要暂停显示n秒的过程中，我的一切用户体验你无法响应我了，按键没反应，蜂鸣器不响，led灯不闪烁，一切好像死机了一样。等到系统显示完成后，用户心中大舒一口气，心中悬石落地，你终于又回气儿活过来了。这是糟糕的体验。
好吧，为了改善体验，许多人就想办法来。把用户体验搬到中断里面做，这是另外一个麻烦的开始，全局变量的增多和跨模块的判断，其根源之一始于此，弄个不好，就是随机性崩溃。中断程序变胖，终究是不方便的，于是为了改进，就只好在中断程序中置标志位，然后在hold_delay(TIME)函数的循环中清狗，并且判断标志位作响应动作。许多应用逻辑需要hold住的地方何其多，上九天下地府处处添加，函数深度不可测，逻辑递归难判断，系统大乱的祸患就此埋下。
那如何解决呢，事件--状态机，一句话概括，在当前状态下，遇到某某事件，则执行什么动作后，进入下一个状态。它似表非表，如水般自然，像空气般无痕……好了，其实是我不愿多讲，若要具体讲下去，恐怕涉及公司知识产权。尽管这个事件状态机思想是个公开的秘密，原理大家都懂，但做得好的还不多见。Hold住本身就是一种状态，看你如何抽象它了。
佛曰：菩萨畏因，凡夫畏果。那灾难之源，是需要敬畏戒惧的，待到结果发生，悔之莫及。
* Filename: 一线研发之声：嵌入式C编程www.gec-edu.org经验 之 只有一条清狗语句
* key: 看门狗 系统架构 os-less 嵌入式
********************************************************************/
一个好的os-less系统，只有一条清狗语句，它位置就固定在main函数中的
while(1) /* or for(;;;) */
{
__watchdog_reset();
}
如果你有两条以上看门狗语句，那么会有什么后果呢？ 在系统足够复杂的时候，很能引起当机，由于静电或者程序自身逻辑的原因，进入了某个思维的盲点，系统进入一个有清狗语句的死循环里面，退不出来。这是最危险的，尴尬的，蒙羞的事情。
那么多出来的清狗语句，一般会用在哪里呢？
1. 系统初始化，有些设备初始化需要读取它的反馈状态，用while，担心复位，于是清狗。我一般用While (dev_read_status() && (i--))，这个i，32位顶天了。一般mcu没这么快法。
2. mcu睡眠前清狗。有些人喜欢在系统进入睡眠前清狗一下，担心系统刚好在那一刻复位。这只能说明你对自己的程序不了解，主回圈程序一圈下来，最大执行时间其实心中有数。函数多少深度宽度心中要有低。如果刚好睡眠前一刻复位，那也有可能在跑别的函数过程中复位。
3. 某些应用逻辑貌似要需要hold住，比如屏幕的暂停显示2秒钟等。许多人生生地把这种逻辑做成“硬延时”，就是死等。这是一个令人戚眉的做法，因为这意味麻烦的开始。在你需要暂停显示n秒的过程中，我的一切用户体验你无法响应我了，按键没反应，蜂鸣器不响，led灯不闪烁，一切好像死机了一样。等到系统显示完成后，用户心中大舒一口气，心中悬石落地，你终于又回气儿活过来了。这是糟糕的体验。
好吧，为了改善体验，许多人就想办法来。把用户体验搬到中断里面做，这是另外一个麻烦的开始，全局变量的增多和跨模块的判断，其根源之一始于此，弄个不好，就是随机性崩溃。中断程序变胖，终究是不方便的，于是为了改进，就只好在中断程序中置标志位，然后在hold_delay(TIME)函数的循环中清狗，并且判断标志位作响应动作。许多应用逻辑需要hold住的地方何其多，上九天下地府处处添加，函数深度不可测，逻辑递归难判断，系统大乱的祸患就此埋下。
那如何解决呢，事件--状态机，一句话概括，在当前状态下，遇到某某事件，则执行什么动作后，进入下一个状态。它似表非表，如水般自然，像空气般无痕……好了，其实是我不愿多讲，若要具体讲下去，恐怕涉及公司知识产权。尽管这个事件状态机思想是个公开的秘密，原理大家都懂，但做得好的还不多见。Hold住本身就是一种状态，看你如何抽象它了。
佛曰：菩萨畏因，凡夫畏果。那灾难之源，是需要敬畏戒惧的，待到结果发生，悔之莫及。