Никаких практических величин вероятности у меня нет, но я параметры из EEPROM все-таки периодически подгружаю, каждые 10 сек.

Соображения тут следующие: Энергия помехи, необходимая для изменения ОЗУ, на несколько порядков меньше, чем необходимая для изменения EEPROM. Соответственно и вероятность порчи ОЗУ значительно выше. Параметры из eeprom являются константами и не изменяются в процессе работы. Все другие переменные в ОЗУ меняются несравнимо чаще, чуть-ли не все время. А чем больше время "жизни" значения в ОЗУ, тем больше вероятность его сбоя. Причем большая часть алгоритмов МК циклические, поэтому порча содержимого обычной переменной чаще всего нивелируется последующими циклами, а порча константы может изменить поведение прибора на длительное время.

Другой вариант - проверять CRC констант и в ОЗУ, и подгружать только когда есть ошибки.

Все это, конечно, чистая эмпирика, но это из той области приемов, которые я всегда применяю, в отличие от тестирования регистров и АЛУ

p.s. Забыл уточнить, речь идет о внешней EEPROM, из внутренней копии в ОЗУ обычно не делаю, читаю напрямую.

Тут - кто как себе разгоняет.

Самый эффективный способ вызвать сбой - весьма прост.
1) Подключите ваше устройство ч/з не стационарный блок питания. Например ч/з свой.
2) Воткните этот БП в тройник.
3) Паралельно ему воткните устройство мощностью не менее 1.5кВт с индуктивной нагрузкой.
4) Поискрите этим устройством часа три. (В зависимости от качества БП и разводки, первые сбои пойдут через 1 - 10 мин)

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

Попробуйте проделать операцию с двумя вариантами программы, - получите статистику сбоев.

Если устройство намертво повисло, то значит - шляпа.

А если не зависло, то это ещё не означает, что сбоя нет

Ибо могло пройти искажение инфы в ОЗУ от помехи.
Как напрямую, в рузультате воздействия на ячейку или шину адреса/данных во время записи,
так и косвенно, например, в результате случайного джампа выполнится код, который не должен бы выполняться, и это код запишет в ОЗУ не то, что нужно.. Получиться дезинформация, т.е. деза

Чтобы в случае случайного джампа в область данных из-за помехи не произошло ничего плохого

Это вопрос ради вопроса? При "случайном" джампе все плохое уже случилось.

Встречный вопрос: а в каком виде писать программу, чтобы в случае "случайного" джампа в любую ее область не происходило ничего страшного?

Страдаете фобией?
Совет: не берите в голову. Эта проблема надумана. В жизни такого явления практически вообще не бывает. Как минимум, у меня -- ни разу такого не было. У моих знакомых -- тоже.

Просто подумайте, если такая помеха действительно существует и способна исказить работу ядра МК, то что можно говорить вообще о работе устройства в целом? -- Правильно! Само по себе устройство очень плохо спроектировано: не правильно разведено питание, отсутствуют кондеры, чувствительные элементы не экранированы, полигон под чипом отсутствует, и т.д.

to дон: ваша же тема? Где-то там вы, помнится, приводили пример с "безопасными" таблицами CRC... Или с того времени что-то изменилось?

nop
---
---
nop
От начала до конца .

Из-за того, что админ заблокировал мне возможность отвечать в разделе "Общение - OFF topics" отвечу здесь. так как эта тема близка к этой http://electronix.ru/forum/index.php?showtopic=47394.


Почитайте эту тему и найдёте ответ на свой вопрос. В любом случае в программе можно предпринять меры по уменьшению неприятных последствий случайных джампов.

А если у Вас в ATmega128 4кБ кода и 124кБ данных с ПРОИЗВОЛЬНЫМ содержимым, то даже по теории вероятности "прыжок" в область данных в 31 раз более вероятен. И тем более в таком большом массиве данных бОльшая вероятность выполнения потенциально опасных операций



Вы не правы. Если у меня в программе всего одна команда sbi Porte , 6 включающая реле подрыва атомной бомбы, а в 124 кБ данных, хранимых "так как есть" таких команд может набраться несколько сотен, то разве не возрастает вероятность несанкционированного подрыва атомной бомбы в несколько сотен раз?




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

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

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

И кстати еще вопрос к Вам: почему вам не дают покоя именно случайные джампы? А если мк в результате сбоя исказит команду? Т.е. у вас есть какая-то статистика возможных сбоев мк и случайные джампы там на первом месте?

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

Я бы сказал -это не реально вообще. Это всё равно , что на данный процессор , вешать ещё один процессор , что бы он контролировал основной процессор , но и этот процессор , тоже надо контролировать - вдруг как прыгнет.

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

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

Да ладно Вам.. Уж чего-чего, а памяти в современных MCU "как грязи"... В смысле хватает... Вот у меня например часто используется ATmega128. Там 128 килоБайт памяти.. Так вот.. Я никогда не использовал больше 8 кБ. Даже самые сложные проги вместе с RTOS умещались у меня в 8кБ



Ну плохим танцорам-программистам всегда что-то мешает...

А насчёт мажоритарного голосования я в курсе.. Но это в разы увеличивает стоимость изделия..
А для ширпотреба это означает, что твои изделия никто не будет покупать. Пусть они в 100 раз надёжней, но и дороже же в 4 раза своих аналогов... А мои изделия относяться к категории ширпотреба... В которых надёжность желательна (ибо хоть они и не атомную бомбу подрывают, но неприятности в случаи некорректной работы устройства будут весьма серьёзные), но не настолько, чтобы потребитель переплачивал за неё в 3-10 раз..

Поэтому приходиться искать дополнительные методы увеличения надёжности БЕЗ УДОРОЖАНИЯ ИЗДЕЛИЯ





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

вот с этого и надо было начинать

Тут два варианта - либо вы гений и сложнейшие проги умещаете в 8 кб, либо у вас пока не было соответствующих задач




Так не получится. Вам потребуются более опытные (и дорогие) программисты. Модификация программы будет стоить в разы дороже и занимать больше времени и т.д.

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

Я это уже и писал:
А мои изделия относяться к категории ширпотреба... В которых надёжность желательна (ибо хоть они и не атомную бомбу подрывают, но неприятности в случаи некорректной работы устройства будут весьма серьёзные), но не настолько, чтобы потребитель переплачивал за неё в 3-10 раз..

А если Вы приобретаете устройство для управления сантехникой дома и Вас дилемма: взять за 1 килобакс устройство, которое может залить, а может и не залить примерно эдак раз в 5 лет Вашу квартиру водой в результате самопроизвольного открытия крана. Или взять за 5 килобаксов устройство, которое может залить Вашу квартиру с той же вероятностью раз в 50 лет...Что возьмёте? Затопление квартиры вещь конечно не смертельная, но неприятная.




Вы наверное ещё молоды раз не помните, что была такая операционная система для компьютера. DOS называлась... Ну так вот.. Её размер был 12 кБ... Мои программы конечно попроще, но тем не менее RTOS там есть..

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

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


Помнится, на системную дискету было напихано где-то под мегабайт... С учетом того, что даже порезанная фат под МК весит порядка нескольких кил, что собственно входило в эти 12к?

Почему? Т.е. просто немного "подправить" код Вы считаете по деньгам дороже выйдет чем разрабатывать и покупать элементную базу для железа к примеру с трёхкратным резервированием

Приведу конкретный пример. В большой партии устройств в среднем проиходит одно ложное срабатывание в год на одно устройство. Если применить троирование, то можно уменьшить вероятность ложного срабатывания до 1-го ложного срабатывания в 10000 лет. Но при этом цена устройства возрастает в 5 раз.
Также можно уменьшить вероятность ложного срабатывания до 1-го ложного срабатывания в 10 лет за счёт "программных методов". Цена изделия при этом не возрастает. В среднем 1 ложняк за 10 лет вполне устраивает потребителся.. А удоражание стоимости изделия в 5 раз не устраивает настолько, что он просто откажется покупать Ваше изделие.. И кому тогда будет нужна Ваша супернадёжная система за такие бабки?Что тогда Вы выберете? Всё равно побрезгуете воспользоваться увеличением надёжности за счёт лучшей проработки программы?


Я имею ввиду "до дискетные" версии ОС, когда операционка была зашита а ПЗУ..

А компьютеры Синклер, ZX-Spectrum тоже не помните?

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

Для этого проводятся испытания устройств на ЭМС и по ее результатам принимается решение о соответствии изделия ГОСТам, ОСТам.

Ну кроме ЭМСа есть ещё много чего другого, например доказательство безопасности ....где вот и приходится рассказывать про битые регистры, ОЗУ, неожиданные джампы в область флэша...и как от этого безобразия защититься....

Тем более, что я объяснял выше почему "не было". Потому что он и его "знакомые" просто не имели инструментов для наблюдения таких случайных джампов и отличить их от других типов "глюков" программы.

Вот я , например, не вижу атомы. И что? Значит их не существует?



То что изделие прошло испытания на ЭМС ещё совсем не говорит о том, что в нём полностью исключена возможность случайного джампа из-за помехи в процессе долговременной эксплуатации.. Согласны?

Другие, в отличии от Вас, видимо профессионально занимаются проектированием устройств от и до. И, видимо, более профессионально умеют писать софт для этих устройств. Посему у них программы не глючат. Вот и все.

Странный, не логичный вывод какой-то.. Не находите? Больше похож на "наезд". Или мне показалось?

Я просто сказал, что они не наблюдали явление случайных джампов, потому что не имели инструментов для их наблюдения и не имели желания их увидеть. А Вы сразу "в отличии от Вас" и прочее...

А насчёт "не глючат" есть 2 аксиомы программирования(которые подтверждаются более чем 50-ти летней историей программирования):
1. Программ без ошибок не бывает. Бывают программы без обнаруженных ошибок.
2. Каждый найденный последний программный баг является предпоследним

Не показалось.



Весь этот бред придуман теми, кто пытается оправдать собственную импотенцию в плане разработки правильных устройств/софта и т.д. мифическими "глюками", "фазами Луны", "биополями" и т.д.

С наездами добро пожаловать сюда Моя веб-страница

Там я смогу высказать Вам всё что я о Вас думаю без всякой цензуры и купюр.. Впрочем как и Вы сможете сделать то же самое




Только начинающий программист (проще говоря ЛАМЕР) или человек, не имеющий никакого отношения к программированию(не Ваш случай?) может утверждать, что в программе достаточно большого объёма он не допустил ни одной ошибки или говорить о том, что "настоящие профессионалы" пишут программы без ошибок


Ведь известно, что даже опытнейшие программисты с 30-ти летним опытом работы тоже допускают ошибки, на вероятность которых, кстати, "фазы луны" влияют не в малой степени

Не поделитесь инструментарием. Очень хочется понаблюдать.

В этой теме где-то я уже описывал как "засекал" случайные джампы... Ключевые слова "загорается светодиод".... Поиском, надеюсь, умеете пользоваться?

А с чего вы взяли что сбивалось ОЗУ или регистровая память? Вы уверены что МК вообще работал? Как вы проверяли что PC перегружается каждый такт?

Уверен. Потому что я в ISR системного таймера каждую секунду моргал светодиодом...

А вообще Вы вопросы такие...гм.. задаёте.. Вы что же? Думаете я ламер?



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

Да, но в приводимом вами примере вы не упоминали что у вас там ещё прерывания работают.
Можно посмотреть на всю вашу программу(лучше наверное аттачем)?


А вы у меня кажется что-то про поиск спрашивали? Я просто вопрос задал, мне интересно!


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

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

Без этой методологии - "радиолюбительство", а не разработка (блин, не в День Радио будет сказано )



Встречал я таких клоунов... Клоуны не потому, что ошибаются (все мы люди), а потому, что свои ошибки исправить не то что не хотят, просто не могут (именно та самая умственная импотенция, не могут даже понять, где грабли разложили, вот и списывают на "фазы Луны"). Больше, правда, хорошо что заочно с такими встречался - в виде устройств, которые даже на столе работают со сбоями (очень блин Вас напоминает, Вы тут где-то утверждали, что нужно даже, чтобы устройство больше сбоило). Что же с ними будет, когда их на объекты ставят?




Более того, мы принимаем это как аксиому!

Последние три страницы - никакого конструктива, пора закрывать.