[aprox 0]

Если Вы «драйверные» вещи выделите в отдельные классы, как в обсуждениях по ссылкам в предыдущем моём сообщении, а в процесс будете отправлять уже «высокоуровневый» результат работы драйвера, то отрабатывать драйверные прерывания будут так же быстро, как и в программе без какой-либо ОС. Всю быструю работу будет делать драйвер, остальное — разбуженный результатом процесс. Это вполне реализуемо в рамках scmRTOS.

А смысл? Зачем нужна вообще scmOS, если и без нее реализуются все те же самые функции вытеснения процессов с приоритетом и защищенность данных каждой отдельной задачи? Зачем мне осваивать ставшую ненужной OS и подлаживаться под ее условности?

Не нравится отдельный драйверный класс — сделайте свой хитрый процесс. Раз он хитрый — Вам не удастся воспользоваться готовым шаблоном для стандарнтых процессов, но Вы тут так много говорили про С++...

Этот язык я использую для опреления задачи реального времени как класса с защищенными методами и данными. Отдельные стеки, сохранять контекст каждой задачи, уже не неужно. Соответственно, одна из главных фич многозадачных OS с приходом C++ выглядит ненужной.

[ коды skipped]

Тут имеем быструю реакцию (уже не класса драйвера, а непосредственно класса процесса) на прерывание. Но не в его методе exec(), предназначенном для работы в рамках ненастоящего прерывания вытесняющего планирования ОС, а в его методе compa_isr().

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

 

делал на большом приоритете, потом снижал приоритет ядра до более низкого и его могли прервать даже те прерывания, которых он победил при первоначальном арбитраже. То же самое я делал на i8051 — после критической по времени части обработчика очищал уровень приоритета и данный обработчик уже могли прервать не только более приоритетные прерывания, но и вобще все, т.е. я снижал уровень приоритета обработчика прерываний до приоритета основного кода. Иногда при этом даже то же самое прерывание прерывало как бы само себя, но шло при этом по другой ветке (по бедности — таймеров не хватало, вот и было на один таймер навешано несколько задач разной периодичности и длительности). Не совсем то, что было в 1801ВМ или что есть у MSP430 или современных чипов, но это именно эта идеология.

Видите ли, ссылаться на опыт прошлого, на проблемы со старыми чипами... как-то неконструктивно. Я знаю все те проблемы, сам наплясался с бубном всласть. Сейчас время другое- в чипах появились нормальные прерывания с приоритетом, периферия вся забуферирована через FIFO, не надо программно торопиться с пересылками блоков данных- это за нас делает DMA. Напичкали все, о чем мечталось лет десять назад. Так, пользоваться надо!

 

[sasamy 0]

одна из главных фич многозадачных OS с приходом C++ выглядит ненужной

 

Вспоминаются слова Высоцкого: "Капитан, Никогда ты не будешь майором!.." Ни один язык не заменит ОС, тем более убогий С++.

[AHTOXA 18]

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

Может, хватит вам уже позориться, а? Неужели трудно понять, что механизмы инкапсуляции C++ ну никак не защищают данные при конкурентном доступе к ним из разных потоков выполнения (в вашем случае - из прерываний)?

Я, если честно, немного переживаю за "задачи связи" :)

 

[ReAl 0]

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

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

Для тех, кто в танке — повторяю:

• Система прерываний "Электроники-60" и 1801ВМ ни на гран не хуже таковой у Cortex-M3 (а предзагрузка слова состояния для обработчика из вектора — временами вообще песня, но это к вложенности не имеет отношения, просто удобно).
• У і8051 система прерываний вполне себе приоритетная с поддержкой вложенных прерываний. Уровней, правда, два или четыре, но для такого мелкого кристалла больше не очень и нужно, с учётом возможности опустить приоритет обработчика на уровень фонового процесса мне больше трёх никогда не было нужно. На AVR первое время страдал от нехватки таких возможностей :-)
• MSP430 тоже не дурак в этом смысле.

Да, многое у коретксов получше, чем у предыдущих ядер, но не настолько, чтобы совсем отменить всё предыдущее.

То, что Вы с рвением неофита повторяете слова «новые», «современные» — говорит только о недознании Вами вопроса и о непонимании того, что развитая система прерываний ортогональна ОС, не отменяет её, а помогает ей. Чем примитивнее система прерываний, тем тяжелее живётся ОС, а не ОС исправляет недостатки системы прерываний.

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

Считаете возможности современных процессоров панацеей, отменяющей всё и вся — Ваше право. Про это даже песенка есть:

Нам электричество сделать все сумеет,

Нам электричество мрак и тьму развеет.

Нам электричество заменит всякий труд,

Нажал на кнопу чик-чирик и тут как тут.

[lotor 0]

Да, тему поднимали неоднократно, в том числе и с zltigo. Ему задавался этот же вопрос. Он на него не привёл технических аргументов, а сказал лишь, что ему лично так больше нравится, это его эстетическое предпочтение.

 

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

 

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

 

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

 

Вариант с равными приоритетами и карусельным вытеснением хорошо ложится на большие ОСи, где множество процессов живёт своей жизнью, очень долго, и реальтайм не важен. В RTOS же ситуация в корне другая, и такой способ планировки, ПМСМ, ничего кроме недостатков не имеет.

Я согласен, что введение одинаковых приоритетов будет накладно. Просто я прекрасно обходился конечными автоматами, пока не наткнулся на то, что код чужой библиотеки надо было "параллелить" со своими задачами. Срочно пришлось смотреть RTOS, которые имели порты под мой мк - среди них была и ваша. Но, т.к. явно места блокировки в чужой библиотеки указать было затруднительно, пришлось выбрать FREERTOS, задать задачам одинаковый приоритет, переключение контекста 1 мс - и тогда я получил желаемый результат.

[dxp 67]

Отдельные стеки, сохранять контекст каждой задачи, уже не неужно. Соответственно, одна из главных фич многозадачных OS с приходом C++ выглядит ненужной.

Это надо выбить в мраморе и покрасить золотыми буквами. И разместить в аллее троллинга.

 

" Ни один язык не заменит ОС, тем более убогий С++.

Да уж куда ему до мегаязыка Цэ.

 

Я согласен, что введение одинаковых приоритетов будет накладно. Просто я прекрасно обходился конечными автоматами, пока не наткнулся на то, что код чужой библиотеки надо было "параллелить" со своими задачами. Срочно пришлось смотреть RTOS, которые имели порты под мой мк - среди них была и ваша. Но, т.к. явно места блокировки в чужой библиотеки указать было затруднительно, пришлось выбрать FREERTOS, задать задачам одинаковый приоритет, переключение контекста 1 мс - и тогда я получил желаемый результат.

Почему бы просто не вынести код этой библиотеки просто в отдельный процесс, и пусть он себе там живёт? Приоритет установить из требований приложения

[lotor 0]

Почему бы просто не вынести код этой библиотеки просто в отдельный процесс, и пусть он себе там живёт? Приоритет установить из требований приложения

У меня шел непрерывный поток данных, который надо было писать библиотечными функциями на карту. Я пробовал сделать так, как вы предлагаете - получалось, что отображение и реакция на кнопки тормозилась. Если бы я мог указать в библиотеки места блокировки - расставить семафоры и т.п., то этот вариант сработал. Для меня это единственный случай, когда нужны были одинаковые приоритеты. Но он определил мой выбор RTOS.

[VslavX 0]

Я согласен, что введение одинаковых приоритетов будет накладно.

Не очень-то оно и накладно. Например, TNKernel поддерживает и уровни приоритетов и round-robin в пределах каждого приоритета, а время планирования и переключения контекста такое же (или даже лучше, правда новую версию SCM4.0 я не тестил) как у SCM. И реально этот round-robin используется, недавний конкретный пример - потоки выполнения CGI в HTTP-сервере. С точки зрения системы, как бы не должны обработчики двух одновременных HTTP-запросов между собой по приоритетам отличаться. Или если у процессора два абсолютно одинаковых MAC-а. ИМХО, некрасиво если потоки драйвера одинакового "железа" будут иметь различные приоритеты.

 

[dxp 67]

У меня шел непрерывный поток данных, который надо было писать библиотечными функциями на карту. Я пробовал сделать так, как вы предлагаете - получалось, что отображение и реакция на кнопки тормозилась. Если бы я мог указать в библиотеки места блокировки - расставить семафоры и т.п., то этот вариант сработал. Для меня это единственный случай, когда нужны были одинаковые приоритеты. Но он определил мой выбор RTOS.

Всё равно не понял. Почему тормозилось? Какой-то более приоритетный код надолго отбирал управление? Или этот код библиотеки тормозил остальное?

 

Если второе, то не очень понятно, почему ему не понизить приоритет, чтобы кнопки не блокировал?

 

Не очень-то оно и накладно.

Это что считать наклАдным. Переключение контекста сама по себе приличная по объёму инструкций операция. И отдельный стек. Я понимаю, что при наличие 32К оперативы выделить лишних полкилобайта особых вопросов не вызывает. Но чем это лучше, чем просто выполнять задания по очереди в одном процессе?

 

Например, TNKernel поддерживает и уровни приоритетов и round-robin в пределах каждого приоритета, а время планирования и переключения контекста такое же (или даже лучше, правда новую версию SCM4.0 я не тестил) как у SCM.

Чудес-то не бывает. Если планировщик более сложный, то и время его работы тоже будет больше. В своё время сранивал с uC-OS/II, там карта процессов состоит из распределённой структуры и приоритет вычисляется в два приёма - время передачи управления было в 2-2.5 раза больше. При прочих равных. Именно время передачи управления, а не переключение контекстов. Время переключения контекстов само по себе зависит от размера контекста, от процессора и его тактовой, но не от ОС.

 

Другое дело, что кому-то пофиг, что время передачи управления в несколько раз меньше. Например, zltigo прямо говорил, что ему не важно, сколько он там времени тратит, на его задачах всё успевает, а наличие возможностей ему нравится, поэтому его выбор FreeRTOS. Точнее, то, что от неё осталось после его доработок. :)

 

И реально этот round-robin используется, недавний конкретный пример - потоки выполнения CGI в HTTP-сервере. С точки зрения системы, как бы не должны обработчики двух одновременных HTTP-запросов между собой по приоритетам отличаться. Или если у процессора два абсолютно одинаковых MAC-а. ИМХО, некрасиво если потоки драйвера одинакового "железа" будут иметь различные приоритеты.

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

[ReAl 0]

Кто сказал, что МАСи должны иметь одинаковые приоритеты? Если по одному из них трафик большой, а по второму малый, то вот и разница.

Та не™, у Вячеслава по обеим (одинаково) большой :-)

[lotor 0]

Всё равно не понял. Почему тормозилось? Какой-то более приоритетный код надолго отбирал управление? Или этот код библиотеки тормозил остальное?

Если второе, то не очень понятно, почему ему не понизить приоритет, чтобы кнопки не блокировал?

Проще всего мою ситуацию можно представить как две задачи, каждой из которой нужно постоянно выполняться и нельзя указать места входа в блокировку. Если повысить приоритет одной из них, страдает другая, т.к. отбирается управление на достаточно долгое время. Возможно можно было обойтись разными приоритетами, и дело в моем малом опыте в этих вопросах. Но наиболее просто такое решилось именно одинаковыми приоритетами. :)

[dxp 67]

Та не™, у Вячеслава по обеим (одинаково) большой :-)

Тем более, зачем тут лишние накладняки на передачу управления в непредсказуемый момент?

 

Проще всего мою ситуацию можно представить как две задачи, каждой из которой нужно постоянно выполняться и нельзя указать места входа в блокировку. Если повысить приоритет одной из них, страдает другая, т.к. отбирается управление на достаточно долгое время. Возможно можно было обойтись разными приоритетами, и дело в моем малом опыте в этих вопросах. Но наиболее просто такое решилось именно одинаковыми приоритетами. :)

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

[VslavX 0]

Это что считать наклАдным. Переключение контекста сама по себе приличная по объёму инструкций операция. И отдельный стек. Я понимаю, что при наличие 32К оперативы выделить лишних полкилобайта особых вопросов не вызывает. Но чем это лучше, чем просто выполнять задания по очереди в одном процессе?

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

 

Чудес-то не бывает. Если планировщик более сложный, то и время его работы тоже будет больше. В своё время сранивал с uC-OS/II, там карта процессов состоит из распределённой структуры и приоритет вычисляется в два приёма - время передачи управления было в 2-2.5 раза больше. При прочих равных. Именно время передачи управления, а не переключение контекстов. Время переключения контекстов само по себе зависит от размера контекста, от процессора и его тактовой, но не от ОС.

От процессора зависит само собой. И от ОС зависит - от планировщика, схемы данных диспетчера, от активированных фич и просто от качества кода. Я сравнивал uC/OS, FreeRTOS, SCM и TNKernel - есть вот такая тема, там проведено практическое исследование вопроса (в разрезе по ОС и процессорам :)). Поэтому я продолжаю настаивать что "не так уж оно и накладно" :).

 

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

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

 

 

Тем более, зачем тут лишние накладняки на передачу управления в непредсказуемый момент?

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

Я не хочу сейчас дискутировать о достоинствах и недостатках кооперативной и/или вытесняемой многозадачности. Просто у пользователей TNKernel всегда есть выбор между кооперативом и вытесняйкой, а вот у пользователей SCM - выбора нет, только кооператив (ессно, речь о задачах с одинаковым приоритетом).

 

[lotor 0]

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

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

[AHTOXA 18]

Поэтому я продолжаю настаивать что "не так уж оно и накладно" :).

ваш вариант TNKernel : 2.83uS для LPC1768, @100МГц,

scmRTOS: 2.55uS STM32F103 @72MHz (приведённое к 100МГц - 1.83uS).

Более чем в полтора раза однако :)