Cпасибо,Саша.
А на практике все таки,как убедиться,что все процессы живы,а не
весело щёлкаете WDR и глухо висите

Например, завести набор флажков. При WDR сбрасывать. А в каждом критичном месте программы - взводить свой флажок. При очередном сбросе WDR - проверить, все ли флажки взведены. Если не все, то висим.
Можно усложнить, ждать взвода флажков несколько циклов.

Спасибо,что-то такое я и представлял.А если пара-тройка задач асинхронные и главное требуют обслуживания с периодом больше периода срабатывания собаки?

а на практике, делаем примерно так:
при загрузке определяем источник ресета, если было не от power on , то регестрируем ошибку.,
делаем заглушки на все незадействованные прерывния(если есть связь с верхом то предаем это на верх ), запускаем автомат контроля использования стека/рам, запускаем автомат контроля
использования текущего размера системного тика....

дальше просто работаем, и что удивительно, все контролируем...

Тогда флажка не хватит, нужен счётчик. При получении флажка от такой задачи счётчик сбрасываем. При неполучении - увеличиваем. Когда значение счётчика превысит порог - висим.

Ну, недостаток сброса в системном таймере неоднократно обсуждался (например, получение команды HALT. Не знаю правда, есть ли она в AVR - уже привито ). Я обычно использую достаточный минимум - в системном прерывании взводится флаг, в основном кольце по этому флагу непосредственно сбрасывается WDT.

Вообще-то я хотел написать, что для обычных дивайсов следует идти не от умозрительных заключений об успешной или неуспешной ловле сбойных состояний, а стандартном тестировании приборов по стандартным методикам. Если доктор прав, и вероятность сбоя в нормальных условиях десять в минус восьмой, то программными извращениями можно ее улучшить на порядок или ухудшить на порядок - и при этом ничего не почувствовать. "Опыт - критерий истины". Все удары молнии, броски по питанию и прочие неприятности давно уже стандартизованы. Протестили - и вперед.
А программирование - никакое это не искусство, и это такое среднее ремесло, давно уже привлекающее только тех, кто больше ничего делать не умеет. На этой высокой ноте разрешите пойти спать.



Зачем же? На практике можно продолжить работу - подумаешь, сброс прошел?
Работать! Вернуться на то же место. Не под ОС, конечно

Дык, конкретно здесь, только для того что бы знать что оно было,
если в рамках поставленной задачи нам пофиг, было или нет, мы можем просто проигнорировать....
а если не пофиг, можем и запомнить....что был сбой ....

Согласен...Мог и R16 сбитцо..Мог и SREG_Z... Была ещё такая тестовая прога:

; Зажечь светодиод
ldi R16 , 0b11011111
out PortC , R16
;------------------
Loop:
cli
wdr
rjmp Loop
;---------------
Crash:
; Погасить светодиод
ldi R16 , 0b11111111
out PortC , R16
rjmp Loop
;---------------------------
rjmp Crash
rjmp Crash
rjmp Crash
rjmp Crash
.....
rjmp Crash
rjmp Crash
rjmp Crash
rjmp Crash
;------------------------------



При испытаниях вначале светодиод горел... Пять минут...После того как я потрыкал пьёзозажигалкой светодиод погас... Трыкал ещё...И один раз (за целый день "издевательств" мне удалось обратно зажечь светодиод


Ему также всё равно на каком языке написана программа, зашитая в девайсе. Ему важно только чтоб девайс выполнял возлагаемые на него функции с требуемой степенью надёжности. И потребителю всё равно, что выбранный Вами СИ-компилятор не поддерживает те или иные конструкции. И потребителю не скажешь (когда выясниться, что произошёл сбой из-за того, что программное обеспечение не обнаружило случайный джамп в область данных во флэшь): "реализовать программные защиты для меня было слишком сложно - поэтому я их вообще не делал"

Дык вот это и должна хотя бы пытаться сделать программа. А чтобы это сделать она должна по-крайней мере обнаружить, что сбой имеет место


Ещё один мне "Америку открывает" Повторяетесь , Господа.. По кругу уже начинаем топтаться.

Повторяю для "не четателей а писателей": я ниразу не отрицал необходимости впервую очередь аппаратных решений для обеспечения надёжности



А Вам за что платят деньги? За то, что Вы штампуете посредственные программы? Зато быстро?
А что? Для Вас очень затруднительно написать прогу с обнаружением и разруливанием сбоев? Тогда я вообще не понимаю за что Вам платят деньги


А реалии рынка - эта гнать вал? Т.е. не нормальные программы, а, простите, посредственное фуфло? И что? Есть люди, которые за это фуфло ещё готовы платить деньги?



Если для Вас это всё слишком сложно, то почему Вы вообще работаете в области эмбедерства? Может лучше носками торговать?


Вот поэтому я "соломки подстелю" в виде спец. организации проги, чтобы сбои были по максимуму обнаружены и устранены их отрицательные последствия... Ибо какой бы у Вас супернадёжный девайс не был, лучше перебдеть, чем недобдеть. Да, "программные методы" не дают 100% гарантии обнаружения сбоя. А из-за 99,99% Вы и "мараться не будете"?


Во-во.... Я бы инженеров с таким подходом на версту бы не подпустил к разработке..Пусть лучше трусами торгуют..


А если подумать? Или Вы задаёте этот вопрос, просто чтоб продемонстрировать, что "против лома нет приёма"?. И что? Да..Это действительно тот случай, когда "против лома нет приёма".. Я же Вам уже говорил..И не один раз.. Что программа не может обнаружить 100% всех возможных сбоев.. Тогда к чему Ваш вопрос?


Вот например Вы если будете знать, что Вам 100% на голову свалиться или плита или кирпич. От кирпича Вас может спасти каска, а от плиты..уж извините...Ничего не поможет... И что? Вы даже каску не оденете следуя Вашей логике, которую Вы тут всем пытаетесь навязать.. Да?

Вы удивительно догадливы, именно за это За одним мааааленьким исключением: пока еще никто на качество моей работы не жаловался. А вот на скорость - да, бывает говорят, нужно быстрее.

См. выше

Да вот, виноват мозгами вышел, скучно мне носки продавать.

Лааадно! Пора спать

Не покатит. После первого же IJMP, возврата в while(1) не будет, а к сожалению генератор псевдо-случайных чисел будет давать всегда одно и то же число, с высокой долей вероятности - безопасное.

Поэтому модель лучше сделать такой:
1. random'ом или перебором заполнять регистры.
2. делать ICALL внутрь функции в которой выполняется SPM

Результат могу сразу сказать - рано или поздно - свалится

Была ещё такая тестовая прога:

; Зажечь светодиод
ldi R16 , 0b11011111
out PortC , R16
;------------------
Loop:
cli
wdr
rjmp Loop
;---------------
Crash:
; Погасить светодиод
ldi R16 , 0b11111111
out PortC , R16
rjmp Crash
;---------------------------
rjmp Crash
rjmp Crash
rjmp Crash
rjmp Crash
.....
rjmp Crash
rjmp Crash
rjmp Crash
rjmp Crash
;------------------------------


Максимум на 10 "трыке" пьзозажигалки светодиод гас. Если "удачно" подключить к корпусу девайса проводок, идущий от "земли" пьезозажигалки и "удачно" приложить точку приложения искры.


Вот и говорите после этого, что порча PC маловероятна

Сообщение отредактировал Дон Амброзио - Feb 18 2008, 07:24

Спасибо, уже дошло.
Остановлюсь на чуть исправленном
варианте

А еще интересно, как это Доктор так лихо чиркает пьезоспичкой, что у него все стабильно сбивается.
Вчера вечером чиркал-чиркал -- все нормально.
Доктор, Вы случаем эти киловольты на корпус не наводите ?
Блин, пока писал, Доктор уже сам ответил.
Так вот, когда нормы ESD sensitivity нарушаются, то к чему камлания?
Явно же ж кто-то виноват. А подвиг одного, как известно, - это преступление другого.
И что самое печальное - паранойя не только профессиональная болезнь, она еще и заразная.

Сообщение отредактировал _Pasha - Feb 18 2008, 07:32

По проге:
1 .А вы там случаем DDRC не забыли проинициализировать?
2. И ещё зачем там в цикле CLI? Понятно было бы перед циклом, но в цикле не очень понятно. Это тоже с каким то тестированием связано?

Просто эти мелочи позволяют соменению закрасться.

По поводу защиты от "случайных" jump:
Допустим наша программа состоит из блоков Check - это всяческие проверки о которых тут писалось и блока Run - в этом блоке выставляются управляющие сигналы, действия которых нельзя отменить(ну к примеру "Пуск ракеты" это всё конечно утрировано).
В итоге получим

В результате случайного джампа мы попали в Run....

Конструкция

не покатит в силу специфики применения. Т.е. в этом случае задача всё таки нерешаемая или я не прав?

Конечно если программа будет на 99,(9) % состоять из Check, а оставшаяся часть будет Run всё равно будет ненулевая вероятность пуска ракеты.

P.S.
Дон Аброзио, если не составит большого труда и это не является большим секретом могли бы показать стандартную обвязку вашего MCU(цепи питания, резета, развязка входов выходов)? Eстесно готовые схемы не надо. Просто в общем виде типа как в апп ноте рисуют. А то получается вы всегда приводите программу без схемы и говорите что сбоит программа, а может дело то и не в бобине.

На основании этх тестов я понял, что всё же лучше попытаться обнаруживать в программе эти случайные джампы. После этого я решил проверить "а как же с ОЗУ? Оно не портиться?" И модифицировал прогу так, что она у меня непрерывно совершала тест ОЗУ. "А как же порча ячеек FLASH?" - подумал я. Короче, сделал и непрерывный тест флэшь. Короче у меня крутились 2 потока и ядро RTOS. Один поток непрерывно тестил ОЗУ, другой флэшь. И плюс оба потока были "сконструированы" так, что обнаруживали (разумеетцо не со 100% вероятностью) случайные дампы.

Выяснилось, что:
а) Чаще всего проц вываливался на обработчик случайного джампа
б) Потом на обработчик порчи ОЗУ
в) На обработчик порчи флэша (после проверки флэщи программатором выяснялось, что на самом деле флэшь не портилась, а переход на обработчик вызывался порчей ОЗУ во время теста флэшь)


Хотя конечно нельзя утверждать со 100%-й уверенностью, что переход на соотвествующий обработчик сбоя был вызван соответствующей ему причиной. Например переход на обработчик порчи ОЗУ запросто мог быть вызван случайным джампом. Хоть это и менее вероятно (за счёт того, что у меня программа организована специальным образом + некоторые аксиомы по вероятности, которыми я руководствовался), но исключить такую вероятность нельзя


А что? Реальные помехи просто обязаны подчиняться нормам ESD А то их в тюрьму посадят если они нарушат нормы ESD?




Не забыл.. Иначе бы светодиод не зажёгся... Кстати , да... Погасание светодиода в конкретно этой программе могло быть вызвано и случайным изменением PortC, ddrC... А вообще у меня была куча различных тестовых программ (всех вариантов и не упомнишь) . Поэтому я в своих примерах на форуме пишу только часть кода, из которой можно понять основную идею теста



Может это и паранойа (как некоторые выражаются) но для надёжности. Я всегда так пишу когда мне нужен гарантированный программный СТОП. И написать однц 1-тактовую команду меня не сильно затрудняет. Так же как процессор не сильно затрудняет её выполнить


А если подумать?
У меня "запуск ракеты" от одной команды невозможен. Ибо у меня железо выполено таким образом, что релюшка, запускающая "ядерную ракету" ( ) включается как минимум 2-мя пинами, сигналы на которых устанавливаются в разных точках программы. Так что даже если на один из пинов в результате сбоя будет подан сигнал "Enable RUN", то на другом-то пине такого сигнала не будет. И Америку не придётся с карты стирать ластиком

1. На реальные помехи - реальная экранировка подсобного хозяйства и реальные техусловия
2. Пример решения на уровне архитектуры: см. MC68HC908MR08(freescale) понятие "WRITE-ONCE REGISTER"