Спасибо за совет, а в университете я изучаю маркетинг

Спасибо, интересные ссылки.
Но спецы из NASA в книге из 400 страниц, собственно выбору RTOS vs No RTOS посвятили всего 3-и параграфа.
А потом и вообще отправили курить суперлуп для малых встраиваемых систем - Get by Without an RTOS

В книге "REAL-TIME SYSTEMS DESIGN AND ANALYSIS" подход менее бюрократичный и более серьезный.
И там сразу предупреждают(вольный перевод), что для RTOS нет единых обобщенных методик верификации.

Хотя да, никто не связывает надежность и вопрос применения RTOS. Но скажем NASA проговаривается в таком смысле, что RTOS дает только экономию времени и денег (здесь важно слово "только").

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


Скорее, более абстрактный. Опять же, это инженерная книга, да еще 2004 года, а наука идет вперед. Проблемами
верификации занимаются давно, и даже есть методики (тот же DO-178B). Так или иначе, формальная верификация,
сиречь - математическое доказательство, является конечной целью. Вот, осенний свежачок [1] и [2]


Как не связывает, вон, Enthusiast связывает, ему прямо уже говорят, мол "ос != "ущерб надёжности"".
А NASA применение ОС подразумевает неявно, говоря, например, о RMA (Rate Monotonic Analysis, частотно монотонный
анализ) и вообще, там много "осевых" терминов по тексту.
Вообще, если представить ОС как тупо набор библиотечных функций реализующих определенные сущности, вопросов будет
меньше (а во многих глубоко эмбеддед ОС это и есть статически прилинковываемая библиотека).

[1] http://arxiv.org/ftp/arxiv/papers/1210/1210.2882.pdf
[2] http://arxiv.org/pdf/1211.6185.pdf

Статья про активные драйвера, кстати, неоднозначно показывает решение проблемы сложности драйверов.
(А сложность косвенно ведет к ненадежности)
С одной стороны пассивные драйвера вызывают треть ошибок в осях. Чуть ли не главные убийцы надежного софта.
С другой стороны они предлагают такой уж мудреный путь создания и верификации активных драйверов,
что только одни вспомогательные действия вызовут новую кучу ошибок.
Эт не говоря уже от том что на каждый чих там нужен майлбокс.
Скажем для драйвера Ethernet-а нужно будет 36 майлбоксов.
У меня столько на вcе фирмваре уходит с полным TCP стеком вместе с VPN, WEB, GUI, FS и прочим.

Спасибо за статью. Очень интересно почитать было, еще буду разбирать-обдумывать методику верификации (кажется там есть новые для меня идеи), потому что использую описанную технологию активных драйверов (думаю ее много кто использует - идея-то "на поверхности") - именно обработка всего доступа к аппаратуре в едином потоке, и единая точка разбора входящих событий, с перекрестной верификацией (при помощи встроенных ASSERT-ов) начального и конечного состояния внутреннего автомата. Это позволяет не парится вообще о синхронизации многопоточного доступа к ресурсам - из кода уходят все эти критические секции, и код становится более быстрым и читаемым. Мейлбоксы как-то не расплодились - использую очереди, часто нативные (встроенные в данные, например в поля буфера сетевых пакетов) и единый семафор/масочное событие для модуля. Причем такой подход отлично работает не только в драйверах. Жаль подобной статьи не попалось ранее - избавило бы от многих мук выбора драйверной модели. Данные про сравнительную производительность немного удивили - утилизация CPU выше (это понятно), но и пропускная способность выше (это странно немного - предполагал что производительность как раз страдает, готовлюсь к кое-какому рефакторингу)

Это всего лишь статья

Edit: Вообще, шерстите arxiv.org и мониторьте, иногда там жемчужины попадаются.

Сообщение отредактировал vshemm - Dec 11 2012, 22:31

Respect!!!


Каким же образом Вы связаны с программированием и схемотехникой? Заинтриговали!

Напиши в личку, пообщаемся

Мне кажется вы превратно поняли.
Сделать процедуру драйвера в отдельной задаче при этом оставив switch-case структуру на входе не хитро.
В статье же речь идет о разработке протокола драйвера и верификации потом его реализации по формальной модели.
Потом там борются с таким явлением как stack ripping (я бы перевел как потеря стека).
Т.е. драйвер разрывается на отдельные операции по окончании которых вы не можете надеяться на сохранение информации о состоянии драйвера в стеке.
Вы должны создавать структуры состояний для каждой задачи использующей драйвер. Просто перенос процедур драйвера в отдельную задачу проблемы не решает.
И именно stack ripping мешает анализаторам верифицировать протокол по модели.

Я скажем не разу не нашел возможность сделать активный драйвер.
А в принципе мог, создав модель в том же симулинке.
Пассивный реализовать гораздо проще.

На чём основано данное умозаключение?

На том же, на чем и Ваше) Только оба этих утверждения - противоположны друг другу

Мои доводы:
1. Если в устройстве используется динамическое ОЗУ для исполнения программы, то снижается надёжность работы устройства в целом. Причину я озвучивал ранее.
2. Чем больше строк исходного кода используется в программе, тем выше вероятность появления ошибки в ней, а следовательно, ниже надёжность работы устройства в целом.
С этим кто-то не согласен?

Интересный сайтик по теме: http://wiki.osdev.org/Main_Page

Я не согласен. Я не вижу логики в ваших аргументах.
1) Какую причину вы озвучивали ранее? Какие сбои в динамическом озу? Какая взаимосвязь между озу и ос? какие сбои ячейках в динамическом озу?

Ну допустим, есть DRAM, в котором, как вы говорите "следует иметь в виду вероятность сбоя в ячейках динамического ОЗУ". Вынесем надежность DRAM за рамки этой ветки и возьмём за априори: DRAM = вероятность сбоя в ячейках, т.е. ненадежна. Загрузив в неё ос получаем глючный продукт. Кто бы спорил. Но так это не проблема ос. А теперь грузим в это DRAM прогу без ОС - и что в результате? Более надёжный продукт? Не будет сбоев или они будут реже? Тоже глючный продукт получится. И если у вас глючная память - хоть винда, хоть линукс, хоть без ос....даже хеловорд или QNX - упадут и не встанут.

2)опятьже нету тут логики. Что надежнее - 1000 строк кода без ошибок или 10 строк кода с ошибками? код ос выверенный и оттестенный код многими людьми. А ваш свежий суперлуп нужно тестить и тестить. Если вы не доверяете коду ос, потому как не доверяеете чужому коду, то тогда также не следует использовать стандартные библиотеки, нестандартные библиотеки которые кто-то писал. А компилятор - это программа, которую писали теже индусы люди, и там таже могут быть ошибки. Тогда вообще лучше писать самому на асме и самому асм переводить в машинный код, а то вдруг компилятор асма подведёт.
И более того - программа без ос не всегда меньше программы с ос.

ps а на мой вопрос вы так и не ответили: Какая взаимосвязь между динамическим ОЗУ и ос? Почему эта связка ненадёжна?

Я не согласен
Любая память может сбоить. И не обязательно гонять ОС на динамическом ОЗУ. Многие RTOS вполне поместятся во внутреннюю SRAM 64 кБ. У меня контроллер с SDRAM работает несколько месяцев без выключения. Сбоев не было.

Ну напишет программист эти же строки для замещения ОС своим переключателем. Ну или использует уже готовое и отлаженное, протестированное многими людьми. Что надежнее? Я второе выбираю. А переключалка задач (или ОС, кому как нравится) уже на малых проекта дает выигрыш. Ну опять, банально, опрос USART в одном потоке, опрос клавиатуры в другом, принятие решений - в третьем, мигание светодиодами - в четвертом... И т.п.