Ну вы как-то скачете из угла в угол - я же вам прямой вопрос задал про использование ОС vs bare metal, а вы с темы съежзаете. Хотя я могу ответить за вас - большинство задач на современном уровне развития без ОС вы просто не решите, автоматика и прочие биосы - это всего лишь исключение.

Вы схемотехник или руководитель, я угадал?

Ну вот, давайте ОС заменим аппаратным решением. Как это будет выглядеть? Под ОС я подразумеваю не голый шедулер, но сервисы (мьютексы, очереди, что там еще есть?), драйвера, различные сетевые и не только службы. Как весь этот суп организовать аппаратно? Пусть даже на ПЛИС? Это возможно?

Оба раза мимо: сейчас я просто студент
Я хочу сказать, что по возможности в разработке электронных устройств следует избегать использования операционных систем, исполняющихся из динамического ОЗУ, во избежание непредсказуемых сбоев в работе электронных устройств. Если же сложность разработки устройства не позволяет избежать применения ОС с динамическим ОЗУ для сокращения трудозатрат при разработке, то тогда лучше делить устройство на несколько независимых узлов аппаратно. Задачи управления следует решать без использования ОС, а взаимодействие с пользователем и прочие менее критичные к надёжности работы задачи выносить на аппаратуру, управляемую операционной системой из динамического ОЗУ. Имеющий разум и уши да услышит.

Большинство ембеддед-осей исполняется не только не из динамического, но и вообще не из ОЗУ.

Не нужно ни чего избегать. Нужно избегать использовать ненадёжные аппаратные и програмные продукты.

Чем не нравится связка ос+диманическоеОЗУ? Что, ос както по другому будет работать в динамическом озу нежели в статическом? А связка ос+статическоеОЗУ надёжнее? Или связка суперлуп+диманическоеОЗУ надёжнее? ОС вообще не знает, что озу может быть динамическим или статическим, и что исполняемый код находится в озу или в пзу.

Помню эту конкуренцию, всё-таки, хорошо, что сиэстел попыталися сделать своё. Жаль, что энтузиазм также по экспоненте.. А нынче от завода Шевченко - тут промолчу.

Нынче не разберешь из чего они выполняются. Понаставили всяких акселераторов, промежуточных FIFO, кэшей.
Хуже того, теперь даже шинные матрицы могут сбоить и объявлять о своих ошибках причем разных.
И что с такими ошибками делать?
Еще не видел RTOS которые бы что-то с этим делали. В лучшем случае когда все пойдет в разнос удалят задачу.
В рамках RTOS реально сложно бороться с проблемами сырости аппаратуры и туманности спецификаций.
Проще использовать линейный код без переключений контекстов, динамических ссылок и HAL уровня и статический анализаторы кода с трассером и все тотально прошерстить. Проще в плане достижения реальной надежности.

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


Проще-то оно проще. И такой простой подход получается применять пока программы несильно сложнее уровня "Hello, world" пишутся. А потом, по мере усложнения программы начинаешь понимать, что HAL-уровень не просто так появился, и таки суперлуп себя изживает.

Вот у нас софт для основной линейки продуктов развивался так:
- 1992.. - линейный код, чистый ассемблер x86, примерно 16к кода
- 1995.. - линейный код, некоторые протоколы в фоне на прерываниях, все еще ассемблер x86, 32-64К кода
- 1996.. - ассемблер частично помирает, фоновые прерывания, 50+ процентов C
- 1997.. - первое портирование на другой контроллер (первые Мега103), доля C неудержимо растет
- 2000.. - уже есть опыт с Win32, хочется и на встраиваемой платформе такое поиметь, но ресурсов нету, суперлуп становится очень сложным и достаточно глючным, протоколы в фоне на прерываниях тоже плодятся, поддерживать с адекватным качеством становится не совсем просто
- 2006.. - появились 32-битники с ресурсами, с ценой которую уже можно иногда позволить, изучается вопрос RTOS, начинается разработка своей вытесняющей платформы.
- 2009.. - окончательный перевод всего кода аппаратной поддержки на RTOS. Ассемблер почти умер - десятые доли процента, исключая криптографию, разнообразные успешные порты на различные аппаратные платформы
- 2013..?? - перевод основного приложения на платформу RTOS. Ага, суперлуп до сих пор жив в основном коде приложения, но он на сегодня глючит и создает больше проблем чем RTOS-платформа. Это я называю - "загибается". Ну не получается весь этот разросшийся за два десятилетия функционал простым циклом нормально обработать. Сейчас изделие обрабатывает и обращения по разным протоколам, и различную периферию с кучкой протоколов, и оператор бывает с ним работает, и сетевые обращения, и веб-сервер, и по USB-MSD иногда могут данные забирать. И всем этим все еще пытается рулить суперлуп. Не, оно-то все крутится в "фоне", в своих задачах, но суперлуп с трудом уже может хотя бы просто адекватно рулить всем этим через свои убогие монопоточные интерфейсы.

В-общем, на сегодня я рассматриваю RTOS просто как не самый плохой способ модульной организации проекта. Не то чтобы очень уж хотелось ее применять, но жизнь (разрастание и повышающаяся сложность проектов) заставляет как-то организовываться. ИМХО, единственный относительно серьезный минус вытесняющей RTOS - она просит некоторые ресурсы - и память кода для размещения, и оперативную память для стеков. Все остальное вполне решаемо. Ну да, квалификация от системного/встраиваемого программиста требуется немного повыше чем для линейного "Hello, world", но не запредельная, да и расти профессионально всегда приятно. Проблема надежности у меня решается жестко - 10-15 процентов кода это ASSERT-ы. И надо сказать последние года три сработки ASSERT-ов меня вообще не беспокоят.

Ну и байка напоследок - благодаря RTOS я познакомился со своей будущей женой
Была некоторая физическая лаборатория, где сидела милая девочка-аспирантка и снимала параметры с экспериментальной установки. Лаборатория имела кое-какое финансирование, и прикупила одну из первых в университете IBM AT/286. Сначала девочка просто щелкала тумблерами на установке и вносила параметры в файл. Потом лаборатория прикупила нановольтметр с интерфейсом КОП (ака IEEE-488/GP-IB), и еще кое- какие КОП-онизированные приборы, ну и тут нарисовался я - молодой и красивый , с опытом разработки контроллера КОП для шины МПИ. Контроллер успешно был переработан для шины ISA, и написалась программа, которая сама щелкала тумблерами, снимала все параметры и писала в файл. Девочка была симпатичной, а тут еще и первая увиданная АТ-ишка с VGA-мониторчиком, и Wolf3D как раз появился. Ну глупо же было на целый рабочий день запускать экспериментальную программу (ну да, MS-DOS, и экспериментальный цикл непрерывный, с заливкой гелия и азота) и терять внимание девочки, и еще тратить время диковинного компьютера с цветным монитором.
Поэтому был написан такой себе резидентный вытесняющий двухзадачный планировщик. Програмка вставала резидентно, и меряла себе там в фоне по-необходимости. Написана она была достаточно просто на Паскале, писалась моей будущей женой и ее коллегами, грузить их всякими системными тонкостями было неприлично, пришлось "брать удар на себя" - все хитрости делал именно планировшик, помнится он даже контекст FPU переключал. Ну и AT/286 освобождалась для запуска Wolf3D - это был отличный повод наведываться в ту лабораторию. В-общем, первый опыт применения RTOS у меня достаточно успешный - девочка вышла за меня замуж и защитила диссертацию. Так что RTOS-ы не столь уж опасны (хотя.. как посмотреть ).

Гм... это вариант я не учел
Но он многое объясняет. Это Вас в Университете так учат, или Вы сами к таким выводам пришли?
Если перое - не бросайте Университет, но читайте больше самостоятельно, анализируйте как делают другие. Реально делают, а не для лекции.
Если второе - ну нормально, у каждого должно быть свое мнение. Правда, как показывает практика, практика (извините за тавтологию) немного иная

Интересная мысль.... Вообще, надежность и применение ОС - понятия в общем случае слабо связанные, но я попытаюсь
показать, что надежность программно-аппаратного комплекса (прибора) может повысится из-за применения ОС.

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

Теперь рассмотрим вопрос о количестве ошибок в программе. Чтобы убедиться, что их там нет, необходимо:
1. Формально верифицировать математическую модель программы.
2. Формально верифицировать исходный код программы на соответствие этой модели.
3. Формально верифицировать компилятор на правильную кодогенерацию под определенную железную архитектуру.
4. Верифицировать железо на соответствие архитектурной модели под которую компилятор производит кодогенерацию.
До тех пор, пока этого не сделано, ошибки в программе есть.
Очевидно, в случае использования ОС пункты 1 и 2 значительно облегчаются, т.к. ОС верифицируется один раз,
а пользовательского кода становится меньше и матмодель проще.

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

В уже упоминавшейся NASA есть интересный документ [1], в котором хоть и тезисно, но рассматриваются подобные
вопросы проектирования. В частности, вопрос выбора "без ОС" vs "одна из существующих ОС" vs "разработка своей ОС".
Настоятельно рекомендую к прочтению. Более глубоко вопросы дизайна эмеддед систем рассматриваются в [2] - тоже
must read, имхо.

------
[1] http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf
[2] http://www.ee.ui.ac.id/muis/course_file/Re...nd_Analysis.pdf

P.S. Я специально не касался ошибок при эксплуатации (а-ля сбои из-за случайных частиц и прочего), т.к. это
отдельная тема. Но и там ОС выигрывают у суперлупа из-за уже существующих моделей при fault/failure кейсах.
А если AlexandrY не видел такие ОС, которые бы "что-то с этим делали", то это не значит, что их нет.
Даже если сравнивать программно-аппаратное решение с чисто аппаратным, однозначно сказать что последнее
надежнее - нельзя (опять же, смотрим [1] и [2]).

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

Спасибо, интересные ссылки.
Но спецы из 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 и мониторьте, иногда там жемчужины попадаются.

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 в одном потоке, опрос клавиатуры в другом, принятие решений - в третьем, мигание светодиодами - в четвертом... И т.п.

Не согласен.
п.1. Неправильная постановка вопроса. Оченку необходимо производить по параметру вероятность безотказной работы.
п.2. Не показатель. Даже в 10 строчках кода могут быть фатальные ошибки. Зависит в первую очередь от "классности" программиста и корректности постановки задачи.

По основному вопросу - дайте определение ОС. Сравнивать ОС общего вида и специальные некорректно, т.к. они выполняют разные функции.
В общем случае применение ОС позволяет сократить объем программного кода, уменьшить кол-во "глупых" ошибок, улучшить понимаемость программы(в т.ч. программистом, который физически не сможет удержать все взаимосвязи в голове).

Логику искать не надо здесь. Все чисто на опыте и наблюдениях.

Вот TI выпускает серию микроконтроллеров TMS570 , сверх надежные на Cortex с двойным синхронным выполнением на двух ядрах и сверкой результатов, с ЕЕС на каждый тип памяти.
Так во первых у них нет интерфейса к DDR, а во вторых у них нет портов RTOS с поддержкой фичи lockstep.
Буквально сегодня мне пришел анонс их новой RTOS - TI-RTOS. Там опять же нет поддержки lockstep!
Они что с дуба упали? Зачем в таком сложном чипе делать lockstep если его не поддерживают RTOS?
Ответ ясен, они его собирались использовать без RTOS в обычном понимании.
Т.е. в критически надежных системах RTOS не используют. Вот и вся связь

Сегодня уже процессорные ядра специально оптимизируют под конкретные операционные системы а вы все какие-то наблюдения из космоса приводите
http://www.imgtec.com/meta/meta-technology.asp

Я не вижу связи. Какая связь между DDR и ОС? В их чипе нет ддр и какаято невнятная связь между какой-то фичей lockstep и ртос. Что из этого следует? что ддр с ртос не дружит?

Вот чипs TMS570LS: Так во первых у них нет DAC, а во вторых у них нет портов RTOS с поддержкой фичи lockstep.
Буквально сегодня вам пришел анонс их новой RTOS - TI-RTOS. Там опять же нет поддержки lockstep!
Они что с дуба упали? Зачем в таком сложном чипе делать lockstep если его не поддерживают RTOS?

Согласно вашей логики наблюдениям, использование ос в чипах с DAC - снижает надёжность.

ps в тойже TMS570LS есть Real-Time Interrupt (RTI) OS Timer.

Таймер в TMS570 пришел от ядра Cortex. Это не вина TI.
DAC хотя и нет, но можно подключить внешний.
А DDR не подключить никаа...ак
С DDR не дружит надежность. Большим RTOS которые действительно экономят время и деньги своим мощным middleware (VxWorks, QNX, Symbian, ....) нужна DDR, тоже каждый знает.
Вывод - большие RTOS проектируются не для повышения надежности как минимум.
И можно сказать снижают надежность своим размером и требованием к объему памяти.



Этот пример только подтверждает, что RTOS-ам не доверяют и делают аппаратные реализации многозадачности.
Я еще помню эту технологию со времен Scenix когда они конкурировали с PIC-ами.
Не пошло. Ограниченная аппаратная многозадачность удобна только для ограниченного круга задач.

вывод за уши притянут.

Упрощенка, напр. пропеллер: там разделение аппаратных ресурсов за счет "бегущего 0 или 1", в итоге 160МГц - 8 ядрышек на 20МГц. Видимо, просто не дали им пойти дальше.

Я, как вы понимаете, тоже не согласен. К предыдущим ораторам хотелось бы добавить следующее:
1. Чтобы так утверждать, нужно сначала определиться с методикой измерения надежности и то, по сравнению
с чем надежность ниже. Конечно, введение ненадежного элемента в систему при прочих равных снижает общую
надежность, но тут ключевые слова - при прочих равных. Понятно, что мигать светодиодом можно из-под
Windows, а можно и простенькой схемой на 155 серии, но ведь некоторые задачи без ОЗУ решить невозможно
(при разумных сроках и стоимости). Опять же, вопрос применения ОС по сравнению с не-ОС абсолютно
ортогонален надежности DRAM.
2. Логика правильная, но посылка ложная. Начиная с некоторой сложности задачи, при использовании ОС
количество кода уменьшается (при условии, что задача корректно решается).

Вообще, если уже кто-то представил себе ОС как библиотеку с неким функциональным набором, уже может сделать
вывод, что как только человек в суперлупе применяет такие понятия как многозадачность, синхронизация,
память,... - он уже реализует ОС, которая, правда, размазана по пользовательскому коду. И тогда спор
суперлуп вс ОС отпадет сам собой. Действительно, нет принципиальной разницы между решением применять
libc для printf(), например, или rtos.lib для schedule() - просто функционал разный. И физическое отделение
данных сущностей в отдельный слой выглядит весьма логичным.

Другой аспект - физическая ненадежность электроники. Это тоже решается применением всяких SOI, сапфировых
подложек для исключения тиристорного защелкивания, triple-well технологией для того же, ЕСС на всех уровнях,
мажоритарной логикой, дублированием, троированием и прочими архитектурными радостями. И это все работает.
Пример - curiosity. Там стоят два RAD750, один из которых в резерве, абсолютно не подверженных тиристорному
защелкиванию (latchup-immune), выдерживающих миллион рад суммарной дозы, с надежностью 1.6Е-10 ошибок
(single-event upset) в день. Плюс 256Kib EEPROM, 256Mib DRAM (sic!) и куча флеш памяти. Плюс физическая защита,
разумеется. В результате, расчетная надежность данного комплекса примерно 1 failure в 15 лет. Хз, много это
или мало, но точно что достаточно. А крутится там сами знаете какая ось, и это неспроста. Так что если сильно
захотеть, можно и с ненадежной DRAM в космос полететь


Чтобы так говорить, опыт должен быть всеоблемлющим и должны быть проведены все возможные в принципе наблюдения.
Очевидно, что таких людей на планете Земля нет, поэтому остается только искать логику.



Данные выражения ложны. Чтобы их опровергнуть, достаточно привести один контрпример - см. выше. Если куриосити
не работает в сложных условиях и там нет критически важных задач, приведу другой пример. Есть известные стандарты
авионики, применяемые Federal Aviation Administration (я хз как это перевести), в частности, ARINC-653 и DO-178B.
И есть оси, им удовлетворяющие (тот же LynxOS-178B), задача которых не кинофильмы показывать пассажирам в салоне,
а входить в состав СДУ, т.е. помогать рулить. Да что там авиация, если даже в наших современных ракетах, которые
все еще объективно одни их лучших в мире перешли от жесткой логики к вычислителю с памятью + ос - о чем-то это
говорит (только тсс, это гостайна .

Так что RTOS применяются и им доверяют.

Как-то так.

По просьбам трудящихся я приведу здесь ссылку на отчёт североамериканских сотрудников "Гугла" об отказах в работе динамической памяти на серверах: "DRAM Errors in the Wild: A Large-Scale Field Study".

Да, тут крыть нечем.
Это я упустил.
Но с другой стороны, как я понял, рассматривался наш земной контекст, с комплектацией из Digi-Key и с минимально достаточным бюджетом.
И тогда несколько другие законы начинают работать.

Если рассуждать в том же духе, то на международной космической станции у космонавтов ноутбуки вообще работают под "Виндой". Теперь "Винда" стала космически надёжной осью что-ли?
Парни, может пора уже научиться думать своей головой, опираясь на факты и здравый смысл?
А через показательные полёты в космос эти "сверхнадёжные" операционные системы оседают в головах доверчивых руководителей и инженеров на радость довольным маркетологам.
Применять операционные системы с исполнением из динамического ОЗУ в задачах управления в электронных устройствах недопустимо.

Это не совсем так. Почти весь софт (включая оф. сайт) разрабатывается и поддерживается индусами. Ti это никак не скрывает. Вот отсюда и растут все ихние проблемы.

После нового года поступят в продажу SoC CC2538(он же CC2580 Cortex+ZigBee). Первоначально они анонсировали поддержку FreeRTOS но вот совсем недавно они заявили, что FreeRTOS поддерживаться не будет. Они не смогли портировать Z-Stack на RTOS. И это не вызвано соображениями надежности. Они ответили, что Z-Stack для запуска на FreeRTOS нужно переписать а они это делать не будут. Хотя перед этим они пытались это сделать.

Гугл отдельная тема. Данная статистика просто пища для размышлений. У МС тоже есть публичная статистика по фолтам
в винде Но тут другое. Гугл (я сейчас очень утрированно скажу) применяет ненадежное оборудование для построения
надежной системы. Т.е. он применяет дешевый шлак для построения надежной и робастной системы. Как им это удается?
Математика. Map reduce, сейчас вот spanner, причем это уже устаревшие технологии для гугла. Посмотрите на данную
статистику с другой стороны - гугл вопреки ошибкам в дешевой DRAM выдает на гора надежные решения.
Но и задача у гугла другая, не сравнимая с мелкосерийным производством межпланетных аппаратов (грубо говоря, у них
миллиарды микросхем памяти, в отличие от единичных аппаратов). Так что мимо.


Мой поинт в том, что люди, постоянно выдающие тезисы типа "винда говно", "линукс говно", "QNX - RTOS, остальное говно",
"суперлуп решает" и прочее (не обязательно прямым текстом, но косвенно... и это очень хорошо видно), - фанатики.
Адвентисты седьмого дня. Особенно "программисты QNX", почему то. И они сами себя зашоривают, не видя альтернатив.
Поэтому действительно серьезных задач они решать не могут. Вот я уже подчеркивал, что НАСА в своей памятке говорит
про выбор, выбор ОС, выбор без-ОС, выбор своя-ОС. Каждой задаче - свое решение. Чем бОльшим инструментарием владеет
исполнитель, тем эффективнее будет решена задача в среднем. Технико-экономическое обоснование должен писать не фанатик.
Но фанатики больше всех орут, и это печально



Будете смеяться, но и так было. Т.е. тупо подходит будущий космонавт (с начальством, разумеется) и говорит: "надо что бы
я на МКС засунул флешку в комп и винда восстановилась". И ничо, летит щас из перигея в апогей, и восстанавливает. И я руку
даю на отсечение, что восстановит.

Ну вы как и AlexandrY упростили настолько что исказили суть. Во первых аппаратные потоки там могут исполняться одновременно используя свободные ресурсы, а во вторых планировщик ресурсов там приоритетный благодаря чему например возможна работа RTOS совместно с GPOS без всякой виртуализации.
http://www.imgtec.com/factsheets/meta/Meta...re_Overview.pdf



Про какое управление вы говорите ? Я знаю массу примеров промышленных установок под управлением OS/2 например станки с ЧПУ, АСУТП и маркетологам типа вас ничего подобного не сделать.

Это уже религия. ))

Ещё раз спрашу: Почему ос+DRAM менее надёжнее чем oc+SRAM или чем чем суперлуп+DRAM?

Вам уже др учасники форума объясняют, что ос или суперлуп - в конечном счете одно и тоже. что schedule или что организация многозадачности в суперпуле - это одно и тоже. И ни как не связанно с ОЗУ.

Я вас призываю опираться на здравый смысл и научиться думать своей головой. Какие факты? Если бы была бы такая машинная команда, например с мнемоникой "ramJamp a,b;". И всё ртос используют эту команду, но эта команда ненадёжно работает с DRAM, а в суперпуле ни кто эту команду не вызывает - вот это был бы факт. Есть подобные факты? Код ос, например FreeRTOS, присутствует впроекте в виде исходников на си. код задач также написан на си. компилятор собрал исполняемый код. почему он на DRAM будет работать хуже менее надёжно?

А то, что ti не поставило в какойто чип контроллер ддр или что нет порта RTOS на чип - это ни чего не значит.
В мосгорсуде используют бумагу "снегурочка". Но это не значит что "SvetoCopy" ненадёжна.
Позвоните в ti и спросите "Почему нету ддр в таком чипе? Потому что ртос менее надёжна на ддр?" Если они скажут - "да, Применять операционные системы с исполнением из динамического ОЗУ в задачах управления ", ну вот тут будет пища, и то это не будет факт, это будет только мнение ti.

Сделайте эксперемент: запилите какойнить девайс.... напишите несколько задач и загрузите задачи вычислениями, пусть ПИ считают, да передают друг другу массивы большие. и запустите сие чудо на DRAM разных типов, например ddr, ddr2, ddr3, ... и при чем разных производителей..... каждых типов по 3-5 производителей. напишите программу с ос и без ос. и потестите. И причем для чистоты эксперемента пусть будет около 3 RTOS ну и 3 неRTOS. ну и потом всё тоже самое, только на статическом озу. - ну вот будет вам детальное исследование и факты.

ну из моей практики: около 12 лет крутится ос в системах, где ошибка=человеческая жизнь, круглые сутки на DRAM, в некоторых местах ещё на 386 компе - ни каких сбоев. Ща ртосы внедрил в проекты, тоже в такие системы, где связанно с жизнями - все работает и ни каких сбоев. Вот вам факт.

Сугубо практический вопрос на обсуждаемую тему. Только выбор стоит не "без ОС или с ОС", а "с минимальной ОС а-ля FreeRTOS или с ОС побольше а-ля uClinux".
LPC2478 (ARM7-TDMI, 96 кБ ОЗУ, 512 кБ флеш) + дофига (десятки мегабайт) внешней памяти с возможностью выполнения оттуда кода, как ОЗУ так и флеша.
Прибор - контроллер АСУТП. Из стандартных вещей, для реализации которых хотелось бы использовать какие-то готовые программные модули - работа с графическим индикатором (текст, простейшая графика - диаграммы), USB Host и Slave, работа с файловой системой на флешке. Остальное - сбор дискретных, аналогвых и цифровых данных, расчеты и логика управления - пожалуй никак не связано с выбором ОС.
Требуемое время реакции на некоторые события жесткое и весьма малое, порядка сотен наносекунд. Обеспечит ли какой-нибудь из линуксов такое время?
Я сам раньше ни с какими ОС не работал. Главным образом поэтому и склоняюсь к чему-то совсем простому типа FreeRTOS, в чем легко будет разобраться. Кроме того предполагаю, что возможности линукса избыточны для моей задачи, а вот ресурсов он явно будет потреблять много.
Прав ли я? Или может быть линукс содержит какие-то вкусности, которые в рамках обрисованной задачи компенсируют время, потраченное на его освоение?

Не реально. У нас на AM3517 600MHz + Linux + PreemptRT время переключения контекста 160мкс.
А у вас частота фактически в 10 раз ниже. Можете поэкстраполировать.

ну а если задачу с быстрой реакцией перенести на уровень ядра? Грубо говоря в обработчик прерывания засунуть быструю реакцию на событие. Тоже линукс не успеет?

Я не замерял таким образом. Так-что пока не могу вам ответить на вопрос.

Т.е. порядка десятков тактов процессора.
Только если реакция несложная и вся в обработчике прерываний.

Тут неподалёку как-то обсуждалось время переключения задач в scmRTOS на Cortex-M3 (72 MHz STM32F1, 100 MHz LPC17). Ну так эти «сотни наносекунд» идут десятками.

Сам микроконтроллер выбран неправильно. Нужно было брать на Cortex-M3 или M4. Там механизм прерываний оптимизирован для малых задержек.
И там легче сделать независимые от оси прерывания.
Вообще независимые от оси прерывания можно сделать практически на любом современном микроконтроллере и в любой оси включая линукс.
Надо только порт оси поправить и все драйвера. Чтобы не было глобальных запрещений прерываний.

Очень быстрый механизм прерываний с поддержкой сервисов оси сделан в свободной RTOS от Keil-а.
https://www.keil.com/demo/eval/rtx.htm

нет не успеет.
читайте http://www.at91.com/linux4sam/bin/view/Linux4SAM/RealTime

Ок, вынесение самых критичных по времени действий в обработчики прерываний - снимает вопрос времени реакции.
А возвращаясь к вопросу о вкусностях - для работы с USB и FAT'ом - как обстоят дела с хорошими бесплатными библиотеками под линукс и под FreeRTOS?
И еще, вопрос объема используемой памяти оказался все-таки актуальным. Какого порядка объемы флеша и ОЗУ нужны под ядро линукса и под каждую задачу?

с чего вы это взяли? смотря с какой частотой прерывания поступают. Навскидку: прерывания до 1кГц только можно "ловить вовремя", быстрее - сложнее. А о частотах порядка мегагерц и речи нет. Всё зависит от задачи.


В Linux с этим, насколько я знаю, лучше чем у других.


тут не подскажу. Ведь ещё ucLinux бывает

P.S. реализация TCP/IP в Linux - одна из самых лучших. всякие Lwip и рядом не валялись. ИМХО

Всяко бывает. Всё от задачи зависит.