Что значит мучиться? Вам что? Утюг на живот ставят чтоли? А я люблю помучиться. Не люблю простые задачи. Чем сложней задача, тем лучше я её решу, поскольку буду работать не спустя рукава, с леньцой, а с огоньком


Вот вот

Откуда такие выоды



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

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

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

Видете как просто? По объёму написанного - столько же. Так почему просто не ответить на поставленный вопрос?

Далее - исходя из этого - WDT лучше помогает чем ваши ограничители. Какой в них смысл? Таймауты применяют при работе с внешним оборудованием, для того, чтобы диагностировать сбой в работе оного. Диагностировать, для того чтобы обработать ошибку определённым образом. Например если не получили ответа от rs485, посылаем повторный запрос, если произошёл сбой при работе с ЖКИ - сбрасываем и перерисовываем. Но если в результате "не ответа" нечего делать? Если уровень сбоя превышает возможности его обработки, в этом случае идёт полная перезагрузка процессора. И аппаратный аварийный рестарт - всегда был более лучшим средством чем программный.

Очень упрощённый взгляд на проблему. Результатом сбоя явлются либо материальный ущерб, либо (в худшем случае) человеческие жертвы



Такая простота хуже воровства и граничит с полной профессиональной некомпетентностью

Да нет таких в нормальной продуманной программе. Сколько раз Вам повторять


А в многопоточных RTOS не применяется? У меня наприммер в моих программах работающих в среде моей же RTOS я контролирую до 50-ти таймаутов различных внешних и внутренних событий

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

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

Спасибо Вам большое...Я давно уже хотел Вам это предложить... Да стеснялся.. Боялся Вас обидеть... Я конечно благодарен Вам за ликбез по использованию WDT (о которой я разумеется за более чем 15 лет работы с MCU и понятия не имел).

P.S. Жаль только что дисскуссия в этой теме зациклилась вокруг WDT (я рассчитывал услышать чего-нибудь новенькое, а тут опять про WDT) и Вы сработали сейчас ватчдог таймером и вывели дисскуссию (я надеюсь) из этого цикла

хорошо что не подрались...

может для начала определить с какими сбоими в работе мк боремся и в серии или до.

например можно создать следующие темы:
- изменение PC внешним воздействием и как и нужно ли с этим бороться;
- сбой работы АЛУ .....;
- отказ АЛУ....;
- сбой чтения из flash;
- выход из строя ячеек flash.

и средства борьбы можно разделить на внешние (по отношению к мк и внутренние - программные и аппаратные).

вопрос интересный и важный

Всегда пишу именно так, но хочу заметить что попав в результате сбоя, к примеру, на метку ReadLptEPP (не загрузив константы в регистры) можно превысить допустимое значение ожидание со всеми вытекающими из этого последствиями.
Предпочитаю использовать WDT + обязательный выход из цикла по переполнению описанный Вами.

Извините, что возможно немного не по теме. Обсуждается Защита секции кода во FLASH. Вероятность сбоя устройства равна 10 в минус 9 степени - это вероятность сбоя устройства из-за сбоя программы ? На каком интервале определена эта вероятность ( на выполнение одной команды, времени жизни всего устройства)? Сбой в программе отдельно взятого МК в системе приводит к 100% сбою системы ( это я к тому, что сначала рассматривалась программа, но вероятность ошибки в самой программе не рассматривается, долее говориться об устройстве а спрашивается о системе)?

Согласен.. Просто я привык уже работать в среде мной же разработанной RTOS, где любой поток может быть вытеснен другим более высокоприоритетным потоком вообще говоря на случайное время. И как в этом случае Вы рассчитаете на сколько должен быть запрограммирован WDT? Поэтому в этом случае счётчик ограничитель количества итераций выглядит более предпочтитетельным. Тем более бывают задачи, где важно именно количество итерация цикла, а не время его выполнения



Хорошее решение.. Но только для программ не работающих в RTOS с вытесняющей многозадачностью.
Я же использую в многозадачной среде виртуальные таймеры и WDT, которые фактически являются обратными счётчиками CPU_Time потока. Т.е. у меня любой поток может посмотреть в любой момент своё CPU_Time - время, которое бы он выполнялся если бы он были один в системе. Фактически CPU_Time - это счётчик тактов выполнения кода потока. Отсюда можно делать следующее. Вы прикидываете сколько максимальное количество тактов будет выполняться поток от точки A до точки B. Инициализируете в точке A виртуальный WDT, а в точке B его реинициализируете новым значением. Если этот виртуальный WDT обнулиться до прихода CPU в точку B потока, то это сбой и система это отработает. Кроме максимального времени работы некоторого участка кода, которое контролируется виртуальным WDT. Я ещё контролирую минимальное.. Ведь если известно, например, что подсчёт CRC 256-ти байтного пакета не может быть меньше 547788 тактов (цифры взяты просто для иллюстрации примера) и мы попадаем на точку завершения подсчёта и видим, что этот участок кода выполнился за 10790 тактов - то ясно же что имеет место сбой....



Да млин, всё-таки неприятно, когда человек не врубившись "что почём" начинает меня "мордой тыкать" в такую элементарщину, что создаётся впечатление, что либо человек меня принимает за полного ламера (и это с моим-то более чем 15-ти летним опытом разработчика девайсов на базе MCU) либо сам таковым и является


В этой теме я рассматриваю только один вид сбоев: несанкционированное выполнение код во FLASH, вызванное аппаратным сбоем.
Этот сбой проявляется в том, что осуществляется переход в запрещённую точку секции кода , либо в разрешённую, но тогда, когда условия для выполнения этой секции кода не наступили.

Среди основных причин этого сбоя можно назвать следующие:
1) Случайное изменение значение счётчика команд из-за помех
2) Случайное изменение содержимого в ячейке ОЗУ в области, где храниться таблица переходов
3) Случайное изменение ОЗУ стека или указателся стека, в результате чего после команд ret/reri мы "улетаем" не пойми куда


СЮДА Я НЕ ОТНОШУ те сбои в командах перехода, когда в программе содержиться ошибка, проявляющаяся в том, что при не которых наборах данных она вычисляет не верный адрес точки перехода




Если сказать короче: здесь рассматривается сбой, проявлящийся в том, что происходит переход от одной точки программы к другой и этот переход не относиться к множеству всех возможных переходов, определённых на этапе разработки программы

Сообщение отредактировал Дон Амброзио - Feb 13 2008, 09:05

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

ИМХО для программиста достаточно встроенного WDT (правда некоторые спецы по надежности советуют использовать внешний) и грамотно написанной программы.

Вероятность отказа устройства 10 в минус 9 степени - это попахивает авиацией, резервированием и прочими усложнениями:-))
Для "гражданских" устройств 10 в минус 5 степени уже хорошо.

Сообщение отредактировал Schtirlitz - Feb 13 2008, 09:32

Вероятность сбоя устройства, явившегося причиной в сбое программы


Я же писал.. В течение года работы девайса.. А вообще Вы на цифры не обращайте - они взяты мной просто для иллюстрации моего примера


Согласен. Просто "система" в простейшем случае может состоять из одного МК и светодиода


Постепенно всё выясним.. Следите за темой


Повторю и для Вас: цифры взяты "от балды" просто для иллюстрации приведённого выше примера

Вы спрашивали почему тут все уперлись в WDT?. Объясняется это тем что это решение практически на уровни железа. Как можно программными методами отследить случайный переход на случайную точку программы? Даже если в программе большая часть функций направлена на контроль правильности выполнения кода, ни что не защитит программу от перехода на случайный адрес с последующим нарушением нормальной работы устройства.
Как мне кажется решение должно быть на уровне железа.. (внешние контролирующие устройства(тотже только внешний WDT), дублирующий контроллер(возможно выполняющий туже задачу) и т.п.) Это мое ИМХО.

В реальной задаче, я пишу это так:

В том посте я про cpi R25, 1+high ( Border_Counter) просто не упомянул. Можно конечно R25:R24 сравнивать с Border_Counter+1, но это уже не обязательно. А код и время добавляет.

А вообще все важные переменные (а к ним счётчики однозначно относятся) обязательно на диапазон проверяю. Это как минимум. Те переменные, которые редко меняются, храню в области ОЗУ защищённой CRC. Это CRC я при изменении переменной перерассчитываю (cli). А в основном цикле (не RTOS) по 1 байту за цикл их CRC считаю и потом сравниваю. А те переменные, которые часто меняются, их инверсией защищаю. Например переменная 4 байта, и её инверсия 4 байта. Когда пользуюсь - ксор с инверсией побайтно делаю, и на FF проверяю. Кстати у меня всегда два регистра из R2..R15 имеются, которые я один раз устанавливаю, и больше не меняю. Одим равный 0x00 (RG00), другой FF (RGFF). Так вот, чтоб переменную в регистры R16..R19 загрузить, пишу обычно так:

А ещё хочу сказать, что все ожидания более 0.05 мС, обязательно нужно в основной цикл (не RTOS) переносить!!! И если не готово - к другой задаче переходить. Там что-то ждётся - к следующей и т.д. Какие уж там 4 секунды ожидания!!!
Но если уж 4 секунды - где, в таком случае, в том цикле, который все дружно переписывали, столь любимая SasaVitebsk-ом, команда wdr???
Кстати с wdr у атмела глюки. В описании написано, что при WDP2=WDP1=WDP0=1 типовое значение при 3В 2200 мС, при 5В 2100 мС. В реальности: от 1500 до 1800 мС. Я из-за этого на две секунды засыпать не могу - собака будит раньше чем RTC.
Я теми AVR пользуюсь, у которых собака=сбросу. Но даже если у собаки свой вектор будет - что это изменит? Что в обработке запуска нельзя WDRF проверить? Конечно в стеке адрес, откуда собака сработала, будет (если стек не навернулся). Но это только на этапе отладки имеет значение. В реальном устройстве это ничего не даст - все программные глюки д.б. уже устранены.

Но вот узнали мы, что щас Crash, а дальше-то делать-то что? По идее надо лог записать, и хорошо-бы восстановиться с наименьшими потерями.

А у меня такой вопрос: кто нибудь здесь лог-ги пишет???
И куда пишите?
Я-то пишу в AT45DB642D. Потом их как файл из MassStorage читаю. Так вот заметил, что флешка по помехозащищённости похуже чем AVR будет! Если помеха не одиночная, а пачкой идёт - нифига мне в AT45DB642D записать без ошибок не удаётся. Как будто, кто-то рукой сеятеля FF там рассыпал. В смысле в буфере 1056 байт. Причем кол-во FF нарастает во времени. Те данные, которые я последними пишу почти не страдают. А первые все FF-ми покрыты. Хотя, конечно, последние данные - они самые важные.

Повторю и для Вас. Расскажите поподробней как использовать WDT в среде вытесняющей RTOS?

Схоласты занимаются некоторыми "проблемами" гораздо дольше, нежели Вы c Вашим "более чем 15-ти летним опытом". "Проблемы" не решены. За темой следить не вижу ни малейшего смысла.