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

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

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. Отчего эта байда спасает реально?