刚开始做单片机项目时，主要以51和STM32F系列为主，并未涉及到RTC和看门狗这一块儿，主要依靠程序的正常逻辑、代码加固和增加断言等方式加固程序，除了功能上的问题，倒也没出现其它奇葩的现象；这也使我养成了一个不好的习惯，那就是不喜欢使用看门狗，总觉得看门狗用处不是那么大，写程序还要考虑喂狗方式，防止看门狗溢出导致程序重启，或者频繁喂狗导致看门狗开了也起不到作用。最近的几个项目都使用了低功耗MCU，并且需要长期休眠，依靠MCU的RTC自助唤醒等；也遇到了一些奇怪的问题，在此做一点记录。
1.RTC唤醒进入工作或者喂狗
在一些应用中，由于条件限制或者应用需要会使用电池进行供电，因此，需要产品长期在休眠状态下，只有外部有信号或者RTC设置的闹钟时间到了后时才进入正常工作状态，处理完后继续休眠。RTC唤醒进入正常工作没啥可说的，走正常流程即可；这里主要是RTC周期唤醒进行喂狗然后继续休眠的情况，比如，RTC周期为5S，看门狗一出时间设置为10S，那么正常情况下每5S会唤醒喂一次狗??然后继续休眠（选择看门狗的中间时间喂狗，防止频率漂移引起提前溢出重启）；那么问题来了，如果程序的大部分功能需要依靠RTC来实现，那么是可用的，能够增加程序的稳定性。但是如果RTC只是用来作为喂狗的定时器，我觉得用处不是特别的大；如果我选择RTC来喂狗，那么一般我会选择如下结构：
main(void)
{
if(喂狗)
{
喂狗（）；
｝
}
RTC_IRQHandler(void)
{
//RTC部分的处理
喂狗 = true；//设置喂狗标志
}这种结构如果程序中存在死等待，可能有用，其它情况有待考究；百度谷歌了一下喂狗方式，也有推荐使用开定时器定时喂狗的，感觉与我这个大同小异；可能还是需要从驱动到功能详细的研究代码，严谨一点防止出错为上策。
2.程序重启维护系统的稳定性
曾几何时，做了一个小项目，客户需要低功耗并且RTC定时发送设备状态信息，可能一连好多天都是在休眠状态下，我也单纯的按照需求上写的一样，实现了全部功能并交付客户使用，几个月的测试并未出现异常情况。就在我以为万事大吉，坐等胜利的时候，天不遂人愿，由于环境的不同和使用方式的不同，出现了异常现象，然后Review code；被上级发现长期的休眠中没有让RTC定时喂狗，只有设置的周期到了会唤醒并处理数据，并且系统是裸奔的，没有开看门狗，然后。。。。。。，然后自然就是一顿批了。
按照要求，修改了唤醒方式，周期唤醒并且开看门狗定时喂狗，然后程序没周期内重启几次以保证程序正常。然后，然后问题依然存在，只是因为使用环境和其它原因造成的不稳定现象。
这里我想追究一个问题，那就是依靠程序周期重启来增加稳定性是否真的可靠？项目中，有许多是裸奔的，连续几年也未出现异常，有的也会出现一些奇怪问题；但是我还是觉得，依靠简单的重启来维护产品的稳定性还是不那么靠谱，毕竟隔三差五的重启给人的使用体验也不是很好（此处只针对单片机类）。不知万能的Internet上的大神们有什么高招，还望不吝赐教。