А чем не устраивает eCos?
Большой круг пользователей которые поддерживают саму ОС - вроде самый главный критерий оптимальности. Линковка своих приложений есть, без предоставления кода последних . И GPL на саму операционку.

Да в общем-то устраивает. Правда несколько громоздка она для простых применений. В добавок я gcc не люблю, привык к IAR. Хотя вообще говоря на досуге потихоньку с eCos разбираюсь.

В продолжение...
Разбирался тут с родными семафорами в FreeRTOS. Выяснилась неприятная вещь: ежели шлю сигнал через семафор от прерывания, а в некторой задаче жду его время N тиков операционки, например так:


то семафор реально захватывается задачей через N тиков операционки, а не сразу после того, как он был послан... В общем по-любому похоже надо свои семафоры заканчивать. Если кому интересно - думаю через месяц закончу, попробую заслать автору FreeRTOS. Если кто хочет потестировать - милости просим.

гм. а сам автор это как-нить комментирует? это же глюк, получается?

Руки не дошли пока ему написать, постараюсь в ближайшее время... Да и надо бы детальнее проверить...

Просьба держать в курсе!
Я похоже тоже избрал FreeRTOS, как отправную точку для создания
более ориентированной на себя системы. Вполне прозрачна на первый взгляд в своей начальной
простоте, хорошо читаемые исходники. До сих пор (скоро 15 лет) всегда делал более-менее свое ( в приглядку естественно ), а тут резко пошел на ARM...... Слишком бысто я в эту работу не вольюсь -
новый процессор, иннструментарий (правда готовый :-) ) - где-то порядка месяца на разборки :-(
в "рабочем порядке". Пока за вчера собрал (IAR) слегка помxав шашкой порт на LPC2124 - живет и общается с внешним миром.

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

Это что ж, на каждого абонента отдельный процесс? Зачем? Вытесняющая ОС имеет главное преимущество - детерминированное время отклика на событие. Если все абоненты равнозначны по приоритету - то их и должен обслуживать один процесс. Если есть разные группы абонентов - например, есть группа VIP, которая должна быть обслужена вперед других, то ее обслуживание поместить в другой процесс с более высоким приоритетом. Только и всего.

В общем, при использовании RTOS тоже ведь надо думать и грамотно проектировать систему. В этом случае все прекрасно ложится, ничего "в свисток" не уходит.

Процессы ОЧЕНЬ простые, код вылизывается, затрат на переключения контекста практически нет.
Лет ...надцать назад была еще одна причина - 8085/Z80 прцессор с 8K очень дорогой ROM,
ну RAM было больше и дешевле - 256 процессов и заметная экономия кода.

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

Наступил на проблему - незаметно съел heap, а у автора IDLE Task
создается из vTaskStartScheduler( ) последней! Ну и не хватило памяти под стек и не запустилась,
а за ней и шедулер не стартовал и полетело все далеко.
Три часа пляски - я уже думал отладчиком пользоваться придется :-).
До нехватки памяти я довольно быстро добрался, но думал менеджер памяти шалит - читал-читал..
В общем для профилактики дописал системный вызов xIdleTaskCreate( ) и поставил его
перед всеми, а в vTaskStartScheduler( ) для совместимости добавил контроль на запущенную
IDLE и создание ее в случае отсутствия. Хотя, наверное, и startup запихнуть можно.

Тож недавно начал юзать эту ось. Портировал на cx805 (ASIC телефона sgh-c100), работает. Были небольшие замороки с частью startup, исправить несложно. Для меня неудобно, что в ходе переключения контекста вызывается SWI (у меня свои виды на использование этого прерывания). А так, в целом нареканий пока нет.

Такие большие виды, что 8/24 битного поля 'соmment' не хватает для того, чтобы пожертвовать
одно значение для переключения контекста :-) ? Я понимаю, что текущий "порт" автора под
ARM сделан левой ногой, дабы "был", но подправить с использованием 'comment' что мешает?

В "portmacro.h"
#define portYIELD() asm ( "SWI 0" );

нолик заменить на любое число которое не жалко....

В "startup.s79" что-то типа:

ldr r0, [r14, #-4] ; Получить тело SWI инструкции
bic r0, r0, #0xFF000000 ; Почистить поля 'condinion' и 'F'

добавить и ветвится по 'r0' как душа пожелает