[aprox 0]

А если задача-приёмник не одна? Вот тот же самый пример - UART, задача-веб-сервер, и задача - ещё что-нибудь (допустим, опрос датчиков)...

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

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

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

[AHTOXA 14]

У каждого свой флаг готовности.

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

"Приемники" работают на общий ресурс, который живет своей отдельной жизнью. Они имеют доступ к этому ресурсу последовательно, поочереди, в фоновом режиме.

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

Но сказать, что в моем случае нет никаких быстрых процессов, выполняемых параллельно, и вытесняющих друг друга по приоритету- будет неправильно. Они таки реализованы в задачах-источниках, целиком размещенных в ISR.

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

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

Боюсь, что вы просто не поняли, что даёт вытесняющая OS.

[blackfin 16]

В том-то и дело, что для каждой периферии существует только одна задача - приемник запроса. По каналу Ethernet - только WEB-серверер, ...

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

 

[ReAl 0]

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

Боюсь, что вы просто не поняли, что даёт вытесняющая OS.

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

Вы её просто не умеете готовить. Как, видимо, и любую другую вытесняющую ОС

...

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

Как видно по выделенному, мы таки понимаем о чём он, но он не понимает о чём мы.

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

[aprox 0]

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

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

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

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

 

... Тю-ю!

Боюсь, что вы просто не поняли, что даёт вытесняющая OS.

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

 

 

[IgorKossak 0]

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

AHTOXA, ReAl, по-моему здесь совершенно бесполезно напрягаться что-либо объяснять.

[aprox 0]

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

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

[AHTOXA 14]

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

Да понял уже, понял. Суперцикл с прерываниями и флажками. Это просто суперсовременно!

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

К счастью, большинство здравомыслящих людей считает иначе.

 

 

AHTOXA, ReAl, по-моему здесь совершенно бесполезно напрягаться что-либо объяснять.

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

А с другой стороны, в наше время любой скандал - реклама. Думаю, что реклама scmRTOS не повредит :)

[mdmitry 0]

Думаю, что реклама scmRTOS не повредит :)

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

P.S. Я с большим интересом почитаю и возможно, задам вопросы.

[aprox 0]

О-о-о-о! Начался крутой холивар типа "моя реализация" vs RTOS (любая).

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

И лучший способ себя пропиарить - это вклиниться в чужую тему не дав себе труд въехать в предметную область.

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

 

 

[AHTOXA 14]

Предложение авторам scmRTOS: кратко опишите правильный способ применения этой ОС для какой-то типовой задачи.

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

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

[aprox 0]

Да понял уже, понял. Суперцикл с прерываниями и флажками. Это просто суперсовременно!

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

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

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

[IgorKossak 0]

Обиделись наверное...

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

[sonycman 0]

Вы же этим и юзера заставляете писать на C++. А сколько при этом будет впустую истрачено флеша на одних только "темплейтах" при компиляции проекта - это уже совсем безразлично мелким пользователям?

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

[mdmitry 0]

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

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

Раздел А.1-А.3 имеется в виду? Да, версии от 29.12.2011. Эту сейчас скачал.

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

Это частично на форуме обсуждалось тут