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

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

Блин. Нет такого в доке.
И не может быть.
Наоборот из ядра и семафоров можно сделать все остальное. Это базовые составляющие минимального размера. В принципе и мне нужно только ядро и семофор, кстати часто вызываемый из прерывания (и в других ОС специально делается легковесный код семафора для вызова из прерывания, чтобы не нагружать стек, здесь такого нет).

Надо дудет разбираться в исходниках: может вместо семафора он подрузамевает TEventFlag (хотя по устоявшейся терминологиии это должны быть разные вещи)

Вообще не умаляя достоинств автора, чувствуется некоторая безапеляционность в сужденияж
Как то:

Типа: Ну конечно они дураки, а мы умней

=============================================
Как видно из приведенного выше списка, отсутствуют счет-
ные семафоры. Причина этого в том, что при всем желании не
удалось увидеть острой необходимости в них. Ресурсы, которые
нуждаются в контроле с помощью счетных семафоров, находятся
в остром дефиците в однокристальных МК, это прежде всего —
оперативная память. А ситуации, где все же необходимо контро-
лировать доступное количество, обходятся с помощью объектов
типа TChannel и MemoryManager, внутри которых в том или ином
виде уже реализован соответствующий механизм.
================ Версия 1.01 25 =================

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

А насчет АВР - это еще мягко сказано. Неуклюжая архитектура и все тут. Сравните порт для МСП и для АВР и все вопросы отпадут.
Насколько мне известно автор портировал ОС на АВР не из-за "красоты изящества и оптимальности" архитектуры последнего, а по просьбе своих коллег.

Что касается личности автора, я имел удовольствие обсуждать некоторые общие темы и могу сказать, что это вполне приятный человек и очень опытный разработчик. Не в пример многим звездам 3.14здабольства с телесистем, кичащимся своими "тяжеловесными" никами.

В доке к версии 2.0 такого обзаца нет.
Думаю что как раз реализация семафора будет по коду гораздо меньше и эффективней чем TChannel и MemoryManager, а не наоборот, делать элементарный семафор из них. Ведь мы работаем при недостатке памяти и ресурсов.

К автору OS, я конечно же отношусь с уважением, без него и небыло что обсуждать, но хочется выбрать для себя верное и правильное решение.
А убогость архитектуры с одной стороны, может выливаться преимуществом в другой. Это вопрос сложный. И с одной колокольни об этом судить не стоит, надо учитывать доводы всех сторон. Но это совсем другая история.

В общем, теперь ясно что имеем. Thanks.

Есть.


Надо бы уточнить, что Вы понимаете под термином "семафар". Мутекс - семфор. И флаг события тоже семафор. Нет счетных семафоров? Да, нету. А они нужны? Приведите реальный пример на мелкой однокристаллке, где они нужны.


А что, не так, что-ли? AVR (ядро) по некоторым данным разработатли два студента из Норвегии. И задумка у них неплохая была, но вот реализация подкачала. Вот этот самый указатель стека - совершенно убогий! Ведь именно из-за этого IAR городит отдельный стек для данных. Два стека - это криво, преимуществ никаких, одни недостатки. А ведь будь указатель стека нормальный, то и не было бы никакой необходимости в отдельном стеке данных. Для стека данных нужно, чтобы указатель стека поддерживал расширенные режимы адресации (со смещениями) и адресную арифметику. Т.е. по-нормальному указатель стека должен быть регистровой парой. А в таком виде, как он есть - отстой.

Второй момент. У AVR слишком дофига регистров при том, что работа с ними неортогональна (младшая половина не работает, например, с константами). Гораздо лучше было бы если бы было регистров вдвое меньше (16), но все они были одинаковы и все они могли образовывать регистровые пары при адресации (т.е. быть указателями) и при адресной арифметике. Анализ кода показал, что в AVR заметный оверхед на пересылках адресов между регистрами, а нормальных поинтеров только два (из которых один отдан по указатель стека - Y). Реально в программе доступен только один Z, а X - недоделанный, не поддерживает адресацию со смещением. Вся эта кривизна очень распрекрасно видна при сравнении, например, с MSP430.

Третий момент - работа с памятью. Она медленная. Для Load/Store архитектуры работа с памятью должна быть максимально быстрой - ведь это ключевой момент, определящий быстродействие. Два такта на одно обращение - никуда не годится. Элементарный инкремент переменной в памяти занимает 5 тактов. из которых 4 - это накладные расходы на пересылку. Никуда не годится!

Это только основные моменты, но они, имхо, определяющие. Недоделанный он, AVR этот.

Все есть. Дока версии 2.0, ревизия 22, страница 25.


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

В версии 2, кстати, лучше уже не юзать TChannel (а MemoryManager'а там вообще нет - не нужен он стал при наличие подержки шаблонов). Есть шаблон channel, на нем все прекрасно реализуется и пользоваться им проще и безопаснее. Единственно, что надо помнить - это то, что на шаблонах очень легко и просто нагенерить горы кода. Поэтому тут надо прявлять осмотрительность (в частности, не городить каналы на объекты типов со значительным размером - ведь проталкиваение через канал производится путем копирования. Тут накладные расходы на копирование могут быть весьма неслабыми).

Вообще то чаще нужен простой бинарный. А Мутекс и Флаг события - работают здесь по другому, обратите внимание в обычном семафоре после "сигнал" только событие с большим приоритетом переведется в состояние работы, а у флага - все события которые имеют этот флаг, сначала естественно с вышим преоритетом, затем и все остальные. Совсем другая функциональность. Я не знаю никакой другой RTOS, гдебы не было этих обычных семафоров как базовый элемент взаимодействия.

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

По архитектуре: - я в основною юзаю DSP - там тоже применяют два стека (реально даже больше - еще для аппаратных циклов)- только это преимущество - быстрее реакция на прерывание
А что медленно работает с памятью - так это за один так пре тех частотах не зделаешь, у микрочипа любая команда 4 такта. И большое колличество регистров наверно как раз и должно компенсировать.
Так что все дело с какой стороны смотреть.
И все вышесказонное естественно ИМХНО.

Флаг - да. А если события ожидают несколько процессов, то как их все проинформировать? Заводить для каждого объект и сигналить всю пачку? Некузяво. Но если вас такое устраивает, то и заводите просто для каждого процесса свой TEventFlag, получите ровно то, что хотите. Флаг событий не заставляет использовать его одного.

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

С другой стороны, когда несколько процессов ждут какого-то события, это, как правило, означает, что событие это широковещательное. Такая ситуация у меня была: пришла команда снаружи, все ожидающие ее проснулись. Коротко, предсказуемо и эффективно.

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

Каких сервисов Вам не хватает?


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


Ну вообще-то, это не официальный документ, а частное описалово. Стиль там вполне свободный и даже анекдоты кое-где в качестве эпиграфов присутствуют. Т.ч. все вполне в "духе".


А вот это Вы зря - ничего подобного там нет и не просматривается. Есть только то, что сказано. И сказано по делу: в AVR указатель стека кривой! Это факт! Указатель стека - это один из ключевых компонентов процессора, "заточенного" под использование ЯВУ Си - об этом (особенно первое время) Атмел свистел на всех углах, заявляя, что, дескать, соорудили офигительно эффективный для С процессор, не в последней степени благодаря тесному сотрудничеству со специалистами по компиляторам фирмы IAR Systems. Как же так?!! Они его (процессор) специально делали эффективным для С, а указатель стека - ключевой компонент для эффктивной косвенной адресации, которую интенсивно используют С-компиляторы, - сделали убогим (именно убогим, если выражаться цензурно ). Что-то тут не складывается.


Извините, у DSP стек возвратов частенько аппаратный. Либо имеет отдельную память со своими шинами для этого. Чтобы параллельности достичь. А на AVR два стека тут совершенно ничего не дают - шина-то одна, все равно адрес возврата в память последовательно складыватся/извлекается - из-за чего и время реакции на прерывание 4 такта. Никакой параллельности нет. Недодуманный он, недоделанный.


А с какой не смотри - вон у ТМСов с черными финами тактовые не в пример выше, а в память за такт лазят. Да еще и два раза (параллельно). Какая проблема за такт обратится к памяти? Частоты, можно сказать, детские. И ограничиваются они не логикой, а флешью. Вон FPSLIC из ОЗУ весь работает, так там он с самого начала, afair, за 30 МГц имел частоты. Не проблема. Думается, что и этот момент просто недодуманный, недоделанный. Как и перебор с регистрами и их функциональность.

Спасибо за идеи.
В принципе если есть исходники, то реализация семафора по аналогии с флагом и мютекс вроде не сложна. У меня вопрос только почему этого нет в базовом наборе? В моем коде и то что я видел как раз 99% занимают обычные и счетные семафоры. Например возмите любой TCP порт для RTOS, как пример функционального применения мзаимодействия между процессами. Заменять где возможно это на мютекс и на использование несколько флагов - извращение.
Растет память, мютекс вообще не имееет состоятия "сигнал" и таймаутов. Флаг уже не используешь в теле функции, которую могут вызывать несколько процессов.
Вообщето для сябя я решил лучше попробовать avrx - там как раз та концепция, которою я придерживаюсь. Дя и сомнения в эффективности языка C++ кода для этого и в частности в обработке прерываний, хотя идея его использования безусловно красивая.

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

С++ в данном случае на самом деле дает не столько "красивость" сколько простоту использования. Есть объект, его потроха пользователя не интересуют. Пользователь работает через интерфейс. Интерфейс очень простой. Я знаю несколько человек, которые вообще С++ почти не знают, только С, но они вполне успешно и безо всяких трудностей используют данную ОС. Говорят, что пользоватся очень просто и комфортно, с чем согласен - это и есть главная цель использования ++ в данном случае.

Не знаю, впринципе всего десяток функций, там и собственно скрывать нечего.
А C++ можно натянуть на любую реализацию, как например ADSP VDK Kernel -хочеш юзай ассемблер, хочешь С или классы C++, а под низом ассемблерный код без потери эффективности. Это я в тему изначальной красивости (но с реальной потерей производительности и ресурсов). Всетаки ниша этой ОС слабые микроконтроллеры, ниже работают кооперативные OC, а ваше уже можно использовать и посолидней типа uCos. Прослойка очень тонка. У меня например использование для ATMEGА8.

Десяток - не десяток, а реально чем проще использование, тем лучше. Сравните, что проще, наглядее и удобнее - создать флаг в этой ОС или семафор в uCOS. Там для этого вызывается отдельная функция с кучей параметров - попробуй еще ошибись, проверки все, afair, на рантайме (а кто их на рантайме чекает?). И pend там тоже тяжелее, замороченнее - надо адрес руками передавать. А тут не надо - this компилятор автоматом мечет. Вот и преимущество. Мелочь, а удобно.

И чем это uCOS "посолидней"? Наличием поддержки инверсии приоритетов? Инверсия приоритетов на той мелочи, куда оно ориентировано - от лукавого. Имхо. В остальном все очень похоже - идеология та же самая. Только uCOS поддерживает больше задач (что тоже реально на мелочи не нужно, да и 15 процессов - не мало), поэтому имеет более сложный, тяжелый и медленный планировщик.

На мегу8 uCOS не ложится, а эта - пожалуйста. ++ совершенно не мешают, только помогают. К тому же шаблоны очень даже кстати.

Ну например, для тойже uCos - реакция на прерывание - только установка семафора из макроса(не из функции!, с целью уменьшения загрузки) и вызов IntExit(). А здесь сколько пройдет времени для вызова системной функции, полная перезагрузка стека, потом C++ хрен знает что наворочает, потом восстановление стека. Раз в 10 набежит.
Опятьже в uCos полный базисный набор функций для взаимодействия, и вообще то набор этих функций берется не от балды а в соответствии с индустриальнымы стандартом. Чем он шире, тем естесвенно и более тежеловеснее будет OC, но пользователь все их может не использовать.
Почитайте например спецификацию uTRON, это то что японцы требуют для ОС ембеддед систем (например для использования обычном автомобиле), даже uCos не потянет.
Инвесия приоритетов, тоже согласитесь, чтобы передать управление другому равнозначному процессу, а приоритет нельзя использовать тот же, приходится как-то изголятся.
А чтоб объективно полность сравнить, набо провести тест, и замерить реакцию на прерывание, время переключения задач, занимаемая память и др, возможности API.

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

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

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


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

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


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

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


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


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


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

Насчет 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 медленее. Не верите - возмите и проверьте сами.

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


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

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

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

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


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


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


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


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

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


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

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

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


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


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


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


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

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



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


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


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


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

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

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

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

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

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


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


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


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

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


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


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

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

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

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

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

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

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


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


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

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

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

Мы просто немного смотрим на одно и тоже с разных позиций или говорим о разном.
Чем продолжать ее дальше - лучше по вашему же совету заняться делом.

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

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


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


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

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

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

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

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

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

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


Учитывая лицензионную политику micrium, шансы очень даже не плохи. Только ориентация нужна на немногим более
жирные процы, тогда и c++ заиграет на всю катушку, а то получается, что жалуемся на нехвату ресурсов, а отказываем себе так сказать в необходимом, и сами используем ЯВУ.
Сделать всего 8 или 16 только не задач, а приоритетов, а остальное по Round-Robin,
хотя бы опционно. И конечно же расширить API, более привычно к той же ucos.
О разделении переключения контекста через прерывания и софтверно уже писалось. Для конечного пользователя код вырастет не намного больше чем был ранее или останется таким же, учитывая опционность компиляции.
Больная тема порты. В некоммерческом проекте все охватить не реально.
Но при таком более широком подходе и количество желающих портануть для себя возрастет.

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

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

Есть на странице 25.
А чем, собственно, mutex не устраивает.
Я, например его именно как семафор и использую.

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

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

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