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

Выбираю РТОС, для своего нового девайса. Из множества вариантов осталось несколько. Прошу помочь с выбором. Платформа - Cortex M3. Планируется использовать для широкого круга задач в будущем.

В scmRTOS порадовало наличие русского манула, хотя и для древней версии. Напугало написание С++, привык думать, что плюсы это удел сложного прикладного софта и ОС на С++ - экзотика. С и С++ знаю на среднем уровне, придется поддятигавать два языка для одного проекта.

Про eCOS уже давно слышал изза всем известного RedBoot но никогда не работал.

FreeRTOS знаю очень популярная, практически у каждого производителя есть какой демо проект с этой ОС.

TNKernel - редкая птица.

uLinux - не знаю нафиг Линукс на МК

Очень интересно знать больше по поводу багов, активности проекта, комьюнити, об этом могут знать только те кто с опытом.

Вообщем расскажите ваши впечатления, помогите вібрать.

Авторы scmRTOS тут обитают, значит если что можно заказать консультацию. Дока вполне актуальная и для 3.1.

С eCOS работал (хотя и не на ARMе). Весьма и весьма приличная штука (кстати, она внутри тоже на плюсах )

Что можете сказать о написании ОС на С++? Насколько это хорошо или плохо? Какие преимущества и недостатки? Если не брать во внимание знание языка.

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

Думаю вряд ли вы найдете ответ хорошо это или плохо.
С++, на мой взгляд, хорош там, где можно применять его вкусности.. В случае scmRTOS он действительно реализует свою плюсовую функциональность.
Потенциальный недостаток только 1, и то скорее всего он был раньше: отсутствие C++ компилятора для определенного МК. Но на сегодняшний день такой острой проблемы не стоит, даже не вспомню компиляторов, не поддерживающих С++.
В остальном C++ дает только приемущества.

Берите vxWorks если не хотите в ближайшие годы перебегать с оси на ось. Лежит здесь неподалеку.
Сама по себе ось дает некоторое облегчение только по началу, а потом захочется middleware.
Если шансов перейти на старшие ARM-ы не светит, то брать надо укомплектованную по максимуму RTOS.

Простите за оффтоп . Но коли тут спецы по осям, то спрошу заодно, дабы лишнюю тему не плодить.
1) Очень интересно - почему до сих пор нет порта Minix под ARM? Какие-то принципиальные непреодолимые трудности? Или просто никому не нужно? Почему спрашиваю - купил как-то Таненбаума, в образовательных целях. Понял, что без знания 386/486 читать книгу нефиг. Учить интел очень не хочется. Хочется найти нечто подобное, но под ARM.
2) В связи с п.1 какую ось посоветуете в виде некоей замены миниксу - чтоб на примере нее вкурить про ОСи вообще, возможно что-то где-то изменить или добавить (ну типа лабы ). Единственное, что встретил по этой теме - в книге "ARM System Developers Guide". Может еще что-то где-то вам попадалось? Буду признателен

Embedded порт Minix под АРМ называется Linux . Ну почти .

Вопросом на вопрос. Простите, а что там в 386/486 сложного, после ARM вам показалось?

Сравнение нескольких осей и обоснование, почему автор выбрал TNKernel: Почему TNKernel?

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

Однако другие сравнения (включая приведенные в топике) примерно на порядок менее объективны. Надеюсь услышать от вас более объективное сравнение, или хотя бы ссылку на сравнение, которое не может быть подвергнуто аналогичной критике.

Его не будет, слишком много критериев и непонятен их вес. Даже то, что можно выразить, например, в тактах, крайне трудоемко для действительно объективного сравнения. Лично для себя, после написания в течении пары десятков лет достаточно большого количества системок и систем в которых то-же быстродействие стояло в топе критериев, лет 6 назад, стал прежде всего обращать внимание не на "10us" выигрыша на переключении контекста, а на функциональные возможности. Единственно, что всегда оставалось на первом месте, это возможность и ориентированность системы на модификацию и дополнение. В те-же времена завязал с изобретением велосипедов с нуля и выбрал за отправную точку FreeRTOS. TNKernel обнародована была позже. Уже когда-то писал на форуме, что очень понравилась. Только собственно шедулер несущий то-же родимое пятно приоритетов, что uCOS я-бы точно для себя менял. Однако, к тому времени FreeRTOS была обжита, со страшноватым стилем исходников и эгоцентризмом Автора FreeRTOS я смирился , внес и продолжаю вносить для себя заметные изменения. В чем-то под влиянием этой конкретной системы пересмотрел свои взгляды. И... за эти годы использования результата на ARM платформе даже в малом, ни разу не сожалел о выбранном пути. Наверное это главное .

eCOS намного больше FreeRTOS, scmRTOS, TNKernel по потреблению Flash и RAM? Не хочется добавлять внешние чипы памяти.

eCos конфигурируется по потребностям пользователя. Так что потребление RAM может оказаться очень разным. Для оценки размеров можно посмотреть на какое нибудь приложение под eCos (redboot например)

Как вариант можно еще RTX от Keil рассмотреть, потому что маленькая и поддерживается компилятором.
Я с год назад выбирал между RTX, FreeRTOS и scmRTOS.
scmRTOS потому что понравилась поддержка С++. Но оказалось что от С++ в микроконтроллере больше проблем возникает чем преимуществ. Опять же размер программы для меня важен.
FreeRTOS вроде тоже неплохой вариант, но преимуществ для меня относительно Keil не было и просто поленился переходить.

Можно узнать, какие проблемы возникают от С++ в микроконтроллерах?

И еще мне не понятна связь между языком ОС и языком прикладной программы. Что мешает, используя ОС, написанную на С, писать свой код на С++? И наоборот - если взять, например, scmRTOS, то что мешает писать свой код на С? Не думаю, что у Си-программистов вызывает трудности необходимость использования нотации <object_name>.<function-member_name>. А больше там ничего плюсового в явном виде писать не надо. Доподлинно знаю людей, который не знают С++, но это им нисколько не мешает использовать RTOS, написанную на С++.

Для меня проблемой было смешивать C++ и С функции. Компилятор выдавал кучу предупреждений. Встроенный в Keil монитор почему то не работал. Признаю что мои проблемы были от недостаточных знаний, но разбиратся времени не хватило. В программировании на С++ все было нормально потому что опыт объектного программирования есть, в том числе и на MS C++.
Вообще С++ мне больше нравится и из за него с scmRTOS связался. Только примерчика под Keil тогда не было. Еще jtag и мониторо от Keil мне дороже С++.

Изучил мануал scmRTOS и пробежался по исходникам, понравилась Использование C++ выглядит очень оправданным, понравились каналы на шаблонах, интересная реализация критических областей с помощью экземпляра класс TCritSect. Думаю, применять С++ актуально. Исходники показались понятными хотя кое-где нет единых правил именования методов, как мне показалось. И два варианта планировщика не совсем понятны, здесь нужно наверное знать еще аппаратные нюансы. Пример без проблем запустился на аппаратной платформе с эмулятором.

Пробовал TNKernel, пример предназначенный для запуска в C-Spy, в свойствах проекта указал использование J-Link, проект откомпилировался, но не запустился, выдал ошибку. Возможно мало было только указать эмулятор, что-то еще нужно было сделать, но дальше копать не стал.

На использование С++ уже смотрю более перспективно, думаю буду выбирать только из С++ операционных систем. Подскажите, что еще есть для моей платформы, только бесплатное, без необходимости открывать исходный код, нарушать требования лицензирования не хочу, авторов нужно уважать.

Еще хотел бы реализацию файловой системы, TCP/IP стек и библиотеку USB на C++.

RTX не хочу, выбрал IAR, к тому же хочу использовать не коммерческую ОС.

Не могу найти какие минимальные требования по памяти для eCos, если оставить только планировщик и средства межпроцессного взаимодействия, как в scmRTOS. Вообще чем хороша eCos на ваш взгляд?

если вопрос лицензионности не волнует - ставите кроссворкс (даже ломать не надо), выдираете исходники CTL (открыто лежат отдельной папкой), выдираете по ним хелп (весьма нормально построенный) и наслаждаетесь.
есть порты под ARM7/Cortex/AVR/MSP430.
очень красивый и понятный стиль исходников. только статическое (compile-time) выделение памяти. небольшой футпринт в памяти.

А кто вас просит открывать ваш код?
Где это такие странные требования?

Если меняете код самой ОС (например, новый порт или сервис) - таки да.
А ваши приложения - они ваши.
Я так понимаю.

Мне кажется после компиляции в бинарнике можно найти паттерны соответствующие определенному (скомпилированному тем же компилятором) коду. Таким образом если кто-то захочет докопаться то может это сделать, достаточно слить бинарник с устройства и провести такой анализ. Шифровать firmware можно далеко не в каждом дизайне.

Читаем:


Вот всё, что от вас требуется - оставить упоминание о копирайте в исходниках.

Вы о каких ОС сейчас говорите? Под какой лицензией?

Конкретно эта - scmRTOS.
Там же и ссылка сверху.

А вот FreeRTOS:




Холодильник - государственный.
А холод, который он производит - наш.

Соберите нужную конфигурацию и посмотрите. Будет не много (порядка десятков KB). Но на МК типа AT Tiny она однозначно не встанет ни в какой конфигурации
Конфигурируемостью.

Пока еще не умею с ней работать и думаю стоит ли учиться. Вижу она четко ориентированна на GCC. Я пользую IAR вместе со средой разработки. А что теперь? Куда это все прикручивать? Будет она работать с компилятором IAR? Драйверов под тот же STM32 в ней нет. То есть придется самому сначала делать порт.

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

Чем eCos лучше той же TNKernel или FreeRTOS? Вопрос к тем кто пользовался, почему вы остановились на eCos и какие ваши впечатления были потом? Я сейчас остаюсь в неведении о том, что выбрать. eCos привлекает тем, что в ней много разных пакетов, но впихуемость всего этого в тот же STM32 для меня остается под вопросом, в списке поддерживаемой аппаратуры eCos перечислены процессоры значительно более мощные нежели Cortex-M3.

Думается, что ОС это все же более менее универсальный компонент для разных проектов, выбранная ОС должна иметь как можно более широкие возможности и быть приемлемой в как можно более широком ряде проектов, чтобы использоваться одни и те же знания в большем числе проектов, сокращая время на изучения новых дублирующих инструментов/ресурсов.


Ок, в качестве компилятора принимается GCC. Какую можно использовать IDE? Нужна либо открытая, либо крякаемая. Желательно кроссплатформенная. Как и чем отлаживать программу? У меня JLink.

Eclipse, без вариантов
Вот, навскидку

Это ОС 'калибром покруче'. Она находится где то между этими ОС и 'большими' типа *Linux (в вариантах uLinux, RTLinux, и пр), WinCE, QNX и пр
Выбрали потому что подошла по требованиям/потребностям и позволила удалить все лишнее. Впечатления самые положительные
Скорее всего впихнется, но вот нужна ли она для STM32 действительно под вопросом. Какие требуются сервисы от ОС?

Eclipse уже советовали (хотя он несколько и монстрообразен). CodeBlocks можно посоветовать
gdb + OpenOCD

Планировщик, межпроцессное взаимодействие, файловая система, стек TCP/IP, сенсорный GUI для МК с LCD контроллером (напишем сами или вставим что-то, пока неизвестно что именно). Требования - минимум памяти, впихуемость в M3 или ARM7 без внешней RAM и MMU.


Можно NetBeans как-то прикрутить? Это сложно? Никогда ранее не видел ничего про использование этой среды для embedded и google ничего не нашел.

В принципе не очень много, можно и что попроще, чем eCos использовать.
Это отдельная песня. В eCos есть какой то uWindows, но насколько это юзабельно (и насчет сенсорного экрана) не скажу.
Можно

Дык, да. Вот я и думаю, что использовать. Пробовал скомпилировать eCos по книге с их сайта, установил Cygwin, что делать дальше не понимаю Не нравится мне эта линукс ориентированность, если так, тогда Linux и поставил бы только на более мощный процессор.
Пакет uWindows не нашел, и ничего подобного в исходниках тоже.

Круто, что можно использовать NetBeans, он намного легче и быстрее eclipse. Если чем-то хуже, то скажите вы. Как это сделать? Мне бы под IAR. К GCC не тянет, может опыта мало, не знаю. Но как-то темно и сложно в линуксах.

Что, точно?
Они ж оба на java написаны, принципиальной разницы быть не должно.
Я вот уже с год с нетбинсом работаю, так с P4HT@3GHz удрать пришлось на что-то поновее. На Core2Duo @ 2.4GHz гораздо лучше, но тоже иногда раздражает.

Пытался пробовать нетбинс, что-то ниасилил снаскоку.
Эклипс тяжеловат (хотя кто ж заставляет все навороты включать), я остановился на CodeBlocks.
Эклипс удобен тем, что под него много чего есть, включая доки и плагины.
Я даже ставил плагин под Symbian, правда HelloWorld скомпилил в КодеВарриоре

Если уж так нравится ИАР, то пробуйте то, что они советуют и официально поддерживают:


Ну и прикрутить компилятор ИАРа к сторонним IDE - это отдельная песня.
А штатная среда - это унылое г.. по сравнению практически с любой более-менее развитой IDE.

Если есть повод бросить эту дурную IDE - бросьте. У меня вот все повода не находится (новый проект, новая платформа...)

Дальше надо ставить конфигуратор (он там где то отдельно лежит). По нему можно прочувствовать объемы. Затем (или параллельно) надо ставить cross compiler (toolchain). Они есть уже в бинарном виде (но не все). Потом можно будет собирать приложение под eCos (просто запустив make из консоли cygwin'а)

eCos - это не Linux. Никаким боком!

Был, счас скачаю, гляну.

Кстати, STM32 процессор поддерживается:

STMicroelectronics STM32F102ZE (Cortex-M3) STMicroelectronics STM3210E-EVAL


Залез в их репозитарий, вот :

Лежит в packages/services/gfx/mw/current/

На практике разница ощутима, наверное по разному написаны. Попробуйте и убедитесь.


Среди тех ОС, которые официально поддерживает IAR только одна бесплатная, представляющая собой кастрированную версию платной.


Как именно бросить? Перейти на GCC? Сложно, очень и поддержка новых ядер появляется в последнюю очередь, эффективность компиляции намного меньше. Оставить от IAR только компилятор, тогда нужно суметь прикрутить.


Про линуксовость я имел в виду, что сей продукт требует инструментарий GCC и т. п. без вариантов. Как и откуда поставить конфигуратор и что такое toolchain - не догнал.

Угу. Но и gcc != Linux

Отсюда - http://www.ecoscentric.com/devzone/configtool.shtml
Кросс компилятор и дебагер под целевую платформу. Можно закачать как часть инсталяции самого eCos'а (см раздел 'eCos and Toolchain' в http://ecos.sourceware.org/getstart.html ) Или построить самому ( http://ecos.sourceware.org/build-toolchain.html )

Блин читаю все это, страшно становится

Давайте проще, помогите сравнить TNKernel и FreeRTOS. Кто чем лучше? Я заметил только, что FreeRTOS официально поддерживается IAR. Тут на форуме находил, что FreeRTOS якобы попроще и подеревяннее TNKernel. Что скажете?

И что скажете по поводу TN NET в качестве бесплатной добавки?