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

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

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

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

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


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

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



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




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

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

Сообщение отредактировал Дон Амброзио - May 7 2008, 06:43

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

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

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

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

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

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

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



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

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

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





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

Сообщение отредактировал Дон Амброзио - May 7 2008, 08:18

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

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




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

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

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

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




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

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

Сообщение отредактировал Дон Амброзио - May 7 2008, 08:31

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


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

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

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


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

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

Сообщение отредактировал Дон Амброзио - May 7 2008, 09:16

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

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