Почитал несколько документов для чайников.
Описано о приоритете задач много, но я не нашел зависимости распределения времени между задачами.
Например у меня три задачи независимые задачи с приоритетами 1, 2, 3.
Логично предположить, что время выделяемое на них будт прямо пропорционально приоритету.
Но никак не могу найти прямого указания о рспределении времени.

Перечитайте, пожалуйста, "для чайников" еще раз или несколько раз. А то пока Ваш вопрос напоминает вопрос из анекдота "все понял, кроме как в трактор лошадь запрягать", очень трудно начинать обoщения с такого уровня

Ну вот например такое описание:



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

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

"Каждая задача должна сама передавать ему управление" относится К ЛЮБОЙ ЗАДАЧЕ, а не только, как написано в неведомой цитате, "кооперативной". Уж слишком конспективную Вы какую-то бумажку взяли . Но даже в отцитированном Вами есть понятие "готовность задачи", которое Вы пропустили мимо ушей. Задачи по любому должны добровольно передавать управление ( переходить в "неготовность") и только если есть задача более высокого(равного)уровня или обработчик прерыания, то она прервет текущую.

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

На форуме много раз публиковали эти ссылки, применительно к freertos для начала можно почитать статьи
http://kit-e.ru/articles/micro/2011_2_96.php
http://microsin.net/programming/arm/index/Page-2.html

При чтении, надо обращать внимание, какого типа многозадачность, вытесняющая, кооперативная или гибридная. И ко всем вашим вопросам надо добавить какой режим многозадачности вы пытаетесь понять.

Я еще не видел ни одной малой RTOS в которой планировщик вел бы учет времени выполнения задач и на основе этого вел бы политику вытеснения.
Для малых и примитивнейших RTOS типа FreeRTOS время выполнения задач должен измерять сам юзер.
После чего решать является ли его состав задач в принципе поддающимся планированию в рамках заданных допустимых задержек.
Для приоритетного планировщика с неизменяемыми длительностями выполнения задач известно правило 70%
Но даже не буду его расшифровывать, поскольку нет в природе задач с неизменяемой длительностью исполнения.
Поэтому все гораздо сложнее.

Понятно, шары не будет.
Распределение ресурсов процессора раньше делал самостоятельно.
Думалось, что FreeRTOS на много сущесственнее поможет утрясать задачи.
Прийдется каждой задаче определять событие для останова/запуска.

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

Я бы предположил даже обратную зависимость времени работы задачи от приоритета. Что-то важное делать быстро, а длительные задачи выполнять по остаточному принципу.

Святым духом не иначе? Вы же как-бы ПОМОЩИ хотите, а чуда. Чудес не будет. А помощь ЕСТЬ!

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

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

Почему нельзя? Можно. Называется карусель.

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

В общем, возлагать на планировщик RTOS распределение времени - плохая идея. И на самом деле всё намного проще, чем вам представляется. Приоритеты задач зависят от их срочности. Например, если какая-то задача связана с аппаратурой - скажем, приходят по UART данные, и аппаратура приёмника не будет ждать, она принимает данные с определённым темпом, поэтому программа должна успевать забирать данные из регистра приёмник. Обычно, это делается в прерывании, но когда накопился пакет, надо его передать основной программе, чтобы буфер приёмника был готов к приёму следующего пакета, а времени "на всё/про всё" - интервал приёма очередного символа, и вот за это время надо успевать отреагировать и передать пакет на обработку. Если процессор будет занят чем-то другим длительное время, то будет потеря данных. Поэтому нужно иметь механизм прервать менее срочные дела и отреагировать на событие, которое во избежание потерь должно быть обработано без проволочек.

Приведённый пример с UART'ом в некотором смысле умозрительный - проблему можно обойти, например, используя кольцевой буфер или пул буферов, но принцип не меняется. RTOS с вытесняющим планировщиком позволяет построить систему, работающую на обработках событий (event-driven), и это очень удобно и эффективно с точки зрения как большей детерминированности времени реакции на событие, так и расходования процессорного времени. И никто, кроме разработчика, не знает, как распределить работу. Только разработчик, основываясь своём замысле, может правильно построить программу - классифицировать все события по срочности и ресурсоёмкости их обработки, и в соответствии с этим уже и определить, сколько ему нужно задач и какие у тех должны быть приоритеты. При этом важно, чтобы в конечном итоге процессор успел их все обработать. Если данный процессор этого не обеспечивает, значит данный процессор не годится для данной задачи. Как правило, процессор выбирается с запасом, и современные МК в подавляющем большинстве случаев позволяют обеспечить это без проблем.


Можно (как уже сказали, это чистая "карусель" - round-robin scheduling). Но зачем? Например, одна задача быстро делает свои дела и ей просто нечего больше делать - логично отдать управление ядру RTOS, чтобы оно передало его другой задаче, которой есть чем заняться. Если все задачи в данный момент отработали задания и отдали управление ядру, то ядро может просто перевести процессор в IDLE (один из простых вариантов - ядро передаёт управление системной задаче IDLE, которая вызывает инструкцию процессора, переводящую аппаратуру проца в один из режимов пониженного энергопотребления), таким образом, если процессору нечего делать, то он и энергии потребляет меньше, что может быть актуально в портативных приложениях.

Карусельное планирование теоретически может быть полезно для перераспределения процессорного времен между фоновыми (т.е. низкоприоритетными и работающими длительное время - например, какие-то фоновые вычисления) задачами.

Цитирую Андрея Курница
http://easyelectronics.ru/img/ARM_kurs/FreeRTOS/Kurniz.pdf

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

RTOS не может распоряжаться временем выполнения задач, поскольку ничего не знает о задачах кроме их приоритета.
В теории RTOS все realtime задачи должны быть выполнены между двумя тиками.
Т.е. возможность принудительного вытеснения планировщиком даже не рассматривается.
Юзер должен установить приоритеты задачам для оптимальной укладки их длительностей на интервале одного тика при вероятностном времени активизации задач.
Если же у вас задача не укладывается в один тик то значит у вас не realtime задача, либо вы выбрали неверный тик и неверно оценили реактивность системы.

Посмотрел статью. Фрагментарно все правильно, а обобщения типа отцитированного - хоть стой, хоть падай.
100% не понимал, что надергал и напереводил .
А Автор темы не понял даже того, что сам отцитировал:

OS общего назначения а-ля виндовс и иже с ним, никакого отношения встраиваемым RTOS не имеют. Читаем еще раз:

Но даже десктопные системы НЕ ДЕЛЯТ время в "равной пропорции" - тому-же, например, Word, как отдельной задаче, ни нафиг вообще не нужно никакое время, пока кнопку с буквой не нажали.

Вам уже написали что ОС общего назначения это не FreeRTOS, но ... вот еще подсказка в файле FreeRTOSConfig.h (должен быть в вашем проекте) есть такой параметр configUSE_PREEMPTION который задает тип многозадачности в проекте. Вот тут http://kit-e.ru/assets/files/pdf/2011_05_97.pdf даже рассматриваются многозадачности. А в этой статье http://kit-e.ru/assets/files/pdf/2011_04_96.pdf показывается что будет если у задач одинаковый приоритет (или разные приоритеты).

И в моей ссылке и в ваших название статей:"FreeRTOS — операционная система для микроконтроллеров."

Я не автор статей, но могу сказать что ОСРВ и ОС общего назначения это разные вещи.
http://omoled.ru/publications/view/20

Цепляться за терминологию в данном случае не важно. Любая ОС в тех или иных условиях может работать как ОСРВ.

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

А это уже схоластика . Да может, если, например, времени настолько много, что и делить его не надо.
Да, и трактор и велосипед оба транспорные средства.

Пример - в осциллографе Agilent (номер наизусть не помню) используется ОС Windows.

У каждой задачи должен быть приоритет и допустимое время выполнения. Да и приоритета не нужно, это просто средство для выполнения задачи в требуемое время. Если ОС способна выполнить все задачи вовремя, то она ОСРВ.
Может оказаться, добавили еще одну задачу, и ОС уже не справляется. Мой мобильник на Андроиде разрешает ответить на звонок секунд через 8. Убил бы!

Фриртос устроена не так. Она дает две возможности
* если приоритет у задач разный, то задача с более высоким приоритетом будет работать, пока она готова (не заснула, не ждет данных из очереди и т.п.)
* если приоритет у задач одинаковый, то они будут работать друг за другом (каждый тик управление будет переходить к следующей задаче)

Если вам нужно чтобы все задачи работали пропорционально приоритету, то во фриртос это придется делать вручную. Но возможно если вы опишите проблему, которую пытаетесь решить, вам подскажут как это правильнее сделать с фриртосом и не придется изобретать свой шедулер

Пример "ни в .... ни в Красную Армию" . То, чем там занимается Windows это ОДНА ИЗ ЗАДАЧ выполяемых на ОТДЕЛЬНОМ компьютере. Все реальное время НА ОТДЕЛЬНОМ ЖЕЛЕЗЕ.

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





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

И Вы думаете, что там все операции с оцифровкой сигнала (под ГГц) реализованы на x86 под управлением Windows!? Нет же, Вы прекрасно знаете, что там внутри еще куча всего стоит, а Windows это вершина айсберга и ОС для удобства пользователя.

Я считаю, что другой ОС в том осциллографе нет.
А приоритеты в Windows есть.
И она вполне себе справляется с функциями RTOS в данном примере.

Там скорее всего какая-то отдельная железка рулит собственно измерениями, а на винде - только GUI, анализ, настройки, экспорт/импорт и т.п.




Да, тут хотелось бы услышать ТСа. Мне на ум приходят какие-то длинные чисто вычислительные задачи, ничего не ждущие, которым хочется задать приоритет друг относительно друга так, чтобы даже низкоприоритетная иногда что-то делала

Конечно. Но назначение осциллографа - захватить сигнал и нарисовать его на экране. Вот со второй частью ОС справляется.

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

Не наводите тень на плетень - либо механизмы для обеспечения этого есть, либо нет. От того, что, "windows" попадет на железо, которое превосходит требуемую ПИКОВУЮ производительность он не станет RTOS - либо у дедушки есть яйца, либо он бабушка.

И каковы же эти яйца-механизмы, конкретно? Что есть, к примеру во FreeRTOS, что делает ее RT? Кроме простоты (примитивизма)?

Предлагаю Вам начать думать с другого конца - а хоть какие-то механизмы обеспечения приоритетов у того-же windows для ПРИЛОЖЕНИЙ вообще есть? Кроме изменения через анус абстрактого (не говорящем ни о каких ни временных параметрах, ни о даже относительном уровне приоритета относительно других задач ) ГРУППОВОГО уровня "приоритета". Механизмы-же той-же FreeRTOS описаны в ее документации ДЛЯ ПОЛЬЗОВАТЕЛЯ в отличие от "windows".

Предлагаю думать не через анус, мутные свойства Windows отложим в долгий ящик (мне она не нужна, просто привел пример), а договоримся, что наличие у ОС таких простейших свойств, как уровень приоритета задач, и задержка на заданное число тиков, волшебным образом превращает ОС в ОСРВ. В дополнение к простоте, из которой и вытекает ее быстрота.

+

В 2003 г. делал и сделал довольно сложную аппаратно-программную систему восстановления всяких железок методом контактной наварки.
Несколько контуров управления ( ток, скорость, давление и пр). Где-то решено аппаратно, но без контроллеров.
Всем заведовала ОС Windows NT в режиме мягкого реал-тайм + самописный софт.
Есть исследования на тему Win NT - как ОСРВ.

Да бога ради. Как раз такой случай:

Если на Вашей наварке, запустить какую-нибудь суровую игрушку, что отстанется от "мягкого реал-тайм" и каков будет результат работы наварочного комплекса?



Тогда незачем было приводить негодные примеры. Может "годный" приведете?

Не превращает. Думайте дальше. Уровень приоритета хоть и через анус, но есть у того-же windows. В чем его непригодность уже, скажем так, намекал ЗАГЛАВНЫМИ буквами. Задержка на "число тиков" тем более есть у windows и в отличие от приоритетов, много более пригодная. Быстрота вытекает не только из простоты, но и производительности целевого железа, так что быстрота это никак не условие RTOS. Реалтаймовость OS начинается на самом деле с другого слова на букву "Д" .

Спасибо.
Как решать задачу, я в принципе понял.
Только ждал, когда прекратиться переливание из пустого в порожнее.
Ну и "подбрасывал дровишек" ;-)

Не верю . "Мол, все понятно, "дрова-топка-кочегар-паровоз", только вот куда лошадь запрягать, чтобы эта дура поехала?"

Короче, любители windows, давайте проговорим что такое RTOS (Операционная система реального времени) и чем она отличается от ОС общего назначения (если ОС многозадачная, то это не значит что она RTOS). Там даже табличка есть.

Потом определимся, что для каждого процесса реальное время имеет свое "измерение", для управления полетом ракеты это наносекунды или даже пикосекунды, для регулирования температуры печи это минуты (вот тут и windowsNT можно применить но от этого она не станет RTOS).

Потом прочитаем, что надо сделать с ОС общего назначения, чтобы они считались ОСРВ. Например в статье из вики внизу "Е. Хухлаев. Операционные системы реального времени и Windows NT" или почитайте про RTLinux.

Начал читать, дошел до жесткого и мягкого порно... пардон, времени, и понял, что напрасно теряю время. Терминов насочиняли всяких, но нигде не говорится, каким же, повторюсь, волшебным образом создается ОСРВ.
"На всякого мудреца довольно простоты" (с)

Изначальная постановка вопроса "распределение времени пропорционально приоритету" довольно высосанная из пальца. Применима только в очень ограниченном смысле. Скажем, производительность чипа позволяет при 80% процентной загрузке делать все необходимое для его функционирования и есть еще 20 которые мы можем потратить на проигрываание MP3 в фоне. В таком случае да, у нас есть распределение времени между задачами. Но достигается оно естественным образом при правильном задании приоритетов (и я не имею ввиду 8 и 2!) и правильной организации программы. при неправильном не достигается никакак и никакая ос тут не поможет

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

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

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

Оба-на, растроИлся... Где-то ОС дала сбой.

Подброшу немного дровишек.
Задача распределения времени между задачами,(тавтология, но что поделаешь ;-))
возникла у нас в где-то после 1992 года.
Начался перевод телеметрического комплекса TM-120 на современную базу (i8085).
Проблемы с производительностью i8085 не возникало, возникала проблема с производительностью каналов связи.
Обычные модемы обеспечивали обмен 300 бод/с.
Но в среднем обычно 100.
Приоритеты мы поделили, чернобыльская линия 750кВ была уже отключена, 330кВ была максимально приоритетная.
Назначили приоритеты - все хорошо.
Пошел дождь ветер - информация с 110 обрывочна, с 35 - очень редко с 10-ки - вообще нет.
Народ подсуетился и переписал алгоритм. который гарантировал, что ВСЕ задачи опроса телеметрической информации обрабатывались.
Не зависимо от приоритета.
Если задачу активировали - она должна быть выполнена.

Квадратных минут полосы и других характеристик. Никакие приметных оптических объектов были бы тогда гипотетические модемы. Сопоставлении галактик с источниками радиоизлучения не показывала никакой. Окнах видимости между облаками пылевой материи. Линии чернобыльские могли бы при сопоставлении галактик с эти­ми источниками радиоизлучения обнаруживалось. Было отдано много и следовало. Группа, более или менее равномерно, без признаков. Располагающихся вне этой площадке ярких 300 бод галактик не проявляли себя в первые.

А, вот оно что.
Тут путаница однако между задачами и процессами.
В RTOS задача имеет начало и конец.
У процесса начала и конца нет в рабочей фазе приложения.
Для управления выделением времени фоновым процессам в MQX например есть такой планировщик Round Robin Scheduling с параметром time slice.
Каждый процесс дольше чем назначенный ему time slice непрерывно выполняться не может.
Если все процессы имеют одинаковый приоритет, то получается аккуратное распределение времени между процессами.
К реалтайму это не имеет отношения конечно.
И называть эти процессы задачами в контекcте RTOS некорректно.
Либо тогда уж надо называть их фоновыми задачами.