Да нету там никаких 40 процентов
Исходные условия:
- STM32F103RG
- тактовая частота ядра 72МГц
- тактовая частота шины периферии 36МГц
- исполнение из флеша с 2 тактами ожидания
- печатная плата - стартеркит от Терраэлектроники
- компилятор IAR 6.30
- максимальные оптимизации по скорости

Тестовый алгоритм такой:
- имеется две задачи - 1 и 2
- приоритет задачи 1 выше (более приоритетная) чем у задачи 2
- задача 1 в бесконечном цикле
{
ждет синхрообъект (семафор для TNKernel и ef для scmRTOS)
после срабатывания синхрообъекта сбрасывает тестовый пин GPIO
}
- задача 2 в бесконечном цикле
{
спит 10 мс
устанавливает тестовый пин GPIO
сигналит синхрообъектом задаче 2
}

В итоге осциллографом наблюдаем импульсы положительной полярности длительностью несколько микросекунд с частотой следования 100 Герц.

Примечание:
Для SCM выполнена дополнительная оптимизация кода (отличие от релизной версии) предложенная AHTOXA - внесена инструкция
"bl os_context_switch_hook" в файле OS_Target_asm.s

Для SCM за основу взял проект 1-EventFlag для порта на STM32F1xx. Tрадиционно помучался со средой (а почему это у вас там есть конфигурация Release которая нихрена не компилируется?), в итоге пришлось проходить все опции ручками - выбирать тагет, включать оптмизации, и прочее. Вкрутил свой код настройки тактовой частоты и флеша. Итоговый результат - длительность тестового импульса 2.72мкс.

Потом взял свой проект на TNKernel, тот же самый код инициализации тактового генератора, тот же самый тестовый алгоритм.
Отключил отладку и всякие плюшки типа профайлера времени исполнения задачи - оп-па, импульс 4.04 мкс. Не, такого не бывает, я же железобетонно уверен. Ага - забыли оптимизацию по скорости включить - 3.56 мкс. Ну не может быть. Полез ковыряться, в итоге нарыл у себя глюк в порту - запрос PendSV избыточно вызывался дважды (это я давно перестраховался при разработке порта и потом забыл убрать, так что уже сегодняшний вечер провел с пользой ). Откорректировал, тестим - 2.88мкс. Та не (ТМ), ага - 5.41 компилируется, а надо 6.30 (как было для SCM). Берем 6.30 - итого 2.76мкс . Кстати 6.30 глючный при высоких степенях оптимизации, я его не использую. Еще немного поигрался с оптимизациями - но начали видимо играть начальные выравнивания функций, уже тут эти такты выловить сложно - было от 2.64 до 3.10 мкс, поэтому за пруф результат все-таки принимаю 2.76.

Итоговый результат длительностей наблюдаемых импульсов:
scmRTOS - 2.72 мкс
TNKernel - 2.76 мкс

Ессно, никаких 40 процентов тут и близко нету, так что "Пастернака надо-таки читать", ага
Я не берусь утверждать что тут эта разница именно из-за более сложного диспетчера - уж очень разные ОС и много факторов влияет.
Но то что двухуровневый диспетчер с round-robin-ом вещь совсем не аццки сложная и медленная - это экспериментально доказанный факт.

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

ну, наверное, можно запилить в scmTROS сущность, которой скармливается лишь битовая маска процессов которым надо карусель устроить и эта сущность каждые N системных тиков будет на время насильно усыплять очередной процесс из этой маски если он активен, таким образом давая поработать другим хоть и с меньшим приоритетом, таким образом чужие библиотеки которые внутри что-то поллят вполне могут работать по очереди? или так не получится?
накладных расходов на такой псевдо round-robbin вроде никаких.

Вы слишком спешите с выводами. Нет никаких "конкурентных" потоков у периферии. Если от UARTa идут строки запросов, то они идут в строго определенный интерпретатор этих запрсов. И никто другой туда не сунется. То же самое, инапример, с Ethernet MAC-ом, после выделения, HTTP запросы поступают в строго определенный интерпретатор, и тоже никто к этому WEB серверу не сунется с чем-то другим. О каких таких "конкурентных потоках" вы говорите? Я их не наблюдаю.

Наверное вы не поняли, что задачей в моем случае является ISR, которая оформлена в виде защищенного метода в классе с защищенными данными. Никто туда, кроме методов самого класса добраться не может. Какие такие "конкурентные потоки"? Можете представить конкретный пример?




Я видимо чего-то упустил, но по-моему CGI основано на использовании .dll в серверах на ПК? При чем тут scmRTOS для малых 8-ми разрядных чипов?

Давайте всё же уточним, что это не Пастернак, а сильно допиленное чудовище Франкенштейна, причём в данный момент никем, кроме самого Франкенштейна не проверяемое
ЗЫ. У меня, кстати, получилось 2.55 мкс (scmRTOS 4.0/GCC).

CGI это несколько более широкая концепция. Имхо, под CGI следует понимать такое - поступает HTTP-запрос, сервер принимает заголовок запроса, определяет имя ресурса. Если это имя является именем скрипта (неважно на каком языке написанном - Ява, Перл, Питон, ПХП, или это вообще может быть приложение на С/С++), то сервер запускает этот скрипт и дальнейший поток данных входящего HTTP-запроса (тело, если оно есть) перенаправляется в stdin порожденного скрипта. А поток stdout, генерируемый скриптом, сервером также перехватывается и отправляется как ответ на HTTP-запрос удаленному хосту. Так вот, веберы (разработчики сайтов) поднакопили некоторый багаж алгоритмов и опыт разработки таких скриптов, принудить их поддерживать явный кооператив сложновато. К тому же обычно из этих скриптов (во встраиваемом сервере это просто процедуры на C/C++ выполняемые в отдельном порожденном потоке) требуется доступ к аппаратуре или внутренним базам данных устройства, например, оно как выдаст "SELECT к внутреннему SQL-серверу" - какой уж тут кооператив.

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

Да я-то понял. Это вы никак не можете понять, что совершенно неважно, каким образом вы обращаетесь к данным - напрямую или же из защищённого метода. Если вы обращаетесь к ним из разных потоков выполнения (ISR в вашем случае), то необходима синхронизация. И никакие защищённые методы её обеспечить не могут.
Вот приняли вы по UART-у, скажем, команду на изменение конфигурации веб-сервера. И что с ней делать? Как аккуратно изменить эту конфигурацию, не повредив работе веб-сервера?

О как завернули. Да не вопрос - приглашаю в гости на демонстрацию, если, канешна, Франкенштейна не боитесь . Ну еще могу, например, уважаемого ReAl в гости пригласить в качестве независимого арбитра . Или скажете, что я арбитра пивом напоил и он не те цифры подтвердит?


Да, GCC (начиная с 4.x) очень неплохой компилятор, и я очень серьезно думаю о переходе на него. Но это не завтра, но как поробую - отпишусь о результатах.
Вы мне лучше скажите почему SCM такая медленная? Я тут почитал Пастернака посмотрел исходники - перевод процесса из NonReady->Ready делается действительно коррекцией битовой маски. TNKernel же делает кучу работы - удаляет процесс из списка синхрообъекта, где тот коротал время в состоянии non-runnable, переносит в список активных диспетчера, и все равно - разницы во времени даже несчастных 40 процентов нету

Да не, я не о том Я верю вам и так. Но это не TNKernel, вернее, не тот TNKernel, который можно скачать и поковырять.

~180 циклов - медленная? Тут скорее вопрос - как это TNKernel умудряется сделать такую кучу работы за столь короткий промежуток!
ЗЫ. А ReAl-а пивом - напоИте, это дело благое

Пробовал. Не получается Он предпочитает коньяк или хороший чай.

Интересная идея, спасибо - надо будет попробовать. Но опять-таки "сущность" не так прозрачна как одинаковые приоритеты.

Дык, если время блокировки объекта соизмеримо или меньше затрат на инверсию приоритетов (это довольно накладное действие), то зачем это делать. А обработка шарных ресурсов, где нужна гарантия того, что время обработки было минимальным, делается опять же через делегирование действий foreground процессу, в документации этот приём подробно описан.

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

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

Нет, scmRTOS мне очень нравится - красиво и талантливо написана, очень шустрая, опять-таки на C++ (подтверждает тот факт что "кошек надо уметь готовить"). Но некоторые архитектурные ограничения - расстраивают. Понятно почему так сделано и откуда оно появилось. Но дальше, имхо, будет становиться печальнее - 32-битники уже серьезно на рынке, давят в том числе ценой тоже. Мелкобитники, конечно, не умрут, но ниша их пожмется хорошо так. И архитектурные ограничения принятые ради мелкобитников будут расстраивать все сильнее и сильнее . Поэтому я в своих портах TNKernel на мелкобитники сознательно "забил" - тоже свого рода ограничение.


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

Насколько я понял, вы реализуете готовые приемы, написанные дизайнерами сайтов? Может, в этом случае проще обратиться к готовым решениям на базе Linux для микроконтроллеров, а не тратить время на scmRTOS, предназначенную для малых кристаллов c ограниченными возможностями?


Вот этого я не понял. С ответом на запрос по-моему в жизни никто особенно не торопит. Так зачем тогда все эти "приоритеты и вытеснения" именно для скриптов? Торопиться здесь надо только в одном месте- там, где входящие пакеты вываливаются из MAC, их нужно фильтровать, сортировать и выделять непосредственно http-query. А потом, с интерпретатором и скриптами, уже никакой гонки нет.


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



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


Как и обычно делают провайдеры, когда идет перепрошивка сайта- останавливают на какое-то время работу web-сервера, клиентам на запросы он выдает ошибку 500- busy, и занимаются переконфигурацией сколько надо времени. Вот, и вся синхронизация.

Линукс не подходит по ряду причин. Готовые приемы использую не я, а дизайнеры, мне приходится их интересы тоже учитывать. И, честно говоря, их доводы мне кажутся убедительными. scmRTOS не использую

Пример. Один клиент HTTP-сервера просто через CGI скрипты запрашивает состояние датчиков и строит на экране диспетчеру графики параметров в реальном времени. Второй клиент в это время хочет получить статистическую выборку из внутренней базы данных устройства. Эта база может быть где угодно, ну допустим даже не крайний случай - на SD-карте лежит. Чтобы сделать выборку надо прочесть с карты полста мегабайт данных, обработать и вернуть коротенький результат. Или другой вариант - по запросу прорулить исполнительным устройством, которое вообще через-какой нить удаленный SCADA-шлюз управляется. В любом случае - скрипт CGI отдает управление стороннему коду, и надолго, на секунды/десятки секунд. И люди которые писали этот сторонний код ни про какой кооператив ни сном ни духом. Что делать с первым клиентом? Прекратить диспетчеру графики давать, потому что сторонний запрос надолго и "некооперативно" забрал управление? В-общем, мое мнение, кооператив - это ограниченное решение для ограниченных условий, когда мы всем можем прорулить и учесть все факторы. Трудно расширяемое и неуниверсальное, поэтому я перед применением кооператива долго и нудно думаю - что нужно сейчас, а что затребуют прицепить потом, а как надо поделить время между разнородными задачами и т.д. В общем же случае - кооператив вообще нормально не работает (вспоминаем Win16).

И как же она обеспечивается в вашем случае?

Вы издеваетесь, да? Вы перегружаете контроллер после каждой команды по UART?

Попробуйте запустить линукс на MSP430 или Cortex M0
Алсо, попробуйте заставить ваш линукс работать месяц (хотя бы) от пальчиковой батарейки в портативном приборе/устройстве

50-150р за камень и двухслойка - тоже не последний аргумент.

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

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

По-моему, для борьбы со "сторонним кодом" неизвестных людей есть только одно средство - это round robin. От моих задач управления устройством описанное вами довольно далеко, а чтобы сразу несколько клиентов наваливались поуправлять режимами- так совсем невозможный и недопустимый вариант. Поэтому могу лишь посочувствовать и посоветовать обратиться к готовым решениям для серверных приложений. А это, увы, Linux и ему подобные OS.




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

Не понял. Может, мы опять о разном говорим? Что вы подразумеваете под "конфигурацией web-сервера" через uart?


Потомки Линукса для мобильных устройств, например Android, вполне приличное время работают от батарейки на платформе Cortex M4. Цена конечно выше, но не порядки.

А если задача-приёмник не одна? Вот тот же самый пример - UART, задача-веб-сервер, и задача - ещё что-нибудь (допустим, опрос датчиков). Здесь, стало быть, задача-источник - это UART, а задачи-приёмники - это веб-сервер и опрос датчиков. Приходит в UART команда. Как с ней быть? Кто должен забирать сообщение по флагу готовности?
Затем, надо же ответить что-то в UART. Как это делается? Здесь уже ситуация "несколько писателей, один читатель". Как вы это разруливаете?
Как вы расставляете приоритеты задач?

Я понимаю, что это всё решаемо. Но не так, что "взял C++ и многоуровневую систему прерываний - и стало счастье".


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

Мои пять копеек на счет скорости переключения контекста.
Несколько лет назад в Иаровском компилере для MSP430 была мелкая бага с расположенными подряд деструктором конструктором объекта.
В моем проекте эта бага проявилась при использовании TCritSect.
Написав баг репорт, я решил проэкспериментировать со скоростью выполнения TCritSect.
Смысл в том, что локальная переменная может быть помещена как в регистрах ядра, так и на стеке, в зависимости от опций компилятора.
Локальный объект (TCritSect в данном случае) размещался только на стеке, и никак иначе.
Иными словами "Си-шные" ртосы, использующие пару ENTER_CRITICAL_* EXIT_CRITICAL_* всегда будут иметь фору в несколько тактов .



Имена потомков в студию!

Это только для MSP430 так, для AVR, например, он всегда такие временные объекты создавал в регистре. Да и другие компилеры тоже регистр используют. Т.ч. это конкретный косячок именно EW430, что странно, т.к. в целом очень хороший компилятор.

В том-то и дело, что для каждой периферии существует только одна задача - приемник запроса. По каналу Ethernet - только WEB-серверер, по UART- только свой отдельный интерпретатор команд, по USB- тоже только свой интерпретатор, от клавиатуры - только свой контроллер. У каждого свой флаг готовности. Никаких перекрестий потоков. "Приемники" работают на общий ресурс, который живет своей отдельной жизнью. Они имеют доступ к этому ресурсу последовательно, поочереди, в фоновом режиме. Поэтому опять же никаких столкновений интересов не наблюдается. Но сказать, что в моем случае нет никаких быстрых процессов, выполняемых параллельно, и вытесняющих друг друга по приоритету- будет неправильно. Они таки реализованы в задачах-источниках, целиком размещенных в ISR.

Счастье - не счастье, а необходимость в вытесняющей OS сразу же отпала. Зачем лишние сущности?

Флаг готовности для кого? Для какой из других задач?

И как этот доступ разделяется между задачами-прерываниями? Вот, допустим, задача - UART дождалась своей очереди (как она об этом узнала, кстати?), и тут её прерывает более приоритетное прерывание задачи-USB. Как в этом случае вы избегаете конфликта? Как сохраняете целостность данных?

Ну, здрасьте... А до этого вы утверждали, что у вас все задачи в прерываниях выполняются. А теперь оказывается, что всё совсем не так? Оказывается, что это банальный суперлуп с флажками из прерываний (стыдливо названный "общий ресурс, который живет своей отдельной жизнью")? Тю-ю!
Боюсь, что вы просто не поняли, что даёт вытесняющая OS.

Пардон, может, я чего-то не понимаю, но как быть с другими "приемниками запроса по каналу Ethernet" - ICMP,FTP,SIP,RTP ?

Ну да, «пять страниц тому назад» я это уже отметил :-)

Как видно по выделенному, мы таки понимаем о чём он, но он не понимает о чём мы.
Очень похоже на споры ~15-летней давности в RU.EMBEDDED на тему «asm vs C» между «ассемблерщиками», не пробовавшими С, и «С-шниками», знающими некоторые нюансы ассемблера получше части апологетов «полного контроля над».

Русским же языком было написано- у каждой задачи- приемника свой отдельный флаг тригеринга. А каждая задача-источник обращается только к одной задаче приемнику.

Этот вопрос следует из непонимания структуры взаимодействия задач. Реализованные в ISR параллельные задачи-источники НЕ разделяют общие ресурсы. Их цель другаяя - сжать входную информацию от приферии и передать потребителю, медленной задаче-серверу, только самое необходимое. для его работы. Например, для приложений c WEB-сервером, задача ISR может произвести очень сильное сжатие информации. Она может самостоятельно отвечать на ARP запросы, отвечать пакетами Sync и Ack, сама выделять чистый http- запрос в текстовой форме, сама контролировать время соединений, их количество, сама фильтровать клиентов по адресам и, наконец, сама выделять текст http- запроса, буферизировать его. Собственно, последнее только и предназначено медленной задаче WEB-серверу. Та же история и с USB, с UART, с CAN и прочее.. Неужели не в курсе, что современные чипы позволяют организовать работу всего этого одновременно в псевдопараллельном режиме c вытеснением по приоритету?


Зато прекрасно понял, - в чисто софтовой реализации, типа scmRTOS, они отжили свой век.

О-о-о-о! Начался крутой холивар типа "моя реализация" vs RTOS (любая). И лучший способ себя пропиарить - это вклиниться в чужую тему не дав себе труд въехать в предметную область.
AHTOXA, ReAl, по-моему здесь совершенно бесполезно напрягаться что-либо объяснять.

Речь шла о встроенном в микроконтроллер web-сервере. Для его реализации из всего стека протоколов нужен минимум: ARP-запросы, из ICMP только ping, да и то, можно обойтись, и конечно TCP. Причем, TCP в сильно урощенном виде. Здесь я считаю важным, что современная периферия в микроконтроллерах позволяет большинство коротких служебных пакетов обрабатывать и отправлять обратно в сеть прямо из ISR, обслуживающей MAC. Вытеснение процессов происходит на аппаратном уровне, специальная вытесняющая OS для этого не нужна.

Да понял уже, понял. Суперцикл с прерываниями и флажками. Это просто суперсовременно!
К счастью, большинство здравомыслящих людей считает иначе.



Да, это тролль. Но тут ведь как... С одной стороны, как правильно сказал ReAl - «чтобы другие, набрёвшие на тему и не разобравшись — не подумали, что он прав».
А с другой стороны, в наше время любой скандал - реклама. Думаю, что реклама scmRTOS не повредит

Предложение авторам scmRTOS: кратко опишите правильный способ применения этой ОС для какой-то типовой задачи. Такой пример сильно снизит порог вхождения в идеалогию ОС. В качестве примера взять в упрощенном виде хотя бы то, о чем писал Aprox.
P.S. Я с большим интересом почитаю и возможно, задам вопросы.

Чисто софтовые RTOS вытесняющего типа сильно отстают от развития периферии современных микроконтроллеров. Все фичи, которыми так гордятся авторы софтовых OS, теперь исполняются аппаратно много эффективнее. К сожалению, не всем это понятно, приходится обращаться к конкретным примерам.

Это вы зря. Обиделись наверное...

А вы руководство читали? Там есть "Приложение A.
Примеры использования". Как раз то, что нужно.

Писать OS на С++ для архаичных 8-ми разрядных кристаллов и гордиться, что заняли всего 512 байт ОЗУ - это вам представляется суперсовременным? Вы же этим и юзера заставляете писать на C++. А сколько при этом будет впустую истрачено флеша на одних только "темплейтах" при компиляции проекта - это уже совсем безразлично мелким пользователям?

Скандал раздуваете по-моему вы. Думаю, вовсе не из потребности в рекламе, а от беспомощности в серьезной и предметной аргументации.

Что Вы?! Совсем наоборот. Я на свой счёт ничего не принимаю. Ибо я в курсе аппаратных возможностей современных МК, но в отличие от Вас я также в курсе возможностей встроенных RTOS, которые с лихвой перекрывают требования приведённого Вами частного примера. С нетерпением жду каждого Вашего следующего "аргумента".

И сколько-же именно будет впустую истрачено такими-сякими темплейтами? Сотни байт? Килобайты? Можете привести конкретный пример с кучей "впустую" истраченных байт?

Раздел А.1-А.3 имеется в виду? Да, версии от 29.12.2011. Эту сейчас скачал.
Интересуют соображения о распределении действий между обработчиками прерываний (USART и т.д) и задачами ОС. Например, анализ пакета на целостность (I) и анализ данных (II): a) I - в обработчике прерывания полностью, II - в задаче ОС, б) I - прием данных в обработчике, целостность в задаче ОС, II - в задаче ОС. Можно разбить на другие подзадачи. Такое разбиение должно зависеть от задачи, но как правильно разбить? Из каких критериев исходить? Собственно, тому, кто применяет это и важно понять. (Чем сейчас и озадачен.)
Это частично на форуме обсуждалось тут

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

Лучший тред за последние полгода по поднятию настроения.
Жду аргументов что asm круче це.
Удивляет сдержанность авторов scmRTOS.
Обещаю всем участникам отсутствие репрессий.

P.S. Может выделить все страницы креме первых в "Общение" ?

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

Я посмотрел бегло эту ветку, как неравнодушный пользователь порта для BF.

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

Аргох, у меня к Вам вопрос:
Чего Вы хотите в связи с выходом 4-й версии scmRTOS? Ведь именно этому событию посвящено обсуждение в этой ветке.

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

Успехов.

Я делаю просто: есть класс-UART, в нём содержатся очереди на приём и передачу:

И в прерываниях происходит обслуживание очередей:

Всё. Теперь любая задача, требующая работы с uart, выглядит вот так:


Посмотрите ещё вот эту ветку, там есть несколько вариантов.

Конкретный пример с цифрами не приведу, потому что не занимался таким исследованием. Зато могу сослаться на IAR, который предлагает два варианта компиляторв с С++ : -1: урезанный Embedded C++ для мелких кристалов, где надо экономить ресурсы памяти и -2. полнофункциональный Extended Embedded С++ с тяжелыми библиотеками. Так вот, темплейты C++ поддерживаются только тяжелым Extended. Отсюда и непонятное противоречие в scmRTOS- с одной стороны вроде заботятся о мелких кристаллах, а с другой- тут же все портят использованием темлейтов. Причем, как я понимаю, ради абстрактной красоты.

Могу вспомнить свой случай, к чему приводит использование темплейтов. В IAR сделал проект С++ без темплейтов для STR911FAM44 с ядром ARM-9. Приложение заняло примерно 160K кодов и констант во флеш. Потом соблазнился красотой темплейтов и оформил то же самое с темплейтами. Пришлось включать компиляцию с опцией Extended. Размер использованой флеш сразу вырос до 210K. "Имеющий уши- услышит".

Господа, давайте перестанем кормить тролля. Не хочется портить радостную ветку.

Мой мотив очень прост, решил исследовать вопрос - какой будет выигрыш от использования scmRTOS в моих задачах? Именно эта OS привлекла внимание тем, что она по-моему единственная предполагает использование C++. Начал с пары очень простых вопросов к авторам и апологетам. Ответы не впечатлили. Стало понятно, что продукт чисто софтовый, абстрактный, не учитывает развитие периферии современных микроконтроллеров. На этом собственно и все, диспут заканчиваю.



Были бы знакомы с современной периферией микроконтроллеров, то заменили бы кучу мелких прерываний от каждого символа, всего одним прерыванием по окончанию работы канала DMA, который сейчас имеется у каждого приличного UARTа. Глядишь, и очереди оформлять для многозадачной OS не потребовалось бы. На stm.com даже AN такой есть.

Кстати, у вас метод uart_t::irq_handler() представлен как член класса uart_t. Позвольте каверзный вопрос, как это удается в С++ оформить метод класса в виде ISR? Да еще и зарегестрировать соответствующий вектор в контроллере прерываний?

Хм, тут в теме такая жара, а я со своим контекстом лезу
Собрал из своих исходников файл с функцией tn_sem_signal() - собственно инкрементирует семафор и освобождаем ожидающую задачу. По возможности почистил от всяких фич других портов (оставил только относящееся к Cortex-M3), TN_ASSERT-ы, отладочные фичи и прочее, н еотносящее к вопросу. Файл даже компилируется - при желании можно посмотреть листинг.

Порядок исполнения такой:
- tn_sem_signal() - ставим семафор
- task_wait_complete() - пробуждаем ждущую задачу
- task_to_runnable() - переводим задачу в исполняемое состояние
- переключение контекста при первом же разрешении прерываний tn_unlock_interrupt() (PendSV)

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

Если разблокируемая задача ждала без тайм-аута (с бесконечным таймаутом), то при пробуждении она удаляется из списка ожидания объекта и вставляется в список диспетчера - две операции со списками. Если был конечный тайм-аут - то задача удаляется еще и из списка системного таймера. В-общем, тут round-robin-а вообще не видно - естественно, он не исключен, просто никак на процесс пробуждения задачи не влияет.



"Огласите весь список пжлста" © "современных микроконтроллеров".
А у меня вот такой пример - PowerPC MPC83xx от Фрискейла, там PCI/PCIe, SATA, GbE, USB HS и еще всякая мелочь, линейка разработки 2005-2011 годов. Там нормально так периферия развита - куда уж современнее. И, представляете, оно вообще не поддерживает вложенные прерывания. И где Вы с Вашим подходом окажетесь? А, ну да, щаз скажете что Линукс наше фсе

Думаю, не надо. Тут, пусть и в размазанном виде, но есть рекомендации по разделению работы на «драйверную» и «процессовую» части, линки на другие темы по этому поводу. Пусть живёт.

Зато у не-современных Fujitsu MB90, у M16C, у Siemens C16x и STM ST10 — есть. Оно ведь как — решили что нужно сделать — сделали, хоть и давно. Решили что не нужно - не сделали, хоть и недавно. Они ведь слово «современный» без придыхания произносят, просто работу свою делают :-D


Уже сижу и вижу такой сам весь из себя экстрасенсорный канал ПДП, который знает, сколько я в терминале символов набрал, чтобы не по заполнению буфера прерывание выдать, а по последнему набранному мной символу.
Не бойтесь — когда надо, ПДП задействуется. Или FIFO. Или оба.

Не надо было скипать без прочтения код из http://electronix.ru/forum/index.php?s=&am...t&p=1049089.
Стоило сходить по ссылкам из сообщения http://electronix.ru/forum/index.php?showt...p;#entry1049007
Естественно, нестатический метод обработчиком не поставить. Естественно, статический можно либо вызвать из обработчика либо назначить обработчиком — в зависимости от возможностей компилятора.
С++ знаете так же хорошо, как и историю развития микроконтроллеров?

Тогда надо сравнить ещё время переключения на низкоприоритетную при постановке на ожидание высокоприоритетной.
У scmRTOS тут симметрия.

А вообще стоило бы мне наконец-то с TNKernel познакомиться ближе :-)


Зависит от. Если UART от отладочной консоли, то как AHTOXA показал — в прерывании тупо заталкивать принятые байты в очередь, а уже в процессе анализировать, включая редактирование строки и т.п.
Если данные пакетами ходят, то лучше весь пакет принять в прерывании, потом отдать его в процесс http://electronix.ru/forum/index.php?showt...mp;#entry841330
Проверка целостности пакета... CRC я бы в процессе проверял. Всё равно ему думать, что делать дальше. Хотя если это slave в каком-то протоколе, то, возможно, и не стоит теребить процесс битыми пакетами. Хотя если они не часто бывают, то не стоит в прерывании тратить считать контрольную сумму каждого пакета...
Вкусовой попрос. Куча <-> не куча.

А мужики-то не знают В том же мануале на эту ОС сказано, что пользователю вовсе не обязательно писать приложение на Си++. Для справки: микс из Си, Си++ и даже Асм прекрасно уживаются вместе. Предупрежу удивление: только не надо все в один файл помещать!


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





Кстати, высокомерие в любых проявлениях - это грех по христианским законам. Вы какого вероисповедания?

Отлично. Ждем порт на AVR и STM8

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

А вот здесь тоже не всё так однозначно. Дело в том, что пока мы сидим в прерывании, ОС не может сделать перепланировку. Представь, что мы, кроме UART-а, должны окучивать что-то быстрое, критичное ко времени реакции. Скажем, какие-нибудь импульсы измерять. Мы назначаем прерыванию от этих импульсов высокий приоритет, в прерывании делаем какую-то минимальную обработку, и взводим event для задачи с максимальным приоритетом. Вроде бы, мы должны практически сразу после прерывания попасть в высокоприоритетную задачу, но нет. Пока не доработает прерывание UART - мы не при делах

Весь список конечно не оглашу, но намекну на практически любой 32-бит чип с ядрами ARM-9/11 или Cortex M3/4. Я лично исторически прирос к продукции STM. Ее линейка STM32 имеет периферию, насыщенную дополнительными фичами. И эти фичи устраняют на аппаратном уровне узкие места в паралелльных задачах управления и связи, вытесяющие RTOS попросту становятся не нужны.

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



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

Ну, а как вы оцениваете на "современность" недавне появление DMA у периферии? Причем в любой комбинации, можно даже сквозной канал передачи организовать, например от UART прямо в SPI, минуя память и процессор. Зачем в этом случае посредники в виде RTOS?

Я-то не боюсь. Потому, что прерывание вырабатывается UART-ом не по фиксированному кол-ву принятых символов, а по time-out в конце непрерывной посылки. Фактическое число принятых символов можно посмотреть потом в контроллере DMA. Этот прием охватывает даже ваш пример следования одиночных символов, я уж не говорю про пакетный MODBUS.