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

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

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

Для начала на ARM лучше FreeRTOS - ресурсов кушает поболе, но для ARM это менее критично, зато за счет этого более бескомпромисна и похожа на "большие" системы. От нее уже потом, как от серединки, можно в вверх/вниз двигаться.

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

Ещё: счас посмотрел - FreeRTOS на чистом си написана, без плюсов. Для кого-то это может быть важно.
Жалко, что порт для 449 мсп-шки только, а у меня 149, надо будет искать 10 отличий...

Памяти? Flash да, но и само ядро не минималистичное - нет ограничений на число задач и их приоритеты, таймерообразные вещи не в лоб сделаны, очереди и прочее суровее... Все это требует еще и времени.

Когда мне задают подобный вопрос, я отвечаю: основное отличие между этими ОС такое: Если вам не нужно в процессе работы программы создавать и удалять задачи, то вам подойдет scmRTOS и вы получите преимущества в скорости и количестве занимаемой памяти (как флеша, так и ОЗУ). Здесь на форуме была ветка, в которой я сравнивал эти ОС по памяти/скорости. Если вам надо динамически создавать/удалять задачи, то scmRTOS вам точно не подойдет, но вы можете посмотреть еще и на TNKernel, я ее не пробовал, но по отзывам она экономичнее FreeRTOS по памяти и пошустрее. Опять же, какой компилятор вы используете? scmRTOS на данный момент имеет "боевой" порт LPC только под IAR, в репозитории лежит рабочий, но довольно сырой порт под GCC дя AT91 и ADuC (пока нет возможности компилить ОС в thumb), портировать его на LPC дело буквально часа. Если вы используете Кейл, вам придется портировать ее самостоятельно.

Отнюдь, не только это. Просто на вскидку по функциональному минимуму:
1. Задачи с одинаковыми приоритетами (да, да, знаю, что в мануале scmRTOS пространно описана "ненужность", но лично мне нужно )
2. Количество задач - не столь важно, но тем не менее.
3. При большом количестве задач более простая организация тех-же таймеров scmRTOS начинает больше тормозить.
4. Функции API более простые, узкоспециализированнее их больше и они опаснее в использовании.
5. Вытесняющая и кооперативная многозадачность в одном флаконе.
Наверноее что-то еще забыл

А Вы только труды профессоров читаете ? Совершенно зря . И вообще никогда не высказываете СВОЕ мнение? Ну это Ваше право, только к чему совершенно непонятные упреки людям, которые выступают от своего имени?
Moderator:
То MacGregor - просьба высказываться по сути вопроса.

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

А вы загляните в исходники порта scmRTOS для ARM...
И приведите свои аргументы "за" и "против" обоих ОС.

Но это наиболее существенное (на мой взгляд) из отличий. Одинаковые приоритеты, да, согласен, плюс FreeROS. Количество задач - теоретически 64 для scmRTOS (практически сейчас 32). У меня пока больше 5 не было. Таймера - на большом количестве задач да, будет тормозить. На малом количестве - наоборот. Функции API - плюсовый компилятор гораздо строже к соответствию типов, так что насчет "опаснее" - спорно. Вытесняющая и кооперативная... А оно надо?

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

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

Сообщение отредактировал Цыкетчик - Sep 24 2008, 08:36