RTC唤醒喂狗和重启那些事儿

Posted teasy

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了RTC唤醒喂狗和重启那些事儿相关的知识,希望对你有一定的参考价值。

刚开始做单片机项目时,主要以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上的大神们有什么高招,还望不吝赐教。

以上是关于RTC唤醒喂狗和重启那些事儿的主要内容,如果未能解决你的问题,请参考以下文章

融云 IM 那些事儿

rtc唤醒日期每天唤醒写啥

JDK源码那些事儿之LockSupport

JDK源码那些事儿之LockSupport

STM8S103 独立看门狗和窗口看门狗

STM32Cube STM32L053配置RTC WAKEUP中断唤醒