RTEMS - http://ru.wikipedia.org/wiki/RTEMS (оф. сайт http://www.rtems.com/ )
eCos - http://en.wikipedia.org/wiki/ECos (оф. сайт http://ecos.sourceware.org/ )

обе открытые и свободные, под гуманной лицензией (у RTEMS - позволяет использовать в собственных разработках, не открывая код).

Но полистав этот подраздел форума, встретил только единичные темы по ним. В чём причина такой нераспространённости??

ведь, как я понимаю, например RTEMS, нет необходимости в MMU, а по отказоучтойчивости она (грубо) сравнима с проприетарщиной в лице QNX, VxWorks, MontaVista (грубо). Всёж была выбрана для марсохода, как-никак..

eCos - тоже активно развивается, поддержка актуальных архитектур (Cortex), периодические релизы..



Хотелось бы понять каковы ниши этих систем и какие из ОСРВ являются их "одноклассниками"
(приведенное сравнение выше - грубо, ибо неизвестны мне аппетиты этих систем до ресурсов).

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

Для затуманивания в открытых осях раздувают дистрибутив, набирают как можно больше сорсов, несмотря на то что некоторые вообще не интегрируются или не протестированы.
Делают кучу несложных но и невостребованных приложений как слой эмуляции POSIX, слой эмуляции uITRON. Какие-то оболочки, какие-то мониторы, назначение которых даже сами авторы слабо понимают о чем сами и пишут в readmy.
Раздувают доку, конвертируют в PS, в PDF, в HTML в другие экзотические форматы, доксигенят.
Эти действия очень просты, выполняются конвертерами на автомате, но зато производят впечатление огромнорго объема документации.

А на самом деле как eCOS так и RTEMS совершенно отвратительно документированы.
Многие важные функции вообще описаны только своим названием и перечислением аргументов в стиле доксигена. Примерно такое же количество функции вообще не описано.
Чтобы описать конкретные способы, случаи, стили использования функций из множества пакетов составляющих фреймворк вообще речи не идет.
Сам открытый фреймворк, т.е. TCP/IP стек, файловые системы, GUI, межпроцессорное взаимодействие, интерфейсные слои для UART, I2C, SPI, CAN, SSI, I2S, SDIO, USB, PCMCIA, Ethernet, и т.д. этих осей очень слабы. Их практически нет для современных микроконтроллеров. Где-то там мелькнут LPC или SAM-ы, но никогда не охватывается вся их периферия в каком-то минимально достаточном для реального приложения объеме.

Кстати с eCOS сталкиваются все кто портирует бистрибутивы Linux от Freescale. Поскольку на eCOS сделан их загрузчик RedBoot.
Дистрибутив RedBoot весит больше десятка мегабайт, солидную часть из которых составляет пакет Microwindows с Nano-X у которого нет ни одного драйвера к современным TFT/LCD панелям и который RedBoot у Freescale никогда не применяет.

В RTEMS я обнаружил такую "фичу" как мультипроцессорность, ее кстати, любят приводить как нечто уникальное некоторые авторы пишущие обзоры осей. Так эта мультипроцессорность в самой RTEMS вещь довольно убогая и примитивная, но хуже всего что свои стабильность и надежность она полностью наследует от драйверов которые должен к своей платформе писать сам юзер и примеров которых на реальных платформах практически нет.

И вот подобной халтурой эти оси пропитаны насквозь.


Кстати, про марсоход.
Нынче даже в мобилах применяют по 5-ть и более процессоров. С полной гарантией можно говорить, что на каждом будет своя ось. Таким образом каждый разработчик оси применяемой в одном из процов мобильника может с гордостью заявлять что его ось юзается в нескольких милионах дивайсов, даже если та ось ответственна только за зарядку аккумулятора или только за сжатие видео с встроенной камеры.
В марсоходе скорее всего счет процессорам идет на многие десятки. Имея в виду любовь NASA к распределенным архитектурам можно даже говорить что там нет даже центрального микроконтроллера отвественного в целом за всю систему.
Т.е. вполне допускаю, что RTEMS у марсохода где-то в пятом колесе справа обслуживает датчик выхлопа для студенческого проекта, но тогда там еще с десяток осей надо назвать также побывавших на марсе.

Только используются чем дальше, тем больше, ха-ха!Бред, легко портируются.То-то роутеры, NAS-ы и т.п. поголовно на одной "открытой оси".Надо полагать - даташиты Вы не читаете, инетом не пользуетесь. Иначе откудо самые ходовые форматы оказались "экзотическими"?А рвкеты и спутники летают как-то и даже с превышением расчетного срока, как марсоходы.Между тем в начале есть ссылка - RTEMS, где написано , prd-ка, Electra - обеспечивает связь, службу времени, измерение расстояний и т.д. Явно не "пятое колесо".
Вот еще спутники: Herschel, THEMIS, Dawn. Ну не подошла "ракетная" ось, МО Америки - для Вашей кофеварки, нет там "лёгкости освоения" - может "халтура" , а может в консерватории чего поправить, только зачем писать откровенные выдумки-то.

А почему во множественном числе? Надо используется, поскольку вся Ваша патетика относится к одной (то самое исключение,лишь подтверждающее правило) операционке, а отнюдь не к тем, которые послужили началом для разговора.

Для особо непонятливых повторяю - если СКРОМНУЮ документацию сконвертировать в десятки форматов, и надоксигенить еще из исходников, то от этого ее не станет больше.

Я тоже типа использую в embedded и отказываться не собираюсь пару свободных осей. Только одну (догадайтесь сами какую) исключительно на индустриальных PC, а FreeRTOS претерпела весьма изрядные изменения и дополнения перед РЕАЛЬНЫМ использованием, хотя и послужила для меня ОТЛИЧНОЙ основой.

Отнюдь не выдумки - , скажем так, размышления, в вот Вы, напротив, пытаетесь исключительно готовыми рекламными цитатами изъясняться

Ладно, это я придрался.
Все равно pdf никак не назовещь экзотическим, других даташитов не видел почему-то.
html тем более.Про пятое колесо - явно выдумки.
Радиосвязь - явно критическая подсистема, не важно сколько процов в марсоходе и сколько самих марсоходов ползает.

Тоже скажу размышление - мне дали стенд делать с дисплеем, связью с верхним уровнем и т.д.
Вроде бы надо использовать какую-то ось, но новерно попытаюсь сам всё написать, охото.
А изучать чью-то ось нет, ИМХО в этом причина малого использования, в психологии.

Зря. С нуля, притом, что есть масса вполне юзабельных (имеется ввиду ядро, а не, например, "BSP") и в состоянии 'как есть', писать незачем. Запуститесь на чем-нибудь, осмотритесь - сможете прогибать-менять-развивать под себя. Я уже давно перестал изобретать (из имеющихся заделов, естественно) почти под каждый случай свою "операционочку". Хотя многие годы и операционки ваял и инструментарий....

Им +5 балов, а вам -1
За то, что не копаете глубже.

У меня был в разработке спутниковый тюнер.
Объясняю как он устроен:
На подключении к радиочасти стоит скоростная FPGA с неким процессорным DSP движком, вещ круто секретная. Имеет I2C и проч конфигурационные каналы. Вся инфа только по NDA. Этим I2C управляет какой-то 8-и битник. Этот 8-и битник еще контролирует температуру этой FPGA, напряжения на ней, алярмы если что посылает, смотрит чтоб она не зависала и проч.
Поток из FPGA идет на сильный 32-х разрядный проц выполняющий роутинг, скремблирование или дескремблирование, фильтрацию, демультиплексирование на потоки, поддержку сигнального канала, поддержку выходного локального интерфейса (оптика, медный Ethernet и т.д. )
И как вы думаете где там RTEMS может поселиться?

А еще, вы нашли в том дистрибутиве RTEMS который дают качать те хотя бы намеки на стеки космических протоколов связи или алгоритмы управления движением или обработки видео?
Там полный ноль! Раскройте глаза.
Никаких доказательств присутствия RTEMS или ее предназначения для высоконадежных и специальных применений нет! Есть только сомнительный статейки в wiki вскользь поминающие RTEMS и всегда в сопровождении неких модулей на SоC-ах

Либо для скачивания доступен не тот RTEMS. Вот это я считаю наиболее вероятным.

Исходный свободный RTEMS имеет практически столько же фичей и сервисов как и uCOS или FreeRTOS или NutOS и прочие оси, но гораздо хуже документированных ибо это бутафория согласно моей версии.
Наживка для студентов, возможно имиджевая пропаганда каких-то университетов или научных групп.

Не знаю, нигде новерно. Лично я постарался бы обойтись петлей (for(;;)).Зочем, ну зочем мне или Вам космический протокол? Вы намерены зопустить спутник?
Видео явно не задача оси.Т.е. врут на официальном сайте и НАСА тоже?
Не серьёзно.Рекламируются и коммерческие оси, чо удивительного-то?

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

За выдумки про пятое колесо Вам -1

насчет ecos и rtems - оно местами так и есть - блин в Украине есть даже такая пословица - "Бачили очi що купували", т.е. нужно быть совсем тупому что бы не увидеть, что ось просто не лепится по данную задачу. Короче : кажному овощу своя кошелка - есть в природе варианты где и ecos недурственно выглядит.
Чтобы развеять сомнения нафиг - реально лучше примеять ту ось, спец по которой есть под рукой - иные варианты просто обойдутся дороже.

К какой же, позвольте узнать?

Не догадались? Linux - количество (огромное) переросло в качество (нормальное). Написанное относится к инструментарию и ядру, но оттнюдь не к десктопным потугам, где невобразимое количество "разработчиков" уже угробило здравый смысл.

мы используем и то и другое, процы ARM, PPC, SPARC
большинство процев кастомизированные (то есть АЗИКи), поэтому нужен полный контроль над сорцем
знаю, что конкуренты в этой нише используют те же ОСы
eCos тоже не требует открывать код (она по LGPL вроде бы была), я не лойер, но мериканьски лойеры проверяли
http://javad.com/jgnss/

по поводу надежности - приборы работали в антарктиде автономно - резет некому было нажимать, ну и в рекламных целях их то в формулу-1 то еще куда-нибудь засовывают (журнал GPSWorld можно посмотреть)

то что AlexandrY думает про это - сильно отличается от реальности

с RTEMS лично я дело имел мало (вобщем простая С-шная ось, проект давно заморожен и используется нами как legacy support), но сравнивать что-то типа uCOS с eCos - это просто смешно, совершенно разные весовые категории (я не из теоретических соображений, а из опыта использования обоих)
для каких-то дуделок и елочных гирлянд uCOS нормально (затраты на освоение екоса избыточны), в eCOS например, есть поддержка SMP

я бы поставил eCos посредине между переключалкой и uClinux

так в том-то и дело, что операционки достойные, релизы поддерживаются в актуальном состоянии, с точки зрения лицензионной чистоты для коммерческих приложений тоже всё кузяво,
а чтобы кто-то помимо Джавада и Топкона их использовал я не слышал - вот и пытаюсь понять для себя - в чём парадокс?!

Посередине eCos это и есть чистой воды переключалка. Приличная (как и многие другие), но именно переключалка. Из наворотов считай только загрузчик (чужой).
Кто готов делать свое - могут выбирать в ряду таких-же переключалок. Остальные выбирают разной степени навороченности комплексные решения от uCOS до Lin/Win.

Не знаю как RTEMS но eCos пробовал поднять на своей платформе. Так что могу выступать как потенциальный чайник. Плюсы следующие: поддерживает посих (так что синтетические порты практически ненужны а отладка драйверов на синтетических портах и так без смысла), маленький футпринт, хорошо стыкован боотлоадер redboot с системой (совместные исходники ). Но конфигураця адская. Модификация исодников конфигуратором хороша для того кто эти исодники писал. Тоесть без хорошего понимания как оно устроено использовать конфигуратор безсмысла (если нет приготовленого под конкретную платформу). Ну и понятно поддержка (как бог дал на группах если платформа не стандартная ). Мне кажеться чтобы использовать eCos то надо пройти следующие этапы чайник -> чайник который понял что надо смотреть на HAL чтобы запортировать свою платформу -> много времени -> какой то результат . A это отображаеться на времени (ну а начальник он и в африке начальник).
А что касаетьса RTEMS то много этого есть в телефонах VoIP (SIP).

да нету имхо никакого парадокса. Джавад и Топкон открыто признаются, что применяют, остальные потихоньку юзают безо всяких там рассуждений "переключалка-неперключалка-агде же космические протоколы" . есть российские конторы где применяют, называть не стану, пусть сами называются.

Делаю электронику для Фурье-Спектрофотометра, для марсианской экспедиции (ИКИ РАН + ESA). Элементная база - Actel RTAX2000. Там реализуется LEON3. Операционка - RTEMS (она уже зарекомендовала себя в нескольких приборах ESA, да и более удобна(это моё субъективное мнение! Просто по опыту работы) по-сравнению с eCos). Прикладные программы наш программист пишет на Аде.

ну там MINIMAL конфиг отъедает ~64к, если сравнивать с scmRTOS то сильно тяжелая переключалка, однако.

ну и виндовз по большому счету тоже переключалка (причем хреновая)

Зато бескомпромисная по функциональности - можно не прогибаться (и не работать с постоянной оглядкой) под возможности минималистичных (это не ругательство - ну цель такую авторы ставили и решили) щедулеров типа scmRTOS, uCOS.

посмотрите список контрибуторов - если не из универа, то наверняка используется в приборах фирмы

также аштек (проф. магелан) программисты то оттуда, и вполне возможно тримбл - это корень зла

причина использования в аштеке (имхо) - нужна была операционка открытая, без всяких фии. а тогда (~20 лет назад) ничего кроме RTEMS и не было
а потом (~10 лет назад) проект разросся, держать его в С стало очень тяжело, поэтому перешли на С++ операционку (тоже альтернатив eCos никаких не было)

для людей свято верящих, что бездельники из университетов не в состоянии написать ничего дельного, есть eCosCentric - то же, но за дэнги




я вообще-то не программист, мой инструмЕнт Verilog HDL. но так как делаю микропроцессорные системы, то первые коды (порты) приходится писать мне, но дальше минимальных конфигураций не иду.

смысл (и преимущество) eCos перед scmRTOS (я кстати ее уже пользовал с большим удовольствием) это возможность набрать юзерей, которые пишут юзерские задачи и их легко добавлять их в проект. то есть не нужно считать - а хватило ли битиков в слове треда на все задачки, а нужно ли юзерьский printf заменить на UART_out_data и т.п.

то есть здесь получаются преимущества Linux-а (типа отладки на ПК, легкости сборки) для маленькой cистемы - память сотни к, а не мегабайты

собственно поэтому я бы и поставил eCos посредине между Linux и scmRTOS

мне например гораздо менее понятно использование uClinux, а не eCos для систем без MMU. за минимальную возможность прохалявить (по моему опыту собрать задачку для ecos совсем немного сложнее, чем для uClinux) пользователи uClinux готовы тратить мегабайты и сотни мипсов непонятно за что.