[bmf 0]

А если реализовывать по честному семафоры (как в той же uCos) - то придется уже вести их дополнительный список и просматривать его при каждом изменеии состояния задачи. Размер и сложность OC вырастет раза в два. После этогo smcRTOS - более правильно называть просто диспетчер с некоторыми фунциями API, пригодный для академических целях или когда уже деваться некуда из-за скудности ресурсов, но здесь уже как правило есть и другие альтернативы.

[dxp 50]

Ну например, для тойже uCos - реакция на прерывание - только установка семафора из макроса(не из функции!, с целью уменьшения загрузки)

Из какого макроса? О чем Вы говорите??

 

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

А сколько пройдет времени? Какого времени? С какого момента? О чем Вы говорите, не понимаю. "Здесь" при возникновении прерывания вызывается его обработчик, в котором на входе сохраняется контекст текущего процесса. Далее пользовательские действия, в т.ч. сигналится, например, флаг (и ожидающие процессы переводятся в готовые к выполнению). На выходе управление передается самому приоритетному из готовых к выполнению. Точно так же, как и в uCOS.

 

С++ ничего там не "наворочает". Совершенно! Возьмите хотя бы и посмотрите на кодогенерацию прежде чем такие выводы делать. Открою для Вас тайну - uCOS толще и тяжелее (и по размеру кода, и по требованиям к ОЗУ, и по быстродействию). Причем очень заметно - как бы не в два раза, если не больше. Из коммерческих ОСей тут гораздо лучше embOS - она близка по быстродействию к scmRTOS, хотя тоже уступает (я сравнивал их демо пример, где количество задач ограничено тремя). Тормоза и жручесть uCOS вполне объяснимы - там 64 задачи надо уметь обслуживать да еще и с возможностью инверсии приоритетов. Это бесплатно не дается.

 

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

И что это за стандарт такой, на основании которого сделана uCOS? Как называется?

 

Насколько я понял из откровений Лябрусса, свою ОС он писал для себя, для своих целей, т.к. продолжительное время не мог найти готового, удовлетворяющего его по цене и качеству. А потом опубликовал результат своей работы, который оказался востребованным. Успех uCOS в значительной мере обусловнен двумя обстоятельсвами: 1. работоспособное решение, основанное на реальных требованиях и реальных возможностях; 2. отличная книжка-введение в ОС РВ.

 

Чем он шире, тем естесвенно и более тежеловеснее будет OC, но пользователь все их может не использовать.

Нонсенс. Тяжеловесность ОС определяется не количеством сервисов, а базовыми механизмами ядра, организацией и менеджментом задач.

 

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

На мелочи 8/16-битной время, требуемое для реализации инверсии приоритетов, обычно соизмеримо (или даже больше), чем время занимаемое низкоприоритетным процессом при обращении его к совместному ресурсу. Т.е. инверсия приоритетов тут - это только лишние килобайты кода, лишнее (остродефицитное) ОЗУ и куча времени, проведенного внутри критических секций. Только и всего. И спросите у народа, кто пользуется uCOS, много ли они пользуются инверсией приоритетов в своих реальных проектах, и много ли прироста производительности (и смысла) в ней они там находят.

 

А чтоб объективно полность сравнить, набо провести тест, и замерить реакцию на прерывание, время переключения задач, занимаемая память и др, возможности API.

<{POST_SNAPBACK}>

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

[dxp 50]

И еще, посмотрите как в uCos ищется самая приоритетная задача, и как в smcRTOS или freeRTOS и увидите что время поска при любом переключении (через swithtask или при установке семафора) будет в 10 раз меньше.

<{POST_SNAPBACK}>

Насчет freeRTOS не скажу, давно уже не смотел в ее сторону. А про uCOS, конечно, знаю. Две итерации по таблице. При количестве процессов менее 8 это ДОЛЬШЕ, чем в scmRTOS, где просто тупой перебор-поиск признака активного процесса. В scmRTOS всего максимум может быть 15 пользовательских процессов, реально их бывает не более 8 (я не знаю никого, кто бы использовал больше на мелких МК с килобайтом-двумя ОЗУ). Поэтому в ее случае можно позволить себе максимально простой и легкий алгоритм поиска. С 64-мя задачами такого делать уже нельзя. В этом и состоит их главное отличие - бОльшая масса обладает бОльшей инерцией.

 

Насчет реальных времен переключения процессов: я проводил такой эксперимент: один процесс, более приоритетный, встает на ожидание флага. Другой процесс устанавливает ножку МК в 1 и сигналит флаг. Когда после этого ожидающий процесс получает управление, он сбрасывает ножку МК в 0. По длительности импульса и определяется время передачи уплавения между процессами. На MSP430F149 при тактовой частоте ~5 МГц на scmRTOS время было порядка 26-27 мкс, на uCOS - около 50 мкс (или около того, могу уже точные цифры наврать, давно было, но запомнилось, что где-то порядка двух раз). Комплятор в случае scmRTOS был IAR v2.0x, в случае uCOS - 1.26. Качество кодогенерации смотрел, никаких нареканий к 1.26 не помню. Причина, по которой использовалсь разные компиляторы - для scmRTOS нужны ++, для uCOS был порт под 1.26.

 

Т.ч. Ваши заявления про 10 раз - извините, бред с любой стороны (ни одна из ОС не имеет такого преимущества перед другой - максимум раза в три), и uCOS медленее. Не верите - возмите и проверьте сами.

[dxp 50]

А если реализовывать по честному семафоры (как в той же uCos) - то придется уже вести их дополнительный список и просматривать его при каждом изменеии состояния задачи.

А что значит "по-честному"? В чем состоит "честность"? Весь этот учет нужен для реализации инверсии приоритетов. Может они где и нужны, но не на MSP430 и не на AVR. scmRTOS ориентирована на эти МК - и вообще на однокристальные МК, где мало ОЗУ. Не нужна там эта ИП - небесплатно она дается. Если uCOS претендует на толстые процы с толстыми задачами, где это надо, то пожалуйста, я не оспариваю необходимости этого свойства в той нише. Но в этой нише сия фича выполняет роль грузила.

 

Размер и сложность OC вырастет раза в два. После этогo smcRTOS - более правильно называть просто диспетчер с некоторыми фунциями API, пригодный для академических целях или когда уже деваться некуда из-за скудности ресурсов, но здесь уже как правило есть и другие альтернативы.

<{POST_SNAPBACK}>

Называйте, как Вам угодно - от этого абсолютно ничего не меняется. scmRTOS очень похожа на uCOS - та же идеология, те же принципы. Реализация другая, оптимизированная под свою нишу.

 

Что касается "академичности", то вот возьмите-ка да и примените-ка uCOS на своей меге8. И расскажите после этого, как оно там легло. И для сравнения проделайте то же самое с scmRTOS. И сравните. По размеру кода, по требованиям к ОЗУ, по временам передачи управления/реакции на события. Интересно будет узнать, как Вам понравилось остутствие поддержки раздельных стеков для данных и адресов возвратов в uCOS. Может после этого у Вас возникнут мысли и о практичности. Мега8, кстати, уже не такой скудный МК - там целый килобайт ОЗУ!

[bmf 0]

Знаю что не влезет на мегу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 50]

Знаю что не влезет на мегу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.

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

[dxp 50]

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

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

 

 

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

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

 

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

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

 

Или "Такое планирование несколько сложнее простого приоритетного, а преимущества как-то не особенно заметны."

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

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

 

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

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

 

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

 

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

 

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

 

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

[dxp 50]

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

Попробуйте! Особенно интересно будет посмотреть, как Вы на С будете реализовывать инкапсуляцию, наследование и, особенно, шаблоны. И главное, смысла никакого в этом нет. Реализация на С++ имеет недостаток в силу меньшего распростанения этого языка, но и дает одно из главных преимуществ - простоту и безопасность использования. Использование действительно очень простое, проще некуда - я знаю несколько человек, которые в ++ почти ничего не понимают, однако безо всяких проблем используют scmRTOS, освоив буквально за пару дней.

 

Кстати bitmapserch в нормальных процессорах эта одна ассемблерная команда за один такт, здесь в том же ucos прощелкали, эту возможность, чтобы вынесте ее в порт.

Думаю, что ничего они не "прощелкали", а пошли на это сознательно. Лябрусс сразу сориентировался на 16 (и более) разядные процы с возможностью подключения внешней памяти (у него встречается недвусмысленное замечание о том, что на однокристаллках использование вытеснящей ОС очень затруднительно). Отсюда и количество задач до 64-х, отсюда и соответствующий механизм поиска активной задачи с наибольшим приоритетом, отсюда и таблица на 256 байт, объявленная как const - не жалко ему 256 байт, которые в Гарвардских процах размещаются в ОЗУ (хотя этого объема хватает для стеков двух-трех процессов). Потому что не ориентирована эта ОС на МК с малым количеством ОЗУ, и не ставилась никогда задача оптимизировать ОС под мелкие МК.

 

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

Ну, если Вы так круты, что фактически переписали uCOS, то добавить в scmRTOS простой бинарный семафор Вам ничего не должно стОить! Ведь там работы-то на полчаса - взять за основу TEventFlag, изменить пару строчек внутри его функций-членов да прописать новый тип внутри пространства имен OS. Во всяком случае, уже на эту дискуссию Вы потратили времени несравенно больше. :)

 

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

Э-э, пардон, а в uCOS что, не так, что-ли? Как Вы себе представляете переход из прерывания в другой процесс/задачу, если на входе не сохранили конекст текущей задачи?

 

Есть стройное и элегантное решение, состоящее в том, чтобы иметь в МК отдельное софтовое прерывание, которое и будет переключать конктексты, а все остальные прерывания сделать обычными, где при необходимости взводятся сервисы и выставляется запрос на софтовое прерывание - при выходе из обычного прерывания вызывается софтовое, которое и производит переключение контекстов. Но ни в AVR, ни в MSP430 такого прерывания нет, можно использовать какое-нибудь свободное, но тут уже все это получается проектнозависимое - в одном проекте так, в другом эдак... Скажу по секрету, что такая возможность в настоящее время серьезно рассматривается и в одной из будущих версий scmRTOS этот механизм появится.

 

И кстати почему то все солидные фирмы скромно называют свою embedded RTOS - или кернелом или биосом и

Ага, особенно uCOS. Или embOS. Или Salvo. Или jacOS.

 

только новоиспеченные кричат о свох продуктах как о OS, до которой в полном смысле этого слова им ... .

:laugh: Для начала дайте четкое определение термину "Система". Потом термину "Операционная система". Потом сделаем выводы.

 

Подумайте над такой вещью. Мерседес - это автомбиль? А Вольво? А Фольксваген-жук? А Тойота Королла? А Хаммер? А Зил-130? А Камаз? А БелАЗ? А Ока?

 

А Ту-154 - самолет? А Боинг-747? А Су-27? А Антей? А Сесна? Или Сесна - это фанера с моторчиком?

 

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

 

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

 

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

 

Таким образом, любая OS, RTOS, Kernel и т.д. на деле являются именно системами и ничем иным. А конкретное название - это не более, чем маркетинговый ход, имеющий целью выделить свое поделие из общего количества аналогичных и/или подчеркнуть ключевую особенность - как в случае с uCOS, где сказано, что она The Real-Time Kernel, что понимай как: "У нас тут не хрен в сметане, а ядро реального времени!". :)

 

smcKernel отражало внутренности гораздо вернее.

Совершенно не так! Kernel там есть и представлен в виде class Kernel. А все вместе именно система, хоть и маленькая, можно сказать крошечная.

 

Даже в ucos потом дописали "Real-Time kernel".

Это не потом, а сразу. Только это не дописка, а нечто вроде расшифровки - дескать, ОС с ядром реального времени.

 

P.S. Ответ пришлось разбить на три сообщения, потому что в одном большом не работает квотинг, а без него читабельность, имхо, неудовлетворительная. :)

[bmf 0]

На каждый ваш лист, я смогу аргументированно ответить своими тремя, на которые я не сомневаюсь вы ответите уже 9.

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

 

Мы просто немного смотрим на одно и тоже с разных позиций или говорим о разном.

Чем продолжать ее дальше - лучше по вашему же совету заняться делом.

 

и ИМХО иногда Вы не логичны, перевираете, недоговариваете или говорите совсем о другом.

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

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

а скрыть внутренне представление оно в C легко скрывается. А шаблоны, то вообще на любителя, и кто то советовал из совсем не использовать.

И вся эта концепция красота vs. эффективность. под большим вопросом. И такая простота больше нужна студентам первых курсов, чем для промышленных решений.

 

Ну, если Вы так круты, что фактически переписали uCOS, то добавить в scmRTOS простой бинарный семафор Вам ничего не должно стОить!

и ничего в этом крутого нет, это под силу среднему программисту и даже хорошему студенту. Как то напал на японский сайт, так там неисчислимое море этих rtos - написанных ихними обычными студентами, для них это в порядке вещей.

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

 

Есть стройное и элегантное решение, состоящее в том, чтобы иметь в МК отдельное софтовое прерывание, ...

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

 

а насчет, другой ОС для меги8- повторяю , для данной задачи мне более подойдет avrX на ассемблере - полный preemptive и Round-Robin в одном флаконе и мои любимые семафоры и 500 байт footprint. вот вся и арифметика.

 

Или что мешает переписать ту же ucos, выкинув инверсию приоритетов и оставив 8 или 16 задач и иметь в распоряжении все типовое API. При существующих портах это сразу накроет большинство микроконтроллеров. Лично мне это не нужно, каждый занимается тем что ему интересно или за что платят деньги.

 

smcRTOS на своем текущем этапе более интересна в академических целях, если вам будет легче, то это моя частная точка зрения, не более.

и как Вы ее яросно защищаете, говорит что она еще может не остановилась в своем развитии.

И если вы считаете что то иначе, то это ваша точка зрения.

 

И кроме нас с вами, все о чем мы говорили здесь никого не интересует(к сожалению) и все что я высказал как сторонний и

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

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

 

И я признаю что smcRTOS несомненно задумана как красивая, элегантная и простая, и посмотреть как внутри все устроено стоит того, чего и всем желаю.

[bmf 0]

Теперь о позитиве.

 

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

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

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

Сделать всего 8 или 16 только не задач, а приоритетов, а остальное по Round-Robin,

хотя бы опционно. И конечно же расширить API, более привычно к той же ucos.

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

Больная тема порты. В некоммерческом проекте все охватить не реально.

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

 

Имея опыт работы с AD, к слову неплохо ляжет на 2191 и Blackfin, и сам бы прикрутил их для своих задач, вот и новые порты.

 

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

[IgorKossak 0]

В доке к версии 2.0 такого обзаца нет.

<{POST_SNAPBACK}>

Есть на странице 25.

А чем, собственно, mutex не устраивает.

Я, например его именно как семафор и использую.

[bmf 0]

Придется его такой и использовать.

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

[dxp 50]

А чем, собственно, mutex не устраивает.

Я, например его именно как семафор и использую.

<{POST_SNAPBACK}>

А как Вы его используете? Там ведь на ожидание можно встать только если мутекс захвачен другим процессом.

[bmf 0]

Да все уже получилось не так, как вначале задумавылось :(

Время реакции на прерывание (имеется ввиду задержка начала выполнения первых полезных инструкций кода прерывания) в preemtive RTOS типа AvrX или smcRTOS слишком большое (теоретически если процессор уже находится в состоянии переключения на какую любо задачу то 2*время_полн_сохр_контекста + время_полн_вост_контекста) и это вместо того чтобы просто сделать какой либо ответ на прерывании в самом теле процедуры и выставить семафор, и лучше счетный, что бы знать сколько надо еще потом пропущенных прерываний обслужить.

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

В итоге альтернативе простой cooperative RTOS не нашел, все преимущества preemtive при большом колличестве задач или недостатке памяти и требовании скоростного обслуживания прерываний испарились.

Да и лишние 300 байт кода на поддержку preemtive по сравнению cooperative, когда все и так еле лезет, не лишние.