Днес като всеки петък се струпа много работа и нищо не успях да направя по въпроса. А и цялата друга седмица няма да мога. Но събрах доста материал за размисъл и за изпробване. Като изпробвам нещата, обещавам да постна резултатите. Още веднъж благодаря на всички.

Доста време мина от последния ми пост, но чаках нещата да се установят. В момента изделието ми работи, но му се случва да зависне понякога. От към хардуер пробвам почти всичко, дори слагах оптрони и на входовете, слагах екранирани кабели и овивах пласмасовата кутия изделието с домакинско фолио. Накрая сложих едно изчакване от 0.5 сек преди да разреша прекъсването за динамичната индикация и нещата драстично се оправиха (явно не е имало време да се инициализира нещо правилно).
Пак благодаря на всички за съветите.

Имам още едно питане, което е горе-долу към същата тема и ще го направя тук, за да не пускам нова тема.
Иска ми се все пак да се застраховам напълно от зависване, като използвам WDT. Проблема е, че като четох описанието на кучето, при задействането му се рестартира процесора. Предполагам, че така се губят текущите стойности на променливите, дефинирани в програмата. В програмата ми има 3-4 процедури, които се изпълняват циклично. Идеята ми е, като зависне процесора, по една от променливите да разбера в коя процедура е бил процесора преди зависването и да го върна там. Ако стойностите на променливите са запазени, процесора дефакто ще продължи от мястото, където е бил преди зависването.
Въпросът ми е следния: Има ли област от RAM-а, която не се засяга от ресета(За EEPROM-а FLASH-а знам, но все пак те са с ограничен брой презаписи). Дори да записвам стойностите през интервал от 0.1 сек., пак ще ми свърши работа, защото приложението не ми е много критично откъм точност на времевите интервали.

Рам-а си запазва стойностите (теоретично - не съм го изпитвал на практика). Има един регистър който казва какъв е бил резета. Проблема ти обаче най-вероятно не е смущение. Провери кои регистри се ползват от програмата и от прекъсването (най често тези за индиректно адресиране) и на входа на прекъсване ги запзвай в някакви други променливи, а на изхода ги възстановяваш.

По принцип процедурите ми се състоят от няколко вложени цикли с броячи в тях. Тези променливи са ми важни. Каквото и да причини зависването, ако имам тези променливи и се върна в процедурата, в която се е случило зависването, ще си продължа без проблем. Ако наистина се запазват стойностите на регистрите с общо предназначение, това ще ми свърши работа. Ще трябва да го проверя на практика.

Трудна работа. Моите наблюдения са, че при увисването на процесора и рам-а се прецаква. Моторолските процесори имат флаг по който се разпознава вида на ресетването. За другите не зная.

Рама по правило се запазва ако не е отпадало захранването. Но ако забиването е било в резултат на силно смущение може да има промяна и там.

Честа практика е да се съхраняват неща в рама и да се ползват след рестарт.
За да стане работата и променливата да не се инициализира след ресета в C компилаторите има __no_init,noinit или нещо подобно с което се указва на компилатора да не инициализира съответната промеллива.
Само дето ти май беше от бейсиколюбците и ще трябва да си го правиш на асемблер вероятно. Не е лесна съдбата на пикобореца особенно когато пише на прекрасния Proton Basic.

Добра практика е в няколко други клетки на паметта в съседство с адреса на променливата да се записва някакво статично съдържание. Ако след ресета е вярно то вероятноста и полезната ти информация да е вярна клони към 100 процента.
Може и с контролна сума ако предпочиташ.

Благодаря за добрите идеи. На бейсик не съм работил от Правец 82 насам. Преди работех на Паскал, после на Делфи. Сега за ПИК-ковете ползвам CCS. В хелпа му не открих подобни команди(...__no_init...), нито в хедър файла на ПИК-а (16F887). Абе, щом рама по принцип се запазва след рестарта, има смисъл да експериментирам.

Нещо съм останал с грешни впечатления
Погледнах за CCS-a. Май при него ако не укажеш инициализация на дадената променлива не я закача в стартъп кода. Тоет по подразбиране променливите са __no_init преполагам

Това е добре. По принцип, тези зависвания не са много фатални, защото схемата е за управление на машина, а около нея винаги има оператор, който да се намеси, но е неприятно. При мен е удобно да нулирам кучето в прекъсването за динамичната индикация, защото прекъсването е само едно и винаги се изпълнява в точно определеното време. Ще симулирам забиване в отделните ми процедури, да видя дали след ресета ще продължи от старото си място. Тази седмица би трябвало да имам време за тези експерименти. Ще постна резултата.

Никола, протона няма такава опция да инициализира променливи, по принцип се прави ръчно, ако е необходимо. Пробвал съм следната постановка (само че с 18-ка). Пускам кучето, пускам машинката която и е казано да прескача инициализацията при всички видове резет без POR. После предизвиквам ръчно (с баране по краката ) резет от кучето, и машинката си тръгва нормално. Обаче при силни външни смущения не съм пробвал какво ще се случи. Машинката управлява едно странно чудо дето прави пара на принципа на бързоварче с лъжички (само че трите фази с едни големи електроди като човешка длан потопени в казанче с вода) не знам какви смущения генерира, ама понякога се палят фазите и няма проблеми с работата на контролера.

На едни небързи, но податливи към смущения (дълги външни кабели без галванично развързване) устройства съм регистрирал, че рам-а се прецаква. Ако машината има датчици, опитай се по тях да се ориентираш къде си, или поне направи дубул на най-важната част от рам-а и я проверявай дали е една и съща след ресетване от кучето. Ако процесорът ме може да се ориентира какво да прави , по-добре спирай машината или я извеждай в изходно положение (което е по-безопасно).

Предложението на никола до някъде е рационално но няма как да му се довериш, напълно възможно е да има промяна точно в тая клетка дето ти трябва а съседната да и няма нищо, според мен ако имаш време и рам по добре пази по няколко копия на променливата която те интересува, примерно 3, след това може да решиш дали да работиш само при 3 еднакви или и две еднакви ти вършат работа. Това като цяло разбира се усложнява софтуера ти в някаква степен, но ти защитава данните.
Така като четох послендите неща ми звучи като да не е проблем със смущенията, ако след като си добавил изчакване нещата са се оправили по скоро ми звучи на проблем в самия софтуер. Там някой предлагаше да видиш как си обработваш регистрите, не е лоша идея, и като цяло не е лошо да проверяваш и фага за ресет, поне да разбереш каква е причината.

По някое време и на мен взеха да ми се въртят подобни мисли в главата. Вчера седнах уж да си поиграя с кучето, но си поразгледах програмата и видях, че съм разрешил прекъсванията за динамичната индикация преди да установя портовете. Като оправих нещата, не е имало забиване цял ден днес.
Благодаря на всички за помощта. От тази беседа научих доста нови и полезни неща

Zeus,
не искам да съм злъчен .. ама какво ти бях написал на стр.2 от темата
в 90% от случаите съм изпитвал зле контролируема нужда да гръмна някой, който ми разправя "всичко ми е наред с програмата незнам защо не работи"
имам лека тъга по онова време отпреди 10ноември когато имаше самокритика(помня трябваше в час на класния да се изтъпаниш пред класа и да мрънкаш за някакви твои пропуски в учебният процес и т.н.)
сега няма такова нещо и народа е винаги уверен в своята непогрешимост
аре успех

Прав си(хиляди извинения ). Но проблема наистина по нищо не приличаше да идва от програмата (даже и сега ми е чудно, а и не съм 100% сигурен, че пак няма да го има, но по-нарядко). Свикнал съм, когато програмата прави проблеми, да има някаква повторямост във времето (все пак имам само 1 микроконтролер и няколко ключа на входовете). Явно някаква инициализация не се е извършвала коректно, но как това е повлияло, та устройството да си работи 3 часа, като за това време превърта 10-12 пъти целия цикъл и после забива на следващия (периода на работа винаги е различен), направо ми е тъмна Индия . Може би за старите кучета е смешно, но все пак на мен ми е първият сериозен проект с микроконтролер.