剛開始做單片機項目時，主要以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上的大神們有什么高招，還望不吝賜教。