scmRTOS - где семафоры? Опции

[bmf]

Хотел попробовать, стал разбираться и не нашел семафоров.
Может я чего не понял?
Есть TEventFlag - но это немножко другое (после "сигнала" все процессы,
ожидающие указанное событие, будут переведены в состояние готовых к выполнению)
Более похож TMutex - но тоже вроде не то.
Кто работал? В чем фишка?

[bmf]

Знаю что не влезет на мегу8, поэтому и ищу вариант для уже написанного кода в jacOS, и в силу некоторых причин надо на preemptive OS.

Напомню, что основный вопрос разногласий "а чем smсRTOS хуже ucos (по концепции построения)"

Вы все прекрасно понимаете.

Возмите API, посмотрите возможности ядра
количество поддерживаемых задач - сколько вы будете делать bitmapsearch (поиск приоритета) для всех? Уснуть можно.
EventFlag в 1 bit - и это полноценный флаг?, вы их наплодите ровно в 8 или 16 раз больше, и соответсвенно займете память.
семафоры
коды возврата вcех функций
обращения по именам
таймауты
различные состояния задачи
еще много чего ....

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

Вы скажете что вам всего этого и не нужно, и правильно.
Если покупаете запорожец, то вы знаете зачем и для чего он вам нужен, а вы пытаетесь впарить его как мерс.
Как smcRTOS запорожец по отношению ucos, так и оная тоже самое по отношению скажем mITRON.

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

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

Вот после устранения указанных недочетов (и конечно портируемости) она действительна станет серьезным конкурентом ucos.
И проблем переписать ее на простом C для улучшения портируемости нет никаких, только вся целостность как ОС сразу пропадет.
Кстати bitmapserch в нормальных процессорах эта одна ассемблерная команда за один такт, здесь в том же ucos прощелкали, эту возможность, чтобы вынесте ее в порт.

Насчет макроса, здесь я ошибся, использую свой порт, а там от оригинального ucos мало чего осталось, но такая возможность принципиально есть.

Про прерывание я имел ввиду случай, когда не надо будет переключать контекст при ввходе/выходе, в smcRTOS это обязательно, независимо от будет ли выполняться само переключение, таких ситуаций в жизни предостаточно.

Воспринимайте сказанное как стороннюю оценку, насколько объективную вы сами решите, мне по большому счету побарабану, я просто высказываю свое мнение.
И кстати почему то все солидные фирмы скромно называют свою embedded RTOS - или кернелом или биосом и только новоиспеченные кричат о свох продуктах как о OS, до которой в полном смысле этого слова им ... .
smcKernel отражало внутренности гораздо вернее. Даже в ucos потом дописали "Real-Time kernel".