Проведите испытания на ЭМС согласно стандарту. Будете приятно удивлены. Судя по цифрам какие-либо меры противодействия помехам отсутствуют начисто.

А вообще, если не секрет, где Вы работаете и что это за устройства?

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


Все причины низкой надёжности программы можно разделить на 3 класса:
1. Ошибки и недочёты при разработке алгоритма (например, не учли в алгоритме возможность случайного джампа на процедуру записи во FLASH). Эти ошибки вызваны недостаточным пониманием архитектуры MCU, для которого пишется программа и не понимание как ведёт себя этот MCU в условиях внешних воздействий
2. Ошибки и недочёты на этапе кодирования алгоритма на том или ином языке (например вместо команды CBR написали SBR в случае написания программы на ассемблере
3. Ошибки в программных инструментах, использованных при разработке Вашей программы (например глюк компилятора) или неправильное использование программных инструментов, вызванное не пониманием того, для чего они предназначены и как они работают

Непонятно... И что - в линию связи не говорит, мол "чувак, не могу, болею" ?

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

На К ВЫХОДАМ девайса подключен контролирующий девайс отсылающий в дополнение к рапорту управляющего девайса в линию связи свое видение выданного управляющим девайсом выходного воздействия. Все. Максимальная степень достоверности. Возможно легкое дальнейшее повышение степени достоверности наращиванием числа контролирующих девайсов. Возможно упрощение системы, когда контролирующего девайса нет, но есть контролирующий процесс, который перехватывает ображения уже непостедственно к исполнительном железу, и уже он отправляет рапорт о состоянии.
То, что изложено автором напоминает ответ на вопрос "кто шил костюм" - "к пуговицам претензии есть?"
"Вы исполнили команду?" - "Перед тем, как мы попытались выполнить присланную команду претензий к исполнению команд JUMP контроллером не было".

Ну люблю-люблю я извращения!
Как вам мой 2й вариант замены call на следующую последовательность команд:
ldi R16,low(mRet) ; только в случае call - для jmp не ставим
push R16 ; только в случае call - для jmp не ставим
ldi R16,high(mRet) ; только в случае call - для jmp не ставим
push R16 ; только в случае call - для jmp не ставим
ldi R16,low(mCall)
push R16
ldi R16,high(mCall)
push R16
ret ; Это вместо call - тапереча так будет. jmp заменить проще - 4 первых команды выкидываются.
mRet:
....
mCall:
...
ret
Это вообще и в асм(.macro) и в С(#define) запросто включается!
А где тут патенты-то выдают, вы говорите?

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

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

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

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

Вот я и говорю - "к пуговицам претензии есть?" А на вопрос "кто шил костюм" или кто проектировал СИСТЕМУ ответов не будет.

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

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

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

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

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

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


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

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

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

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

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

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

Да?

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

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



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

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

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

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



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

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

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


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

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




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

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

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

Сказали и не только сказали, но цифры привели о том как может хреново спроектированная система работать. Все, так сказать описали, только выводов для себя не сделали НИКАКИХ - продолжаете трясти пальму.

Ну просветите меня может я заблуждаюсь. Что же такое по вашему надёжность ПО? И что такое надёжность железа? Только не надо отсылать к диплому по распределённой ОСРВ.

P.S. про уклонистов и "четатилей" давайте не будем лучше.

Поскольку обсуждение темы (не имеющее, к слову сакзать, полезного результата) плавно переходит в банальный флуд, а точнее троллинг со стороны пользователя Дон Амброзио, последний переведён в режим read only на неделю для внимательного ознакомления с правилами.

И Вы всерьез считаете что таким образом повысили устойчивость программы от
случайных jump ?
Ну тогда подумайте что будет если произойдет случайный jump куда-нить между push...

Все давно уже украдено придумано до Вас...
На досуге почитайте AVR Instruction Set,
особенно обратите внимание на инструкции ijmp и icall

Вы...это...мыслю - то попинайте немного.

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

Про тот где избавление от LDS/STS описано.

Всерьёз

Это тоже серьёзно

Я ijmp и icall уже кто-нить запатентовал? Если нет, то я побежал патентовать.

А тут я отвечу так:

Это взято мной из другой темы. Там один чел хотел запрограммировать ОУ так, чтобы робот умно препятствия обходить стал. Так ему отвечали, что этот ОУ запрограммировать невозможно. Надо-бы поставить другой ОУ - программируемый.

А теперь серьёзно.
Насчёт STS/LDS - атмел похоже уже всё придумал до нас. Заглянул я тут в AVR Instruction Set, как мне и советовали. И сейчас один очень умный вещь скажу: если у АВР внешнего ОЗУ нет (а в 90% применений это так), то LDS/STS инструкции ничего опасного содержать не могут. Т.к. первые 4 бита адреса =0 будут! Там могу содержаться такие инструкции как: fmul, muls, movw, cpc, sbc, add, nop. В общем я ни одной потенциально опасной инструкции не нашёл!!! Это что совпадение??? Или м.б. кто то что то найдёт. По крайней мере в AVR Instruction Set заглянет. Иногда надо знания освежить!

Понятно что можно обойтись без LDS/STS, только ограничений у такого подхода много.
Только 64 байта под переменные, а если нужно больше ?
"Намертво" забитая под это дело регистровая пара, а их всегда так мало.
Невозможность одновременно работать с 3 источниками/приемниками данных с автоинкрементом.
и т.д.

Вобще можно без многого обойтись...
Вопрос в целесообразности.

Если для реализации предложенных подходов нужно будет задействовать
контроллер в 2-3раза более мощный с 2-3 раза большим флеш,
если для написания и отладки такой программы потребуется раз в 5 больше времени...,
значительно более дешевым и надежным будет просто аппаратное дублирование
с относительно простыми, требующими существенно меньше времени на отладку, алгоритмами.


Я Вас еще немного поогорчаю, ладно ?
Раз уж посмотрели Instruction Set, загляните еще и в даташит например на mega64/128,
ну и постарайтесь найти с какого по какой адрес у них расположена SRAM...

Ну а потом еще гляньте даташиты на 640/1280..... это у которых 8Kb SRAM.

Я действительно огорчился т.к. решил, что вы Instruction Set не посмотрели. А я-то надеялся, что посмотрите. Я там ни одной потенциально опасной команда со старшим битом =0 не нашёл. Т.е. опасность начинается с адреса 0x8000 и до 0xFFFF. Ни у одного АВР встроенного ОЗУ там нет. Хотя не уверен конечно - может какую то команду я пропустил. Поэтому других, и вас в том числе посмотреть просил.

Про 4 старших бита это я специально написал. Проверить хотел - будет-ли кто действительно Instruction Set смотреть. Никто и не подумал! Иначе написал бы. Т.к. не заметить, что все потенциально опасные команды старший бит =1 имеют не мог. Или нашел-бы какую-то опасную команду со старшим битом =0. Поэтому я действительно огорчился. Т.к. понял, что просто флудим мы тут. И ничего полезного в этом нет. Это я безо всякой иронии или злорадства говорю.

Ну и в какую ж... даль мы улетим если значения в регистрах rrrrr и ddddd совпадут ?

Так эта тема о чём! О том, что куда бы мы не улетели, там-бы мы ничего плохого-то не наделали! Сам-то улёт мы отменить не можем. Регистр перед ijmp собъётся, данные в ОЗУ перед ret, ук-ль стека, PC ... Мы тут пишем о том, как последствия этого улёта минимальными сделать. Хотя-бы по теории вероятности минимальными. Т.е. говоря вашими словами: в какую ж... даль мы-бы не улетели - мы там в ж... не попадём! А это возможно, только если во всей программе ни одной потенциально опасной команды (в т.ч. и во вторых словах двухсловных команд и в таблицах) не будет. А потенциально опасными командами можно считать те, которые зацикливают (могут на wdr зациклить), в регистры пишут (например в порты), или в ОЗУ в то место где реально регистры могут оказаться (запись собственно в ОЗУ безопасна). И мы пришли к выводу, что полностью от этого избавится невозможно. Можно только риск уменьшить. Например, при правильном написании программы, риск того, что командой spm мы FLASH при случайном прыжке сотрём меньше, чем вероятность случайного совпадения CRC16 (см. мой пост). А кол-во таких команд типа: st(std) X(Y или Z),Rxx поменьше надо делать, т.к. состояние X, Y или Z в этом случае неизвестно - могут в порт что-нибудь такое выдать. И размер кода перед ними, переход на который к их выполнению приведёт - тоже уменьшать надо. А вот команда STS в ОЗУ, как я показал, безопасная. Т.к. сама в регистр записать ничего не может, а второе слово у неё со старшим битом =0. Там тоже опасной команды не может быть. Это же к LDS относится. Так-же получается, что все jmp и call в адреса от 0 до 0x7FFF - безопасные! С точки зрения 2го слова конечно. Опасность команды OUT от адреса в ней зависит. И т.д....

Пишу и думаю: всё это ещё кому нибудь интересно или нет? Я-то ко всему этому интерес стремительно теряю, т.к. все во флуд превращается. Все и саму тему-то уже давно забыли.

Я то с вами согласен.
Тема становится скучной...


+1


Отменить "что-то" плохое мы можем ровно также как и отменить улёт, т.к. программа после улёта уже находится в неконтроллируемом/неуправляемом состоянии.
Выход один - перезапуск.


Да конечно же нет. Ну есть возможность "призрачно" обезопасить код от "неизвестных" инструкций, да только зачем это делать?! Зачем терять в производительности на всю эту чушь, если можно выделить лишь критические пункты - те от которых действительно нужна защита (от которых зависит функционирование комлекса):
- запрещенные комбинации упр. сигналов (сигналы "вкл" и "откл" одновременно)
- отказ интерфейса(ов) связи.
- останов RTC
- слет eeprom
- слет флеш
и т.п.

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

Согласен. С точки зрения практика (а я практик) именно так всё и есть.
А попробовал я тут теоретиком заделаться. И что получилось? Оказывается обо всём том, что мы тут откровением считали, атмел давным-давно позаботился. А мы пользуемся. Видимо в атмеле теоретики-то давно уже "абстракную вероятность повышения надежности" подсчитали. И мы лучше них не сделаем. Говорю так, т.к. не верю в случайность того, что у всех потенциально опасных команд старший бит =0 оказался. Из-за этого ведь все реально встречающиеся двухсловные команды безопасными стали. Вероятность того, что это случайность (0ю гипотезу) я в менее 0.5% оцениваю. А может я и ошибаюсь т.к. с вероятностями давным-давно не работал. Или ещё где-то ошибка есть. Но в любом случае вывод из всего этого один - каждый должен заниматься своим делом. А исключения из этого хобби называются.

Мне одно непонятно:
Что имелось ввиду ледибагами, когда они вот эту дисциплинку ввели по записи в особо ответственные регистры типа: SPMCR и обязательно в 4 такта SPM. Отчего эта байда спасает реально?

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


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

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

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

+1

+1

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

Буду делать.

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

Буду делать.

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

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

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

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

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

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

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

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

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

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

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

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

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