1. Тема хорошая задана была:
Параметры оценки архитектуры ОС...
Только ... заговорили её: пошёл разговор об каких-то реализационных нюансах, которые ... могли бы ещё иметь минимальный смысл, если говорить только об
моноядерных ОС, но есть ещё архитектура
микроядерная - клиент-серверная (QNX, ... March, Darwin...) в которой большинство всей этой мелочёвки либо не возникает, либо решается автоматически, ... либо просто не возникает в силу принципиального отличия архитектуры (но возникают другие).
2. Вдвойне интересна - потому, что обсуждение возникло в среде разработчиков ... "малых архитектур":
Цитата(Andy Mozzhevilov @ Sep 12 2005, 06:42)
Можно на эту проблему посмотреть с другой стороны. Некоторые разработчики просто еще не доросли до RTOS (ничего личного). RTOS в их понимании - лишнее нагромождение, причем непонятно как работающее и требующее непозволительно много ОЗУ и ПЗУ. Лечится чтением книг, для начала Лябрусса. Хотя, если взять PIC16 и х51, то использование вытесняющих RTOS для них действительно практически невозможно (PIC16) либо представляет скорее академический интерес для младших моделей в семействах мелких контроллеров.
- что накладывает неизгладимый отпечаток, сравните, например, с:
http://qnx.org.ru/index.php?option=com_min...um=7&topic=16902. А если говорить об
параметрах оценки - то какое к этому всему имеет касательство:
Цитата(TMX @ Feb 21 2005, 11:46)
-. Многозадачность (есть, нет, кооперативная, вытесняющая, набор примитивов для cycl.exec и т.д.)
-. Приоритеты задач (стат, динам, несравниваемые и др.)
-. Особенности переключения задач (контекст, стеки и т.д.)
-. Реализация планировщика.
-. Реализация диспетчера.
-. Оценка преимуществ и недостатков методов планирования/диспетчеризации для конкретных задач.
-. Предотвращение инверсии приоритетов (есть, нет, методы)
-. Реализация искл. доступа к ресурсам.
-. Контроль задач (события, таймеры и др.)
-. Запуск системных и доп. процессов (методы для таймеров, ISR и т.д.)
-. Реализация HAL.
-. API - предоставляемые возможности.
-. Доп. средства (GUI, TCP/IP и т.д.)
-. Общая оценка.
- как может многозадачность быть кооперативная или вытесняющая, в не прямой зависимости от "реализации диспетчера", и чем "реализация планировщика" отличается от "реализации диспетчера"?...
- и все эти вопросы давно описаны и стандартизованы, так же как 100% "API и предоставляемых возможностей" POSIX.1003b (расширение реального ремени)... так что можно свести
всю эту класификацию к вопросу: "... на сколько % вся ваша ОС соответствует POSIX?"...
- и только когда все механизмы POSIX - реализуются, а всё ещё не хватает, вот тогда можно думать о каких либо расширениях... но это очень не скоро
.
Цитата(Гвоздик @ Sep 8 2005, 11:27)
А я согласен с VM насчет ненужности применения ОС в микроконтроллерах. Взгляните на Майкрочип: кучи исходных текстов для работы и с USB, и с Ethernet. Просто надо-то подключить файлы, скомпилировать и все.
3. А чем же эта "куча файлов" отличается
функционально от ОС, только ... плохой
...
Цитата(Гвоздик @ Sep 8 2005, 11:27)
А в бортовых устройствах все равно надежнее код без всяких ОС, да и отказоустойчивость выше будет.
Если предыдущая цитата - это просто заблуждение, то эта уже - преступление
.
4. Но есть ещё другая крайность - святая вера в то, что RTOS чем-то уж очень принципиально отличаются от GPOS (general purpose OS). См. например, здесь:
http://qnxclub.net/files/articles/RemarksO...TheMargins.html- это частное мнение, но разработчика с опытом многих и многих лет...
Цитата(si21 @ Sep 8 2005, 19:33)
Кроме того, ОС НЕ СНИЖАЕТ НАДЕЖНОСТИ ИСХОДНОЙ ПРОГРАММЫ/КОДА, все зависит от умений/опыта/рук/настроения/состояния - выберите нужное - программирующего
Использование API OS
всегда только повышает надёжность программного кода, даже вне зависимости от кривизны рук... Те же стандарты POSIX обобщают опыт (и "грабли") 30-ти лет, а реализации API, например, QNX, обкатываются и исправляются - 25 лет.
Ручной код будетреализовывать то же самое (stdlib) - но только "горбато" и со множеством субъективных допущений автора...
Наблюдаемая иллюзияллюзия надёжности ручного кода объясняется только простотой и примитивностью механизмов и алгоритмов, реализуемых в ручном коде, на
порядки проще, чем альтернативные реализации их в OS.
5. А если, всё же, вернуться к "параметрам и оценкам" - то первейшее дело, определиться с методиками: что и как вы станете сравнивать... К примеру, как это "по-честному" делает Dedicated Systems (www.dedicated-systems.com) - многолетний независимый тестер, в первю очередь RTOS & embedded tools: они в 1-ю очередь публикуют целую "книжку" методик на обсуждение: как мы сравниваем.
RTOS, Всё по ОС реального времени
Jan 27 2005, 13:49
Спасибо!
