Отказоустойчивость ПО

[Gnider]

Так Вы же написали: "Все проблемы с прерываниями надуманны. Берется нормальный современный камень с вложенным контроллером прерываний."? Я и возразил, что сам камень ни при чем.

Не подскажите, где именно? Готовлю материал по этой теме и отметил, что с источниками по ней очень туго.

По моей практике гнать надо почти всех

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

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

[kison]

Язык Си с раширениями и стандартами (которые есть) строго рекомендуется ("HR" - highly recommended) на всех уровнях. (К слову, использование голого Си допустимо только при самых низких требованиях).

Посмотрел этот МЭК. Очень забавный документ. Там походу рулит Паскаль.
В Си слишком многое недопустимо. Точнее не рекомендуется, но такие заявления в ГОСТ это тот же запрет. Например указатели. Без них от Си один огрызок останется. Убрать указатели и язык превращается в бейсик какой то.
Кому интересно и лень гуглить - http://www.gosthelp.ru/gost/gost47517.html
Я вообще не понял больше половины. К примеру желательно исключить ( я выборочно только):
-Указатели, динамическую память, динамические объекты
-Параметры процедуры.
Второе меня вообще в ступор вводит. Выходит передача параметров возможна только через статические/глобальные переменные. Там еще goto запрещен. Он не особо полезен кроме одного случая - выскочить из вложенного в другой цикла. Но так выходит тоже нельзя. Про запрет обработчиков прерывания на асме вообще молчу, хотя они сами по себе вполне безопасны.
ИМХО ни Си ни плюсы к безопасным языкам не относятся. Даже если навешать на них кучу ограничений. Впрочем что останется от Си, если не пользовать указатели, динамическую память и блин - ПАРАМЕТРЫ функций. Огрызки какие то.
Для безопасности лучше взять Паскаль, он строг и лаконичен. Хотя параметры функциям/процедурам там тоже есть. Пентагон вот считает, что надежные программы могут писаться на любом языке, если он конечно называется ADA. И создавали его именно для этого.
Интересно, что С++ в таблице рекомендованных языков нет вообще.
Так что - ADA,MODULA-2,Paskal и Fortran-77 наше все. А как известно настоящие программисты пишут только на Фортране

[testerplus]

Камень как раз причем. Использование ЯВУ,внутрисхемного отладчика,дма и прочего позволяет упростить процесс программирования.

Вы не поняли. Речь не об упрощении процесса и не о том, на чем надо сосредотачиваться программисту. Если напряжение на входе компаратора станет равным Vref, то прерывания (из-за небольшого шума, который всегда будет присутствовать) могут генериться так часто, что программа наглухо повиснет в обработчике. И никакие ЯВУ, камни, отладчики и пр. здесь ни при чем.

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

Это шутка? Там эта тема даже близко не затрагивается (за исключением AVR998 (посмотрите, кстати п.3.1) и подобных, которые действительно этому посвящены; в частности AVR998 - стандарту IEC 60730).

Дайте, пожалуйста, ссылку на такой аппноут (от любой фирмы, не обязательно атмель). Возможно, я пропустил что-то.

Литературу найти можно (в основном в виде статей) только на английском, на русском вообще ничего не встречал (кроме редких разговоров на форумах).

[testerplus]

Посмотрел этот МЭК. Очень забавный документ. Там походу рулит Паскаль.

Так и есть. Если вы когда-нибуть писали программы на паскале, то, наверное, помните, что там ошибку было совершить гораздо сложнее чем в Си. Си намного более гибок, поэтому стал популярным. Но по сути - язык совсем небезопасный. Об этом говорит появление таких стандартов как MISRA (кстати, рекомендованный к применению даже в таких областях, как авионика и медицина).

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

Все не так плохо. Но рекомендация не с потолка взята. (Кстати MISRA тоже не рекомендует использовать динамическое выделение памяти, причем с пометкой "Required", т.е. просто запрещает)

-Указатели, динамическую память, динамические объекты
-Параметры процедуры.
Второе меня вообще в ступор вводит. Выходит передача параметров возможна только через статические/глобальные переменные.

Речь не об аргументах функции, а о передачи функции в качестве аргумента. Так что не волнуйтесь и не передергивайте

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

Да, АДА намного более формализованный язык. Много за него не скажу, т.к. имел дело с ним всего один раз (переводил как-то библиотеку от Heneywell'а), но скажу, что вольностей, как в Си, он не позволяет. там все намного строже и однозначнее.

Интересно, что С++ в таблице рекомендованных языков нет вообще.

Насчет плюсов точно не знаю, но, возможно, они подпадают под "Язык си с надстройками и стадратами кодирования". Так что со стандартом вроде Misra++, плюсы, скорее всего, также HR. (Тескта этого стандарта у меня нет, но он стоит всего 10евро, кому интересно - могут приобрести.)

[Altele]

Интересно все же...Что же с Атмелом то будет..страниц 45 спорили...типа

[Gnider]

Вы не поняли. Речь не об упрощении процесса и не том, на чем надо сосредотачиваться программисту. Если напряжение на входе компаратора станет равным Vref, то прерывания (из-за небольшого шума, который всегда будет присутствовать) могут генериться так часть, что программа наглухо повиснет в обработчике. И никакие ЯВУ, камни, отладчики и пр. здесь ни при чем.

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

[picavr]

Ага, гидроусилители ваще чисто механика.
А мозги не содержат ни кварцевого резонатора ни PLL.

И не боятся нифига ядрёного взрыва, кстати, а электроника загинается от ЭМИ ))))
а ещё были разработки пневматических вычислительных машин... сродни гидравлическим

С атмелом ничего не будет. Но и мы его не будем.....

Будем пока не кончатся закупленые запасы ))))

8-битники производить только на заказ мегапартиями.

Скинемся и закажем Атмелю железнодорожный состав МЕГ8-х на всю Рассею ))) центов по 10-20 )))))

[kison]

Речь не об аргументах функции, а о передачи функции в качестве аргумента. Так что не волнуйтесь и не передергивайте

Если бы. В этом МЭК открытым текстом:
Не рекомендуется использовать:
...
-параметры процедур.
Прочитать это как нибудь иначе сложно. Это вовсе не процедуры как параметр процедур. Тем более что это не что иное как указатель, а он запрещен чуть выше.
На самом деле смысл отказа от параметров есть, именно в аспекте безопасности. Параметр передается или в регистрах или на стеке. В обоих случаях они могут быть испорчены. Передача параметров через глобальные переменные куда надежнее. Просто ограничения слишком сильны.

Насчет плюсов точно не знаю, но, возможно, они подпадают под "Язык си с надстройками и стадратами кодирования".

Тогда и с Паскалем так же? Выходит Дельфи прямо эталон безопасности, в нем ведь столько надстроек... У плюсов в самом языке масса противоречий этому стандарту, типа неявного указателя на текущий объект. В Дельфах кстати ровно так же. Неявная переменная, да к тому же указатель.

Да, АДА намного более формализованный язык. Много за него не скажу, т.к. имел дело с ним всего один раз (переводил как-то библиотеку от Heneywell'а), но скажу, что вольностей, как в Си, он не позволяет. там все намного строже и однозначнее.

Он Паскаль напоминает. Причем все еще круче. Я попробовал, когда его компилятор в GCC включили. Код просто ужос - большой и тормозной. Но надежность походу на высоком уровне. Если меня прижмет до соответствия этому МЭК - буду учить ADA. Вариантов то мало. Или ADA или Paskal. Фортран я давно забыл, что за модула даже не знаю, но компиляторов этих языков для встроенных применений не видел. А из первых двух ADA позабавней. Вообще это лучше в отдельную тему вынести. Иногда размышления о надежности просто выносят мозг. Например контроль частоты возникновения прерываний, а за опору взят такт контроллера. Дальше неплохо контроллировать и сам этот такт, а то не дай бог частота будет другой. И поехало расти как снежный ком.

[kison]

Что то еще противоречия есть. Если следовать МЭК буквально, то его требования приводят к нехилым усложнениям. Например требование иметь одну точку выхода из функции. Блок SWITCH совместно с return уже не катит, нужно завести переменную, записывать в нее значение и после выхода делать return result;
Иногда это приведет к очень неслабому нагромождение if/else/switch и прочим условиям. Либо.. использовать goto, что и запрещено и вообще говностиль почти всегда.

[omercury]

Дальше неплохо контроллировать и сам этот такт, а то не дай бог частота будет другой. И поехало расти как снежный ком.

Этот параметр ещё на 43 станице проконтролирован, вместе с WDT. А уж он (внешний и аппаратный) проконтролирует тактовую...