Защита секция кода во FLASH в ATmega, Как защититься от несанкционированного выполнения кода Опции

[galjoen]

да, пользуем все это.

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

[_Pasha]

А Вы думаете что раз они находяться на одной плате и питаються от одного источника, то они непременно ОБА сглюканут ОДНОВРЕМЕННО и причём у обоих будет ОДИН И ТОТ ЖЕ глюк?

Ну есть же причинно-следственные связи - качество питания, состояние линии связи, условия, в т.ч. и ЭМС...

[zltigo]

Что особенно полезно, когда оба девайса находятся рядом или питаются от одного питальника.

Что-то я не понял реплики. В данном отисанном случае они могут вполне питаться от одного питания, ресетчика, генератора,....., ибо объявлена "священная война" с тем, что управляющий девайс соврет о том, что он сделал.

[Дон Амброзио]

Ну есть же причинно-следственные связи - качество питания, состояние линии связи, условия, в т.ч. и ЭМС...

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

[_Pasha]

ибо объявлена "священная война" с тем, что управляющий девайс соврет о том, что он сделал.

Тогда для мажоритара не хватает еще одного наблюдателя.

[Rst7]

Надёжность программы - это свойство программы выполнять свои функции в условиях "помех" (некорректные данные и сигналы, поступающие извне, случайные изменения ячеек ОЗУ, FLASH, случайные JMP и CALL, вызванные воздействием помехонесущих полей на внутренние микроконтроллера и т.д.)

А вот академическая наука под "надежностью программ" понимает совсем другое:

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

Видите разницу? Я - огромную. Причем, в методологии.

[Dog Pawlowa]

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

А такой протокол вызывает уважение, конечно же?

[Kuzmi4]

Может не совсем по теме - но всё же - мне кажется что уже 2-я тема очень смахивает на флуд:

Флуд - это поток сообщений, не несущих почти никакой смысловой нагрузки. Это такие сообщения, которые можно было бы безболезненно удалить (а точнее, не писать) без всякого ущерба для собщества. Обычно флудят пользователи, которым по большому счету нечего сказать, но которые хотят привлечь к себе внимание. (http://www.teenclub.ru/index.php?e=314)

Может пора это прекращать ?

[Дон Амброзио]

Видите разницу? Я - огромную. Причем, в методологии.

Вы имеете ввиду слова:
"а также неполным описанием условий применения алгоритмов, реализуемых ПО"

Да?

Если да, то кто по-Вашему должен описывать эти условия?

Если нет, то тогда в каких словах, по-Вашему, заключена "огромная разница в методологии"

Может не совсем по теме - но всё же - мне кажется что уже 2-я тема очень смахивает на флуд:

Флуд - это поток сообщений, не несущих почти никакой смысловой нагрузки. Это такие сообщения, которые можно было бы безболезненно удалить (а точнее, не писать) без всякого ущерба для собщества. Обычно флудят пользователи, которым по большому счету нечего сказать, но которые хотят привлечь к себе внимание. (http://www.teenclub.ru/index.php?e=314)

Может пора это прекращать ?

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

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

[zltigo]

Тогда для мажоритара не хватает еще одного наблюдателя.

Читаем внимательно - не стоит задача получит от ЭТОГО механизма правильное управление (получить нечетное число команд и выполнить те, которых больше), задача убедиться в том, что команду выполнили. Достоверность собственно команды совершено спокойно достигается, например, ее ПОСЛЕДОВАТЕЛЬНОЙ посылкой 9999 раз с последовательным мажоритированием, накоплением статиcтики сбоев принятия команды и так далеее. Задача независимого подтверждения ПРАВИЛЬНОСТИ решается одним "контролером". Тем не менее о наращивание "контролеров" я тоже писал.

[Rst7]

Вы имеете ввиду слова:

Я имею в виду все процитированные слова.

мне кажется что уже 2-я тема очень смахивает на флуд

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

[demaven]

У меня сейчас на столе лежит устройство, унутри которого находятся три счетчика импульсов на разных контроллерах, каждый со своим питанием (идентичных), каждый из которых получает время извне (синхронизируется то бишь) и педерает, тьфу, передает кол-во импульсов посчитанных им на сервер. Так оне разбегаются хто куда, хотя источник импульсов ОДИН на все контроллеры. Понятно, у каждого контроллера свой "жизненный цикл", свои заморочки, но ипульсы они считают по прерыванию, вроде много пропускать не должны. Но разбег за сутки составляет более 0.2%, если нет внешних воздействий типа дерганья питания. А допустимое расхождение - не более 0.05% (по желанию заказчика). Частота кварца 4 мегагерца, частота импульсов нестабильная, от 0.1 до 3 герц. Разбег считаю через 10 минут после прекращения подачи импульсов, так как передача на сервер идет раз в пять минут. Устройства не зависают и не глючат, все работает как положено, но разбег есть!!!

[Дон Амброзио]

Я имею в виду все процитированные слова.

Наверное я тупой. Не могли бы Вы мне "разжевать" в чём приницпиальная разница?

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

Господа, господа... Позвольте.. Где это я сказал хоть одно слово, о том, что не нужно впервую очередь бороться с причиной сбоев и обеспечения впервую очередь надёжного железа? Зачем же свои домыслы по поводу моей "неправильной методологии" подавать так, как будто это и на самом деле так? Ой как некрасиво. Я всегда считал, что решение задачи надёжности системы нужно начинать на самых ранних этапах: разработка идеологии и схемотехники устройства. Затем на этапе конструкторско-технологическог прокетирования. И уж потом на стадии разработки программы

Сообщение отредактировал zltigo - Feb 18 2008, 13:11

[zltigo]

У меня сейчас на столе лежит...

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

Moderator:
Еще одно сообщение попугаистой расцветки без всякой на то надобности и буду их удалять. Рекомендую правила почитать.

[Rst7]

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

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

2 zltigo - ну хоть Вы меня поддержите, а? В этом вопросе вроде наши мнения должны совпадать ))