В том-то и дело, что для каждой периферии существует только одна задача - приемник запроса. По каналу 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 - в задаче ОС. Можно разбить на другие подзадачи. Такое разбиение должно зависеть от задачи, но как правильно разбить? Из каких критериев исходить? Собственно, тому, кто применяет это и важно понять. (Чем сейчас и озадачен.)
Это частично на форуме обсуждалось тут