Выпущена scmRTOS 4.0., Ура, товарищи! :) Опции

[AHTOXA]

Собственно, субж.
Ссылки:

• Что нового (en);
• Migration Guide;
• Download;
• svn (trunk).
• User Manual (русский)
• User Manual (en)

Кроме того, незадолго до этого была выпущена версия 3.11. Это завершающая, багофиксная версия 3.x. Ссылки:

• Download;
• svn.

[dxp]

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

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

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

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

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

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

[Lotor]

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

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

[dxp]

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

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

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

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

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

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

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

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

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

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

[VslavX]

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

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

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

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

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

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

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

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

[AHTOXA]

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

ваш вариант TNKernel : 2.83uS для LPC1768, @100МГц,
scmRTOS: 2.55uS STM32F103 @72MHz (приведённое к 100МГц - 1.83uS).
Более чем в полтора раза однако

[VslavX]

ваш вариант TNKernel : 2.83uS для LPC1768, @100МГц,
scmRTOS: 2.55uS STM32F103 @72MHz (приведённое к 100МГц - 1.83uS).
Более чем в полтора раза однако

Та не™
Сравнивать надо на одинаковых процах, одинаковый прикладной код, одинаковым методом (скопом импульс на одной и той же ножке наблюдаем, например), с одинаковыми опциями компилятора, и исполнением из одного и того же места (из флеша, да , и с одинаковыми waitstates). В упомянутой теме апдейт давний написан - включаешь у компилятора оптимизацию по скорости - и уже имеем 2.50uS на 1768@100МГц для TNKernel. BTW, я там еще оптимизаций добавил, надо бы потестить - а то что-то давно я ерундой не страдал