[Don_Ambrosio 0]

Если не можете настоять на нужном камне при разработке железа, то будете всю жизнь мучаться :)

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

 

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

Вот вот

 

Но, я так понимаю, к Вам это не относится.

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

 

 

будете всю жизнь мучаться :)

Чуть-чуть пошевелить мозгами для Вас мучение? :07:

Ну не знаю, не знаю.. А для меня в кайф когда проблема сложная

[SapegoAL 0]

Вы точно не читаете то, что уже написано. Я же написал выше, что " понятие "сбой" гораздо шире понятия "зависание"". Из чего следует, что зависание - это частный случай сбоя и зависание далеко не исчерпывает все возможные виды сбоев

 

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

 

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

 

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

 

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

[Don_Ambrosio 0]

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

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

 

 

Причём понятно, что проц не сразу туда попадает, а с момента сбоя - попадает в ближайший цикл, который не может пройти.

 

Видете как просто?

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

 

попадает в ближайший цикл, который не может пройти.

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

 

 

Таймауты применяют при работе с внешним оборудованием

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

[SapegoAL 0]

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

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

 

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

 

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

[Don_Ambrosio 0]

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

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

 

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

[arttab 0]

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

 

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

 

например можно создать следующие темы:

- изменение PC внешним воздействием и как и нужно ли с этим бороться;

- сбой работы АЛУ .....;

- отказ АЛУ....;

- сбой чтения из flash;

- выход из строя ячеек flash.

 

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

 

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

[adc 0]

Странный ты.. Ну на тебе твою переделанную процедуру (хотя я же объяснял тебе выше как это сделать. Неужели для тебя это так сложно? :07: )

...

ldi R25 , high ( Border_Counter)

ldi R24 , low ( Border_Counter)

ReadLptEPP:

sbiw R25:R24 , 1

breq Crash

sbic pinc,LptSTB ; Строб пришёл?

rjmp ReadLptEPP ; иначе повторить

...

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

Предпочитаю использовать WDT + обязательный выход из цикла по переполнению описанный Вами.

[tyro 0]

1) Вероятность сбоя устройства равна 10 в минус 9 степени; вероятность того, что этот сбой система не обнаружит (не зарегистрирует) и соотвтетственно не предпримит ни каких мер равна 50%

2) Вероятность сбоя устройства равна 10 в минус 3 степени; вероятность того, что этот сбой система не обнаружит (не зарегистрирует) и соотвтетственно не предпримит ни каких мер равна 0,0000001%

 

И что более надёжно? "Надёжная" система, сбои которой просто не обнаруживаются

или "ненадёжная" система, у которой 99,99999999% сбоев обнаруживаются и предпринимаются соответствующие меры по устранению их последствий

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

[Don_Ambrosio 0]

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

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

 

 

Предпочитаю использовать 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 мы "улетаем" не пойми куда

 

 

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

 

В этой теме я рассматриваю только один вид сбоев: несанкционированное выполнение код во FLASH, вызванное аппаратным сбоем.

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

 

Среди основных причин этого сбоя можно назвать следующие:

1) Случайное изменение значение счётчика команд из-за помех

2) Случайное изменение содержимого в ячейке ОЗУ в области, где храниться таблица переходов

3) Случайное изменение ОЗУ стека или указателся стека, в результате чего после команд ret/reri мы "улетаем" не пойми куда

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

 

 

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

Изменено 13 февраля, 2008 пользователем Дон Амброзио

[Schtirlitz 0]

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

 

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

 

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

Для "гражданских" устройств 10 в минус 5 степени уже хорошо.

Изменено 13 февраля, 2008 пользователем Schtirlitz

[Don_Ambrosio 0]

Обсуждается Защита секции кода во FLASH. Вероятность сбоя устройства равна 10 в минус 9 степени - это вероятность сбоя устройства из-за сбоя программы ?

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

 

 

Вероятность сбоя устройства равна 10 в минус 9 степени - это вероятность сбоя устройства из-за сбоя программы ? На каком интервале определена эта вероятность ( на выполнение одной команды, времени жизни всего устройства)?

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

 

 

Сбой в программе отдельно взятого МК в системе приводит к 100% сбою системы

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

 

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

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

 

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

Для "гражданских" устройств 10 в минус 5 степени уже хорошо.

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

[adc 0]

В этой теме я рассматриваю только один вид сбоев: несанкционированное выполнение код во FLASH, вызванное аппаратным сбоем.

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

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

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

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

[galjoen 0]

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

Предпочитаю использовать WDT + обязательный выход из цикла по переполнению описанный Вами.

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

ldi R25 , high ( Border_Counter)

ldi R24 , low ( Border_Counter)

ReadLptEPP:

cpi R25, 1+high ( Border_Counter)

brcc Crash1

sbiw R25:R24 , 1

breq Crash2

sbic pinc,LptSTB ; Строб пришёл?

rjmp ReadLptEPP ; иначе повторить

...

В том посте я про 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 загрузить, пишу обычно так:

ldi YL,low(VarXX)

ldi YH,high(VarXX)

ld R16,Y

ldd R20,Y+4

eor R20,R16

cpse R20,RGFF

rjmp Crash

ldd R17,Y+1

ldd R20,Y+5

eor R20,R17

cpse R20,RGFF

rjmp Crash

...

А ещё хочу сказать, что все ожидания более 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-ми покрыты. Хотя, конечно, последние данные - они самые важные.

[Don_Ambrosio 0]

ИМХО для программиста достаточно встроенного WDT

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

[zltigo 0]

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

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