Здравствуйте!

В настоящее время существует довольно много ОСРВ, как коммерческих, так и открытых.
Поделитесь, пожалуйста, опытом вашего использования ОСРВ и критериями выбора?

Заранее спасибо за ответы!

Главный критерий выбора для новичка имхо доступные информационные ресурсы. По нему у меня победили кейловская RTX и FreeRTOS.
Недавно натолкнулся на книгу создателя μC/OS - вроде неплохо всё описано, поставил в очередь для прочтения.

PS: Стоит выделить еще ScmRTOS - полезна, если хотите писать программы на С++. Её авторы обитают на этом форуме.

PPS: Про ОСРВ я слышал довольно давно, читал статьи, но реально осознал полезность, когда появились в разработке большие проекты - с несколькими интерфейсами, графическим дисплеем и т.д.. И обратно к конечным автоматам в суперлупе и самодельной синхронизации между ними не тянет.

Из ртос пробовал ucOS и FreeRTOS. Разницы в использовании практически никакой. ucOS позиционирует себя как серьёзную промышленную ось, но на деле всё кроме ядра (планировщик, семафоры) не особо практично и заменяется сторонними библиотеками. У FreeRTOS больше сообщество, сама ось бесплатная и достаточно активно развивается.
В целом ртосы не так, чтобы сильно нужны были. Код с ними становится несколько чище, но появляются дополнительные проблемы с синхронизацией и вместо отслеживания одного стека приходится отслеживать десяток.

Использовал scmRTOS, FREERTOS, keil RTX, немного TN_Kernel. Для scmRTOS доки на русском, все хорошо разжевано, минус для начинающего - С++ для встроенных приложений имеет свои особенности.но все равно рекомендую - исходники можно посмотреть, да и нравится она мне - правильная ось ИМХО. Много литературы по uCos читал-там тоже хорошо все документировано.
P.S. -в итоге пришел к тому что средства синхронизации для маленьких проектов использую свои, основанные на шаблонах проектирования queue, event channel, observer/publisher.

Из FreeRTOS выковыриваете переключатель задач и живете спокойно.
Все остальные прибамбасы заменяются одной атомарной операцией чтения\установки флага (две ассемблерных команды).

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

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

Если мне не изменяет память, то несколько лет назад Вы не знали Си и сидели на асме, утверждая, что так проще. Кто знает, может еще через несколько лет будут пересмотрены взгляды и на ртосы?

Память вам изменяет. Последний и первый АСМ, который я знал - для 8051. У всех остальных - даже не начинал интересоваться.
Кроме АРМ. Но ровно в той мере, которая нужна, чотбы правильно вытащить переключатель задач. Т.е. знаю даже не ассемблер, а просто систему команд. Процентов на 5%.

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

Значит я не правильно понял Ваши посты в прошлых темах, которые просматривал, где Вы говорите, что не знаете языка Си - например. И почему-то запало, что был пост и про ассемблер. %)

А по теме - можно использовать и свое. Но как бы не вышел Therac-25. Весьма наглядный пример.

Я и сейчас говорю, что я не знаю Си. Я на нем программирую. Да. Но сказать, что знаю - не могу. Вот Паскаль - я знаю. А вот Си - нет.
Вот Шумахер может сказать, что он умеет водить машину. А я по сравнению с этим эталоном - не могу. Хотя и управляю ей, и передвигаюсь из точки А в точку Б. И даже имею права.

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

Поддержка чужого кода довольно частое явление. И не считаете ли Вы, что если проект написан другим человеком на "публичной" ртос, то это облегчит задачу в разы? Ведь те простые и однозначные конструкции для Вас могут не оказаться таковыми для стороннего программиста, волею судьбы поддерживающий проект созданный Вами ранее. Другой вопрос есть ли в этом заинтересованность. =)

Уже второй раз в Ваших постах встречаю подобное высказывание )))

Очереди сообщений, флаги, memory pool - все это, по-вашему, лишние причиндалы? И как Вы это смогли бы сделать без использования критических секций, а только лишь "одной атомарной операцией чтения\установки флага"???

Сейчас пишу под uCOS-II. В проекте, "где выполняются независимые программы разных программистов"...

Топикстартеру - считаю, что uCOS предпочтительнее для начинающего, книга по ней очень хорошая. Помогает быстро понять основы.

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

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

И вообще. ВЫ МОЖЕТЕ ИХ ИСПОЛЬЗОВАТЬ. НО ЛЕГКО ОБОЙДЕТЕСЬ И БЕЗ НИХ. Эта фраза тоже появляется в моих постах во второй раз.

И опять таки. Есть читатели мануалов по использованию чужих программ. А есть писатели этих самых программ. Вот я не люблю читать. Просто пишу быстрее.

Книгу по uCOS едва ли можно назвать мануалом. Вы ведь уже открывали ее, не так ли? А читалем становиться рано или поздно всякий (лучше рано, чем поздно).
Не могли бы Вы высказаться по данной теме чуть подробнее. Конретно - высказаться по поводу флагов и очереди сообщений. Высказаться по поводу пула памяти. Поскольку ума не приложу, как это Вы можете обходиться без критических секций и только командами SWP/SWPB (я о ARM-инструкциях). Просто хочу убедиться, что, например, говоря о флагах, мы с Вами говорим об одном и том же...

Для меня было бы критичным наличие инструкции к портированию ОСРВ на определённую платформу. По FreeRTOS нашёл статьи в КиТ, но что - то про портирование там не нашёл, а другая документация платная.
C++ в определённой мере даже плюс, так как привычнее.
А µC/OS дорого стоит? И в чем отличие II от III?

Если требуется лицензионная чистота - uCOS отпадает. В чем отличия 2-ой и 3-ей версий - без понятия.
Доки по FreeRTOS - Нажмите для просмотра прикрепленного файла

Спасибо за доки. Но там что-то не описано как её портировать. Очень радует, что, судя по исходникам, для портирования надо написать всего несколько файлов.
Лецензионная чистота не совсем важна, просто желательна, неужели очень дорого?

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

UPD: Это что под ARM нет Оси и без портирования никак?

Исходники uCOS-а вы можете бесплатно скачать. Однако для легального применения в коммерческих разработках - судя по доке NXP лицензия на ядро uCOS-II около 5 килобаксов (не знаю, то ли это на год, то ли еще как...). Обычно коммерческие оси снабжаются TCP/IP стеком, USB device/host, gui и т.д. Что, как мне кажется, и делает их привлекательными для покупки. Так что в целом, думаю, дороговато будет.
А в том же FreeRTOS, как Вы видели - примеры под lwip, fatfs и т.п.
И потом у Вас проблемма портирования. Коли уж во FreeRTOS Вашей платформы нет...Возможно, scmrtos в этом смысле привлекательнее, поскольку с разработчиками Вы здесь пообщаться сможете. Разработчик TNKernel тоже здесь бывает.

все это мое имхо, конечно.


FatFS-ом Вы пользуетесь. Сторонними JPEG-либами тоже не гнушаетесь. Почему у Вас в отношении kernel иное мнение? А как же повторное использование кода, структурное программирование и все дела? Как-то странно все это....

Кстати, по поводу того, что: Не просвятите, что это за стандартные процедуры? И почему, с Вашей точки зрения, добавлять, например, функции для работы с очередями сообщений является глупым (судя по Вашим словам). Речь идет о queue... Комментарий по поводу работы с memory pool тоже хотелось бы услышать. Поскольку эта лишняя причиндалина, присутствующая во всех rtos, как оказывается, нафиг никому не вперлась и присутсвует исключительно для повышения ЧСВ Вы против того, чтобы структура данных и несколько функций были частью kernel?

ChibiOS не подойдёт?

Тут стандартный вопрос: Вам шашечки или ехать? Не секрет, что железный уровень надо прописывать.

На ядро ARM Cortex m3. Для этого ядра, думаю порты есть почти у всех РТОС. Получается надо портировать не на ядро, а только лишь на МК.

Большое спсибо за ответы

Если моральные аспекты не тревожат, или есть лишние деньги, то Keil RTX - достойная ОСРВ для изучения и использования. Помедленнее, чем, scmRTOS, насколько мне удалось проверить. Зато отладка поддерживается самой средой Keil. Можно получить красивые картинки распределения задач по времени, проследить состояния задач.

Рекомендую eCos - очень сильно конфигурируемая штука, можно взять только то, что реально нужно (а есть там много всего)
GPL

Protothreads. Не требует портирования, работает из коробки на всех архитектурах. Атомарность обеспечивается кооперативностью ОС, соответственно нет разного архитектурно-зависимого мусора типа планировщика, сохранения состояния/стеков и т.д.

Не забывайте, что атомарность надо обеспечивать и для прерываний.

Так же как и нет временного детерминизма. Protothreads удобная штука, но это не замена RTOS.

По мере роста опыта и сложности проектов сначала всё делал на C. Потом попробовал FreeRTOS, с ходу не хватило ума разобраться, зато перешёл на Protothreads - имхо вещь просто отменная для тех, кто не хочет заморачиваться с ОСРВ, а суперциклы и ветвления становятся чересчур громоздкими. А теперь уже перешёл на scmRTOS, ибо шашечки C++ очень помогают, а всякие штуки типа файловой системы, ж/к дисплеев и прочих приблуд в наших проектах не нужны. Хотя как заметили выше, для FreeRTOS есть много готового кода. В общем, каждому по потребностям. Кстати, если вам интересна "популярность" той или иной ОС, можете поглядеть на https://www.google.ru/trends

Моральные аспекты уже могут не тревожить - RTX уже free под bsd лицензией.

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

А в какой ситуации скажем ТНКернел при прочих равных лучше чем линукс? (Я сам RTOS люблю и пользую, но чем дальше тем меньше аргументов нахожу за "в очередной раз придумывать все велосипеды").
Если нужна многозадачность, но задачи "вялые", скажем четыре потока RS-232.
Интересует потребление. При этом разница в цене +20...30$ (больше RAM/FLASH нужно для линуха ), то это не аргумент.
Вот еще надежность аргумент, но сейчас плату без вотчдога найти сложно, пересбросится линух и дальше побежит (если не каждый день, конечно).

Несколько разные весовые категории.
И по цене и требованиям к аппаратуре.


Если цена не важна, то почему нет.
Другое дело, что linux ещё надо освоить. Лично мне сейчас это кажется неподъёмным и нереальным.
Но если у вас нет таких трудностей, то - вам проще.

За TNKernel ничего не скажу, это откровенно слабый проект из-за практически отсутствия промежуточного программного обеспечения как файловые системы, прикладной сетевой уровень, USB прикладных профилей, криптографии и проч.
За эталон надо брать MQX, ThreadX, VxWorks, Nucleus Plus...

Линукс тоже не смог снизиться на уровень задач микроконтроллеров.
Производители повально стали делать двух ядерные микроконтроллеры, один для RTOS другой для линукса.
Т.е. уже никто не верит, что линукс когда нибудь сможет надежно на одном ядре выполнять и пользовательский интерфейс и работу с сигналами в реальном времени.
За линуксом остался пользовательский интерфейс и через WEB в том числе и может быть сетевой стек.
Хотя с развитием облачных проприетарных технологий, еще не известно какие перспективы у стека линукса.
Как всегда будет отставать наверно, либо держаться за открытые кросплатформенные проекты, которые без труда можно перенести на любую ось.
Даже полевые шины типа CAN, RS485, EthetCAT... линуксу доверить нельзя, вернее тем бесплатным дистрибутивам.
Вообще линия раздела очевидна.

это да, но зачастую удается обойтись даже без запрещения прерыванийеще не сталкивался с задачами где нужен детерминизм всех потоков точнее 1мс. Даже с двумя параллельными обменами по 1-wire проблем не было - 20 тредов укладывалось в один тик 1мс. Конечно если нужна точность - без прерываний не обойтись, но основным потокам это не мешает.

_Артём_, спасибо.
AlexandrY, спасибо.

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

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

Еще раз спасибо, буду копать в сторону low-cost плат-модулей, поддерживающих линукс и еще что-то, желательно побольше последовательных интерфейсов (RS232/485,CAN). Когда-то считал, получалось что своя плата выгодна от десятка единиц (если не-BGA) или штук от 50 (если BGA), до этого проще готовый модуль использовать плюс своя простая плата с специфической обвязкой. Но опять же, индивидуально все это..... Интересно, что из современного с поддержкой линукса без BGA бывает, наверное уже ничего... будем искать....

Самые оптимистичные потому что для облачных сервисов как раз Linux в основном и используется.



Расскажите это Volkswagen которые разработали для Linux SocketCAN а General Motors использует его в своих люксовых седанах
http://www.opennet.ru/opennews/art.shtml?num=33943

По Вашей же подсказке из другой темы пригляделся к LPC43xx
Хм. розничные цены собственно на камень на дижикее не пугают, да и не-BGA еще бывают
LPC4330 (LQFP144) : $12
"портовооруженность" на уровне: 4 UART+ 2CAN. Есть любимый мной External Memory Controller но как все это гнездится в случае 144-пинового крпуса еще не смотрел. Ядро(ядра?) на 120МГц жрет 25 mA/3.3V. Очень напрягает сплошное TBD в разделе даташита "Power consumption", на что рассчитывать неясно.
Да и насчет отладочных средств непонятно (с ходу увидел только Keil LPC4357 Eval Board за $385). но уже интересно (может, на будущее, сейчас выглядит как из пушки по воробьям)
Upd: нашел такое за $59. здорово
http://microcontrollershop.com/product_inf...roducts_id=4840

Хм, самое время спросить не работает ли в тех "люксовых седанах" целая туча RTOS на поддержке того самого CAN-а.
Потому как если взять какую-нибудь платформу OMAP5, где аж два Corteх-M4 на подхвате, то оо..очень сложно будет сказать кто реально там чем занимается.





LPC43xx это немного другая тема.
Я больше имел ввиду Vybrid от Freescale.
Модули, кстати, делать на таких чипах будет не очень разумно.
Лучше разработать свою технологическую платформу, которая сможет долго прослужить.

обязательно работает, только это не означает что





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

Тут можно много готовых модулей найти
http://starterkit.ru/html/index.php?name=shop&cat=6
Правда я всё ещё присматриваюсь.


Тоесть из вашего опыта следует, что при использовании РТОС программы становились более компактными и их было проще сопровождать?
В scmRTOS 31 поток, вам их хватало?


А где вы черпали информацию по этой теме?

гугл + самостоятельное копание:

http://dunkels.com/adam/pt/
http://code.google.com/p/protothread/wiki/UsersGuide
http://atomthreads.com/
http://bsvi.ru/tag/protopotoki/

Это все очень далеко от темы. Да и вообще, называть десяток макросов осью, слишком громко.
Но работает. Когда надо поболее риалтаймовости, прототреды выполняются из прерываний...

А каким образом вы применяли ОС? Сколько потоков вам требовалось? Сильно ли приходилось дорабатывать её? Осложнялась ли работа с периферией?

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

Для обслуживания событий с дискретностью 1мс не требуеся никаких прерываний - хватает одного системного таймера на 1кГц, с программным опросом флага переполнения.

к работе с периферией наличие ОС не имеет почти никакого отношения. Вся работа с периферией выносится в отдельные функции/макросы, в результате все элементарно портируется на другие архитектуры (напр. портировал один проект (~14K Flash, AVR-GCC/ARM-GCC) с Atmega16 на STM32F100 за один вечер, причем сохранилась возможность компиляции под АВР).