Тогда давайте вообще от всех команд откажемся, они все потенциально опасные, все могут сделать что-нибудь нехорошее. Будем применять только NOP, поскольку это наш идеал


Сама тема не интересна. Как я уже писал, "искусство ради искусства", теоретические размышления, мало пригодные на практике. Просто иногда интересно почитать, что ещё могут придумать люди, которые тему принимают всерьез Именно тему, а не саму проблему в целом, которая важна. (Это не наезд, не обижайтесь )

Есть отдельно взятое мнение, что если тема не интересна то:
- не читать
- и уж точно не писать (сама умрет) ну и не засорять офтом - может кому тема и интересна (мне например интересно в позновательных целях)

Я тут вспомнил того мужика, который вторым на южный полюс пришёл. Пришёл, а там плакат висит "Добро пожаловать на южный полюс". Его тот, кто первым туда пришёл установил. Это я про то, что у всех потенциально опасных команд атмел старший бит =1 сделал.
А тут некоторые считают, что лучше он бы дома на диване сидел, и через интернет посты слал "не вижу смысла ходить на южный полюс".

+1

+1

А я предлагаю написать тем, кто что-то полезное для себя из темы для себя извлёк. Желательно с указанием автора и с комментариями. Но без критики. Думаю это всем полезно будет.
Вот я начинаю:

Буду делать.

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

Буду делать.

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

Хотя конечно отговаривать любителей экзотики (покорителей южного полюса) бесполезно. Делайте так как считаете нужным.

Согласен. Надо было написать так: у наиболее потенциально опасных.

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

Ну я же просил - без критики.

А вы, уважаемый 'defunct', что нибудь полезное из этой темы для себя извлекли? Если нет, то пожалуйста об этом не пишите. Тема и так за 200 постов перевалила.

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

Понимаете, большинство практикующих программистов (а не программистов теоретиков) сталкиваются ежедневно с определёнными трудностями. В том числе ошибки и сбои. Они могут оценить важность того или иного события, с практической точки зрения. Это проявляется при вылизывании любого законченного проекта имеющего мало мальски приличную серию. Например в одном из моих мелкосерийно(тысячи) выпускающемся приборе - было 118 версий и изменений. Каждая из которых выстрадана. Причём обнаружена одна существенная ошибка после начала серийного выпуска и куча мелких, незаметных для потребителя.
Таким образом вероятность мелкой ошибочки программиста которая проявляется при уникальном стечении входных данных или действий - во много раз выше, чем "вероятность случайного перехода во время сбоя на область данных где по дикому стечению обстоятельств сбрасывается WDT". Это вам скажет любой самый высококлассный программист. А исходя из того, что "чем сложнее и крупнее проект тем выше вероятность ошибки программиста" (что совершенно очевидно), то и получается такое обсуждение.
Люди не хотят обсуждать гипотетические ошибки, когда во много выше вероятность обычной привнесённой ошибки.
Это с одной стороны.
Теперь с другой.
Приведу пример из области оптимизации. Представьте, что у вас две процедуры. Одна вызывается 100 тыс раз за секунду, вторая - 10 раз. При оптимизации мы выиграли 1 такт на первой и 10 на второй. Сравните результат. Таким образом оптимизировать вторую процедуру просто не имеет смысла.
Так и здесь. Для того чтобы бороться с такими событиями как сбои, помехи и т.п., необходимо ПРОАНАЛИЗИРОВАТЬ ВЕРОЯТНОСТЬ И ТИП ТЕХ ИЛИ ИНЫХ СОБЫТИЙ. Причём сделать это надо в реальном изделии в реальном месте работы. Уверяю вас, - это можно реально сделать. И получить реальные результаты, на основании которых необходимо строить средства борьбы. Одно дело, если выяснится что с вероятностью 99% портится регистр данных, а другое дело - регистр комманд. Пока же мы рассуждаем о том, "чем лечить внеземной организм при заболевании".

Вот только что выяснил, что у меня не нулевая вероятность появления пакета защищённого 8-ми битным CRC. То есть проходит помеха (точнее идёт непрерывно) и может быть сформирована адрес сетевой + команда + CRC8. За год непрерывной работы на 5 изделиях такое произошло 2 раза. Но борьба будет аппаратной поставлю резисторы подпорки (растяжки) и терминаторы, чтобы отсечь маломощные помехи. Если это не решит проблему, то буду менять протокол.

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

В свете данного обсуждения- имеются ли практические цифры, говорящие о вероятности сбоя (изменения) конкретной ячейки ОЗУ?

В устройстве имеется набор параметров, (констант) защищенных CRC и хранящихся в EEPROM, в начале работы параметры загружаются в ОЗУ. Имеет ли смысл в процессе работы если не загестрировано сброса подгружать их периодически?

Это обсуждалось в другой ветке "тестирование регистров". Я считаю что ответ - "нет".

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

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

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

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

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

Сообщение отредактировал Baser - Feb 21 2008, 21:05

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

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

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

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

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

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

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

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

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

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

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