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]

Знаю что не влезет на мегу8,

А к чему тогда рассуждения про академичность? Есть реальная задача, есть потребность в интрументе для ее решения, есть адекватный инструмент. Найдите другое, такое же по характеристикам и лишенное указанных Вами недостатков?! Очень интересно посмотреть.

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

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

Возмите API, посмотрите возможности ядра
количество поддерживаемых задач - сколько вы будете делать bitmapsearch (поиск приоритета) для всех? Уснуть можно.

Да, только спать придется недолго. На MSP430 при 5 МГц тактовой (не самая скорость, прямо скажем) проверка признака активности процесса занимает 1.2 мкс. 8-й процесс будет обслужен на 8* 1.2=9.6 мкс позже первого, самого приоритетного, 15-й - на 18 мкс. Учитывая, что низкоприоритетные процессы, мягко говоря, не требуют мгновенной реакции, то добавка в несколько микросекунд для них совершенно ничего не решает. А для приоритетных, которым надо побыстрее, все получаестя максимально шустро. Что и надо. Еще раз повторю, что данный тривиальный механизм тут канает только благодаря исходной ориентированности на малое количество процессов. В этом ключевая фишка.

EventFlag в 1 bit - и это полноценный флаг?, вы их наплодите ровно в 8 или 16 раз больше, и соответсвенно займете память.

??? А сколько бит должен быть EventFlag? Это бинарный семафор. Сколько событий в системе, нуждающихся в синхронизации, столько и флагов. Все логично. Что не так?

семафоры

Что с ними не так? За исключением отсутствия горячо любимого Вами простого бинарного семафора.

Кстати, не приведете ли реальную задачу, где он реально нужен? Очень интересно рассмотреть ситуацию, которую нельзя обойти в scmRTOS за неимением оного семафора.

коды возврата вcех функций

Каких всех функций? Функций сервисов? Если Вы имеете в виду возвращаемый код ошибки в сервисах uCOS, то, имхо, это как раз слабое место этой ОС! Ведь это рантаймные проверки, и тут два принципиальных недостатка. Первое - это оврехед. Но это полбеды. Второе и главное - это то, что проверять/обрабатывать эти ошибки в ембеддед системе некому. Вот представьте, что функция pend вернула код ошибки - например, тип объекта не соответствует функции. Кто проверяет и обрабатывает код ошибки? Писать специальный код? Ну хорошо, написали. Что дальше? В лог его занести? Занесли. Что дальше? Программа-то от этого работоспособной не станет - все это годится только как средство отладки.

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

Так не более ли правильно все, что можно проверить на этапе компиляции, проверить на этапе компияции. Возложить эту работу на компилятор - статическая проверка типов - одна из ключевых концепций С++ (да и С, в общем-то, тоже). И тогда ни оверхеда, ни ошибок, делающих программу неработоспособной. Что и реализовано в scmRTOS: все сервисные объекты - отдельные типы, их нельзя использовать неправильно (и пользователь имеет доступ только к интерфейсу, но не к представлению) в смысле случайной ошибки (понятно, что от преднамеренного взлома ни язык, ни компилятор не защитят, но этого и не требуется).

обращения по именам

Не понял, что имеется в виду.

таймауты

Что не так с таймаутами?

различные состояния задачи
еще много чего ....

Какие состояния? Если упомнинаете что-то, то уж пожалуйста объясните по-подробнее, что имеется в виду, чтобы не гадать.

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

Ну, если запорожец ездит быстрее мерса, если пользоваться им проще и комфортнее, то да.