Не успеем - там 4 такта всего. А две проверки по 1 такту и два brne тоже по 1 такту =4 такта.
Можно только добавить ещё один sbrc перед самим spm, и этим уменьшить вероятность ещё в 2 раза.

Вообще-то вероятность абсолютно такая-же, как и у того, что в один регистр будет записано какое-то определённое число.

+1
А я вообще считаю, что для АВР смысла нет на C писать. В программах управления чем-либо (ИМХО АВР только в таких применениях с АРМ конкурентоспособен) переносимости это не добавит т.к. всё к регистрам ввода-вывода привязано. Как встроенные функции C (сделанные такими для переносимости) например с USART работают - знаете. Неужели кого-то они устраивают! Всё равно нормальные люди сами пишут. Ну и где после этого переносимость?

Подскажите, пожалуйста, как Вы определили, что сбился PC, а не R16?

PC - это священная корова!!!

Ну ещё мог сбиться бит Z из регистра SREG. Для проверки чисто сбоя PC всего 1 команда нужна rjmp сам на себя. Собака есно при этом запрещена д.б.
Но это ничего не меняет. Если предположить, что это R16 сбивался, то сбой регистра R30=ZL или R31=ZH перед ijmp или icall к тем-же результатам приведёт, что и сбой PC. Как и сбой в ОЗУ перед командой ret. Или сбой указателя стека.
Я считаю, что тема эта гораздо шире стала, чем просто сбои PC. Тут защита от сбоев вообще рассматривается. Неправильно написал. Д.б. так - минимизация последствий аппаратных сбоев. Или минимизация вероятности того, что аппаратный сбой тяжелый урон нанесёт.
Да, ещё добавить забыл, что АВР всего-лишь как пример рассматриваю. Так сказать - виртуальный микроконтроллер.

0. Перестаете думать, как работать со сбоящим дерьмом, так, чтобы скрыть от пользователей, что они имеют дело с дерьмом.
Ознакамливаетесь c приложением. По результатам ознакомления возможны два варианта
1. Привлекаете фирму Atmel за выпуск сбоящего дерьма не соответсвующего заявленным характеристикам.
2. Собираетесь с умом и думаете о том, как вам удалось создать сбоящее дерьмо.

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

А обеспечить отсутствие последствий сбоев чисто программными методами невозможно. Гораздо дешевле и надежней аппаратные средства (внешние и внутренние блокировки).

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

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

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


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

А какие проблемы бывают на объектах здесь могут многие рассказать. Так что тема актуальна.

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

+1000
Очень помогает.

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

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

Я отчетливо понимаю, что есть области, где необходим такой подход, как описываете вы. Но их сравнительно немного...




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



offtopic
Кстати, что это за фольклорный персонаж "Дохтур туамосец" - тут его пару раз упоминали. Гугл выдал только пару ссылок на телесисы...

Пока народ разогрет всем этим бредом... прошу отнестись серьезно к тому, что я хочу сказать.
Хочу детально проработать вопрос по spm и целостности флеша, для чего сваять простенькую модель:


*) 0xFFFF вариант для меги 64. Для более мелких - надо учесть размер шины адреса

Методика:
1. забили весь флеш, чтобы 0xFF было минимум.
2. Запомнили CRC
3. ставим эту байду на несколько часов
4. Отвечаем 2 defunct

ВОПРОС О СОСТОЯТЕЛЬНОСТИ МОДЕЛИ:
покакит ли это все с псевдослучайными числами с нормальным распределением?
Очень жду комментариев.

Устойства "сглюкивающие" раз в день не имею права на существование в принципе. Должна-же быть какая-то нижняя планка качества. Ни одно из микроконтроллерных устройств работающих в нормальной для контроллера среде не должно глючить, чаще, чем наработка на отказ отнормированная производителем. Если указанные условия не приемлимы, или не приемлимо вообще само слово отказ, то эта проблема решается совершенно другими способами. Высасывание из пальца одной из множества гипотетически возможных причин сбоя и мужественная борьба с ней софтовыми методами с принесением в жертву качества, надежности и сопровождаемости кода совершенное умопомрачение.
Тут поминалась Ядерная Энергетика? Так получилось, что я с ней сталкивался. Ядерный реактор это именно тот случай, когда последствий от отказов быть не должно. Подчеркиваю - последствий а не отказов, кои нормируются. Сделать это тяжело и безумно дорого. Что касается софта, то написанного в рекламируемом здесь стиле софта там не будет близко и на пушечный выстел. Причина проста - софт должен быть верифицирован, как минимум по формальным признакам - написан с использованием инструментальных средств минимизирующих вероятность ошибки человека, в конструкциях языка не должны быть использованы выражения могущие вызывать потенциальные неоднозначности, данные должныбыть четко структурированы, инструментальные средства должны быть в свою очередь проверены временем и достаточно консервативны, разработчики софта должны, извините, соответствовать определенному образовательному цензу...

При всем этом совершено очевидным является тот факт, что устройство может не выполнить свою функцию в нужный момент времени. Посему резервирование прежде всего. неезервированных вещей на энергоблоке всего несколько, практически корпус реактора и кусок трубы с клапанами до насосов и прочего уже резервированного оборудования. Это нерезервированное оборудование и является основным ноухау, стоит сумашедших денег, защищается от внешних воздействий а внешняя среда защищается от него...
Со всем остальным проще - собирается почти по месту насосы можно взять на Украине, двигатели к ним во Франции, систему управления в Германии.... На уникальное оборудование никто старается не закладываться. Только вот резервировние там не шуточное. Например (намеренно подальше от электроники, дабы избежать скатывания в часности), для работы реактора в штатных режимах достаточно одного Главного Циркуляционного Насоса. Во всех нештатных - двух. Там их четыре. Три работают всегда, один стоит в холодном резерве, на регламентном обслуживании.... Двигатели насосов надо питать - начинаем резервировать электропитание - к энергоблоку подходят две линии электропередач от других электростанций (это не считая соседних своих энергоблоков), при каждом энергоблоке три собственных аварийных дизельгенератора (размером с дом), но для останова реактора хватит одного. Если все это хозяйство вдруг отказало, то снаружи энергоблока есть штепсель для подключения предвижного дизельгенератора, которого хватит на питание РЩУ и заглушение реактора. Если вдруг соляку из всех подвижных слили , то на ГЦНах стоят многодесятитоные маховики - совсем уже реактор не расплавится даже при сверхаварийном останове. А если расплавится, то он стоит в Гермозоне, которая в свою очередь расплавившись стечет на 27 метров вниз в выложенный керамикой бассейн и будет там доооолго кипеть.

Да и в простой промышленности, при управлении станком, к примеру, - надо быть очень убедительным, чтобы навязать свой уникальный контроллер. Пожалуйста применяй готовый - сименс/ митсубиши...

И это правильно, - поставьте себя на место директора. Людей и поставщиков тоже надо резервировать. На одного сложно полагаться.

С другой стороны, совершенно не понимаю разговоров об одном глюке в день, к примеру. Мы несколько изделий в телефонии делали. Как понимаете там круглосуточное использование. Одно из самых первых при отсутствии опыта делали на х51. И WDT не ставили. Там по-моему просто не было его, а внешний ставить - тогда недоставаемо было. Как-то раз, недавно, столкнулся с одним своим изделием. Ужасающее состояние, - весь покрыт пылью - валяется среди хлама (во включенном состоянии). Люди забыли что он у них есть. Он просто выполняет свои ф-ции и всё. Люди не задумываются как и кто это делает. Они просто привыкли что это работает. Ну я поинтересовался (вы же понимаете меня это очень интересовало), - спрашиваю а висы у вас били? Смотрят на меня - не понимают о чём я говорю. Ну я спрашиваю - приходилось из розетки вытыкать? Не могут вспомнить!!!

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

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

И, тем не менее, если человеку очень захочется свалить такую систему - он ее свалит. Пример - ЧАЭС.

А вообще, если кого интересует, есть у меня исходные технические требования (украинские, правда) к оборудованию пожарной безопасности на АЭС. Могу дать почитать, документ не секретный, может оттуда почерпнете, чего надо делать, и чего не надо...

Прошло много лет со времени проектирвания системы управления ЧАЭС, да и сам реактор отличается прочти буквально как движок паравоза отличается от двигателя внутроеннего сгорания. Появилась возможность использовать более сложную дуракоустойчивую технику, свалить из штатных режимов работы оператор замучается. От действий оператора в непредсказанных аварийных режимах, естественно завист многое.

Интересует. Правда я и свои (Российские) имею, поскольку оборудование иcпользуется на трех AЭС, в том числе на Южноукраинской и на одну проектируется. Но не систем пожаротушения. Интересует.
Ну а к системам пожаротушения, правда не на энергоблоке а вообще даже за пределами Ядерного Острова я претензии имею - ложно сработала задув газом и порошком полэтажа здания, где стояло мое оборудование. Но там что-то достаточно общепромышленное стояло. На энергоблоках совсем другие, по крайней мере управление не пласмассовая коробочка со светодиодиками на стене, а стойка высотой под метра два с немерянной красы Windows GUI.