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".

[dxp]

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

А что, разве не понятно? Там ведь прямо сказано и не в одном месте, что ОС очень маленькая, что используются очень простые, можно сказать, тривиальные механизмы, что ориентировано и заточено все это под мелкие однокристалки с объемом ОЗУ от полкилобайта до двух. Неужели Вы это пропустили? Описание-то там совсем небольшое, страниц на 90 вместе с оглавлением, предметным указателем и приложениями.

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

"Типовой API" - понятие непонятное. Для Вас типовой - это одно, для меня - другое. Реально есть работающий код и мне очень интересно посмотреть на ситуацию, где Вам действительно чего-то не хватит по функциональности, особенно в теперешей версии с шаблонными сервисами, где можно легко и безопасно создавать очереди сообщений произвольного типа.

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

Ну давайте, покажите уже реальную ситуацию, где Вам не хватает имеющегося.

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

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

Вот после устранения указанных недочетов (и конечно портируемости) она действительна станет серьезным конкурентом ucos.

Она никогда не станет конкурентом uCOS! Она:

во-первых, ориентирована на другую нишу - uCOS туда не лезет;

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

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

Список можно продолжить, но этих основных причин более чем достаточно.