Е зайфоде, ти пък, при по големи РС програми може и да е така, но в контролерите специално не виждам причина да има програми без бъг, особенно такива по 1000-2000 реда. Друг е въпроса за случаите когато се получава бъг, или по скоро неработоспособност в резултат на външен фактор, бъг не би трбявало да има, защото външните фактори може да са много, но въздействията в-у процесора са краен брой, и то не много ако се обобщят, какво може да стане :
- ресет, по някаква причина, проблем с захранване или нещо друго
- счупване на променлива, т.е. проблем в рама
- счупване на кода, т.е. еепром или друго от сорта
- всякакви "непредвидени" ситуации по входове / изходи, такива принципно не трбява да има, примерно ако имаш два крайни изключватели еидн срещу друг, не може да предполагаш че винаги ще е натиснат само единя, дори да няма физически начин да се натиснат и двата.
Значи, проблема от ресета в зависимостот контролера, но най-добре е да караш по стандартна процедура, т.е. да не разчиташ че стека ще е в същото състояние и т.н., дори да е казно че при ресета който си получил е така.
чупенето на променливи, просто ги пишеш по два или три пъти, ако искаш им пишеш и чексума някъде, но дали ще е чек сума или ще я имаш още веднъж същата работа, или почти ... е ако чексумата е 8 бита а променливата 32 може да спестиш място, ама тогава има анс да се счупи така че да и излезе чексумата, нищо обаче не пречи да я пишеш веднъж инвертирана, при ресет може да се случи да имаш само 0 в паметта, и ако я нямаш инвертирана ще приемеш че е вярна, щото ще имащш само нули, но ако я имаш инвертирана това няма как да стане. това решава 99.9% от чупенето на променливи, останалите 0.1% е трудно да ги орпавиш, но се случват твърде рядко.
Счупване на кода, т.е. по някаква причина кода е счупен, това може само да г откриеш, ако си проверяваш чексумата на кода при всяко стартиране, ако е счупен нямаш голям избор, там те оправя втори процесор.
За непредвидените входно изходни състояния говорихме, не трябва да има такива.
От тук нататък всичко е въпрос на задачато която управляваш, като познаваш процеса, затова е важно да се познават управляваните процеси, може да знаеш какво може да очакваш и как да го коригираш. Примерно ако управляваш някава величина, да речем дебит, един рестарт не трябва да повлияе по ниаккъв начин, защото той става за милисекунди, това е доста под инертноста на почти всички задвижки и клапи, т.е. ти ще пропуснеш пренебрежимо малка част. Ако обаче управляваш Ф117 само ти си знаеш при какво забиване колко критичен резултат може да последва, все пак не е лесно да караш тухла да лети ... та всичко е до задачата. Винаги има допустими ситуации, стига да не са прекалено дълготрайни, просто трябва да ги предвидиш и да знаеш какво става след някакво прекъсване.
За WDT позлвай го задължително, това му е идеята, да те ресетне ако зациклиш. Също така ако може да не позлваш while ще е най-добре, или в най-лошия случай навсякъде предвиждай начин да излезеш, по тайм оут, или просто не зареждай WTD вътре ... не мое да имаш while по дълъг от 100-200 мс ... не е правилно де, поне споредмен, и това е прекалено дълъг, всичко по дълго просто си го полираш переодично, или го слагаш на прекъсване ... та ако не зареждаш wdt това автоматично ще те изкара ако забиеш в някой такъв цикъл ... но пак по добре просто си сложи таймоут.
|
Обикновенно комуникацията се прави с state mashine. При нормално написан код имаш само едно място където извикваш getchar. А сега просто изтрии всичко дето си го натворил и го пренапиши според тия указания и ще видиш че няма да имаш нужда от нещо повече от WD и то не за да ти покрива бозата която си сътворил ами да ресетва процесора ако нещо се ошашка от смущения.
