Средства и методы разработки

Думаю != уверен. Для того, чтобы быть увереным нужно иметь какую-то статистику по сбоям, мол возникали вот такие-то ошибки, они имеют вот такое-то распределение по типам, адресам и т.п., фактически случайное -- тогда можно утверждать. А на утверждения "программа сбрасывается" и "контроллер зависает" я имею чёткий ответ -- программист. Который по крайней мере не разобрался в причинах с программной точки зрения при том, что железо вполне позволяет. Второе -- я имею мнение, что вероятность сбоев вызванных попаданием "залётных фотонов" сильно ниже того уровня, что можно статистически заметить за пару лет экплуатации пары тысяч контроллеров. Если мы не имеем ввиду какие-то особо сложные условия эксплуатации. Насколько ниже -- не берусь оценивать. На порядки. А вот фактор именно низкой надёжности "железа" вызванный особенностями работы электронной схемы, особенностями разводки печатной платы и т.п. -- запросто. И кроме того, фактор низкого качества ПО, об этом ниже. Кроме того, я выше писал, что ECC в контроллере не является серебрянной пулей. Да, ECC необходимо для существенного понижения вероятности сбоя, но не достаточно, т.к. не влияет на перечисленные выше факторы, которые более значимы, и ряд других. Я думаю, об ECC имеет вообще смысл задумываться, когда схемотехника источника питания, например, защищает от возможных latch-эффектов. Этого нет в 99.9999% коммерческих изделий. Когда программное обеспечение даёт полноценную информацию о каждом возникшем сбое, а не "программа зависла", когда ПО предусматривает возникновение сбоев, и предусмотривает восстановления после сбоя. Когда ПО само по себе достаточно надёжно (а это определяется не вылизанностью, а больше методиками его тестирования). О надёжности ПО. Увы, но в области embedded традиционно крайне низкий уровень программирования. Более того, тут тебя ещё назовут недоучкой и новичком за попытку использования printf и будут тыкать ассемблером со словами "у нас, тут в мире embedded, так принято, а ты пришёл из мира ПК потому ничего в этом не понимаешь". И такая ситуация, я уже не то, что уверен, а практически знаю, в 99% российских организаций, где чего-то программируют для МК. Вопрос почему так -- чисто экономический. Программисты МК традиционно хуже оплачиваются, хуже условия труда и идут туда специфические кадры. Нет каких-то методик программирования применительно именно к МК. В учебных заведениях этому ни разу не учат тоже, за редкими может быть исключениями. Литературы, русскоязычной, качественной тоже нет. Более того, в руководстве обычно так же считается, что сложные программы в embedded не нужны, нужны мальчики (с мамой, папой и квартиркой) чтоб по-проще и по-быстрей. Потому, что иначе ПО начинает очень сильно попросту перетягивать финансы на себя, безотносительно его качества, надёжности и т.п. Правда в том, что программы -- это дорого. И зависимость стоимости от объёма близка к экспоненте. И тут очень странно выглядят перекосы с ECC памятью и программками hello world. Утрирую, но близко к тому. И со схемотехникой такая же история. Разработка качественной схемотехники -- тоже время и деньги, никому это не нужно и редко где делается. И ECC в таких условиях совершенно ни к месту.