Есть несколько задач (программ) которые должны выполнятся с минимальным временем, можно организовать как линейный список функций, которые последовательно вызываются из главной функции main() при условии что время выполнения каждой функции ограничено т.е. внутри функции нет кода который задерживает выполнения (ожидает чего либо).
Например одна функция обрабатывает принятый массив с USARTа. другая расшифровывает принятую команду и выполняет ее, подготавливает ответ к отправке (квитирование).
Еще пару функций, которые что-то делают (обслуживают клавиатуру, исполнительные устройства). Получается все запутанно, если делать все функции в виде конечных автоматов с минимальным временем работы каждой. Хорошо было бы, если каждая функция выполнялась в виде задачи, ожидает, данные с параллельного потока пускай ждет, получила что хотела, выполняет. Есть задержка в функции скажем, на 20 секунд, пускай ждет, в это время выполняются другие функции. С операционными системами как-то все сложно, может планировщик задач да и все. Какие есть решение не сложные? Механизм взаимодействия функций друг с другом.

Ну для этого и придуманы прерывания, например для UARTа.

-->Получается все запутанно, если делать все функции в виде конечных автоматов с минимальным временем работы каждой. Хорошо было бы, если каждая функция выполнялась в виде задачи, ожидает, данные с параллельного потока пускай ждет, получила что хотела, выполняет. Есть задержка в функции скажем, на 20 секунд, пускай ждет, в это время выполняются другие функции.

Сильно смахивает на параллельность операций. В контроллере врятли получиться.

В прерываниях долго сидеть нельзя, там можно формировать массив из принятых данных и отслеживать конец посылки. А внешне проверять адрес контрольную сумму.

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

А других вариантов-то и нет. Единственное, если есть функции с наивысшим приоритетом (например, приём/передача данных по интерфейсу на максимальной скорости в большом объёме), их придётся целиком запихивать в прерывания. Можно ещё в некоторых режимах блокировать ненужные функции. Главное - не запутаться в системе флагов.

Да флагов рожлается огромное количество на сыром коде, но после оптимизации половина выкидывается. Главное, при расположении большого кода в прерывании не забывать об их приоритетах.

Можно и без вложенных прерываний в одном прерывании все обслуживать, если наименьший период вызова других прерываний не превышает времени работы в данном прерывании. Например, на скорости 9600 прерывания от UART будут не чаще чем через 1 мс. Дребезг клавиатуры за это время конечно не устранишь, а вот разобрать пакет и подготовить ответ вполне можно при достаточной производительности МК. Да и клаву тоже можно обслужить, если вызывать процедуру один раз через 9 (при дребезге клавиш не более 10мс). По крайней мере у меня на MSP430 при работе UARTа на 115200 в 10мс прерывании и клавиатура обслуживается и транспортная процедура (прием/передача/подсчет CRC/выдача ответа "занят", без разбора самого пакета) RTU-ного протокола крутится.

В винде вот красиво сделано. Там есть обработчики событий. Вся прога при этом пишется из обработчиков, которые сами себя вызывают друг за другом. Конечно, там ещё и разделение во времени чтобы тупые обработчики не завешивали систему. Вобщем есть три механизма:
1. Прерывания
2. Обработчики событий
3. Разделение во времени
Хотя может чего ещё и забыл.

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

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

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

Насколько я понимаю это в любом случае RTOS. Просто в одном случае реализованная своими силами и сильно упрощённая, ну а в другом написанная сторонними производителями, и, возможно сильно усложнённая.

Если свой упрощённый вариант, то я пишу так как не рекомендует писать уважаемый 'IgorKossak'.
То есть ввожу флаги состояний, задачи замыкаю на себя, данные напрямую не передаю, общаюсь только ч/з флаги и ОЗУ. (то есть вых. данные одной проги - входные другой). Блоки пишу таким образом, что их перестановка местами м/у собой не влияет на работоспособность программы.

Есть функции, есть планировщик задач. Функции зациклены. Выход из функции невозможен. Функция сама передает процессорное время по команде планировщику, планировщик отдает процессорное время другой функции по приоритету. Возникает вопрос как (для AVR IAR) вернутся в прерванную функцию по адресу где функция отдала управление и как в IAR сохранить рабочие регистры и какие нужно сохранять.

Программа должна выглядеть так:

do{
ReadKeys();
UpdateDisplay();
}while(true);

Всё остальное - дело флагов, указателей и счётчиков.
Главное - в ассемблерном листинге это выглядит точно так же.

В одном из своих проектов я решил подобный вопрос с помощью нехитрого планировщика , который занимался тем, что запускал функции "задачи" по расписанию.
Ввел три типа задач:
TASK_PERIODIC - запускать постоянно через определенный интервал
TASK_SINGLECALL - запустить однократно через определенный интервал
TASK_KERNEL - запускать в отдельном _idle_ цикле постоянно (к этому типу относятся всевозможные Dispatcher'ы)

Задачи помещаются в отдельные очереди и при вызове могут добавлять/удалять в/из очереди любые другие задачи. Если потребуется выполнение довольно длительной задержки (у меня таки потребовалось) внутри "задачи", то задача обязана вызывать _idle_ цикл, чтобы отрабатывали все "системные" задачи типа TASK_KERNEL (обслуживание времени, I/O и т.п.).

От флагов такой подход полностью не избавляет, но все-таки минимизирует чуть-чуть, и экономит ПП. Для сравнения этот планировщик отнимает всего ~500 байт ПП и может занимать меньше, ну а кол-во занимаемого RAM'а регулируется взависимости от потребностей проекта. (по 16 задач каждого типа займет 10*16*3 байт ОЗУ).

www.scmRTOS.narod.ru - очень подробное описание как это все делать.

Программа _может_ так выглядеть, но вовсе не должна. Суперлуп наиболее примитивный вариант реализации многозадачности, что данный код и демонстрирует - 100% ресурсов занято там, где хватило бы долей %.



Получается 10*3 байт на задачу, только на "системные" издержки? Как-то многовато. Для невытесняющей оси нужно в 4 - 5 раз меньше.

Скромная попытка объяснить необъятное двумя словами :

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

Если не хочется ждать окончания какого либо процесса - можно вообще поступить таким образом (в свое время реализовал это на z80 ПК Zx-Spectrum):

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

10 байт на задачу, 3 разных очереди. Вот такая вот структурка:

Попробуй всеж чуток с операционками разобраться, пока не с вытесняющими, кооперирующими, очень простая jacos. Если пишешь только на С, все очень просто, толково описана и примеры есть. Фриварная, с исходниками, автор баги быстро исправляет.
Как для меня оказалась проще чем я ожидал, это первая с которой столкнулся, может есть и лучше, не спорю, но реально простая и удобная, ресурсы минимально жрет, только когда на асеме вставки лупишь - лучше в дебагере детально просмотреть АСМ объекта, как всегда для сюхи

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

Осень. Пора, как все, лететь к RTOS.

Но я пока делаю по старинке.

Самые быстродействующие или просто привязанные к времени процессы распихиваю в прерывания по таймеру (причем несколько - от 500 мкс до 1 с).
Прочие процессы - в вызовы функций в цикле по индексу состояния процесса.

for(;;)
{
//process 1
event=GetKeyEvent();
if (!event) event=GetTimerEvent();
if (!event) event=GetExternalKeyboardEvent();
process1[status1]();
//process 2
event=GetIrdaEvent();
if (!event) event=GetModemEvent();
process2[status2]();
}

Особенность моих устройств - помехоустойчивость, процессы должны выполняться даже после сброса процессора и такая структура это обеспечивает.

Есть RTOS, нет ее, на этапе начала проектирования ресурсы контроллера и частота появления внешних событий должны быть просчитаны. А если все просчитано и понятно, зачем RTOS?

до нее дохдит очередь, когда задачи с приоритетами 2 и 3 неактивны.
А вот случится ли это (если должно) - вопрос к разработчику

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





Ясно, а кто задачи с приоритетами 2 и 3 делает активными - планировщик? по событиям? или планировщик, видя что все задачи не октивны, сам запускает с наивысшим приоритетом

1. Вызов по индексу - организуется массив функций и вызывается функция из этого массива. Все просто и наглядно.

2) Раз я говорю, что RTOS не использую, значит функция завершается так же естественно, как пиво в бутылке

3) А механизм передачи сообщений прост.
- Каждый процесс имеет status. Это уже достаточно информативно для того, чтобы другие процессы могли узнать, что делается в этом. Например, состояние ошибки. Жду, курю бамбук, жду событий.
- Каждый процесс генерирует события при вызове функции GetProcessNEvent().
типа if (beer_level==0) return(evBeerOver);

Это событие обрабатывается примитивно просто :
switch (event)
{ case evBeerOver: OpenBottleWithVodka();
case evVodkaOver: GoToShop();
}

Может и событие и приложение.
Это происходит при помощи различных сервисов, таких как семафоры сообщения и т.д.
Найдите мануал на какую-ть ось (я с JjacOS разбирался), там все подробно должно быть расписано.

Jacos пробовал - реально полезная вещь. Сейчас экспериментирую с scmRTOS - тоже нравится, но это уже с вытесняющей многозадачностью.

А что, исходники jacos уже появились? До сих пор, насколько я знаю, было множество библиотек под разные процессоры и варианты компиляции?

Да и насчет ответов автора - да, год-два назад так и было, подтверждаю. Но сейчас человек, который тоже использовал jacos, сообщил, что автор на его письма отвечать перестал. И разработки переехали под scmRTOS, которая реально имеет открытый исходный текст, в т.ч. для коммерческого использования.

+1
Посмотрел на сайте автора, так там нет никаких исходников... Можно ссылочку?
ЗЫ
Страшно нравится jacos, вот только что известно на счет багов?

Автор jacOS высылает исходники по запросу, напишите ему письмо, должен ответить.

Посмотрел ОС scmRTOS, jacOS, Salvo. многозадачность нужна в AVR а все операционки со своей поддержкой много МК самых разных, поддержка разных компиляторов, условная компиляция, комментарии в исходнике не поймешь, да и исходник сам не найти, компоновка в среде, закрытые подключаемые библиотеки… Можно конечно по примерам, по рекомендациям интеграции в определенную среду разработки но так до конца не поняв внутреннею работу ОС, разбираться, что где не работает, почему когда работает когда нет. Понравилась Salvo но где исходник! В моем проекте задач 6. Причем некоторые требуют жесткой временной привязки и активно используют таймеры, порты ввода вывода, ШИМ, SPI, USART. Остальные задачи, включить выключить, считать дискретный вход. Мне кажется, нужен хороший кооперативный приоритетный планировщик как, например в Salvo (вот бы его исходник) ни какой глобализации объять не объятное, только то что нужно. Осталось написать кооперативный планировщик, скажем задач 10 максимум. Может есть у кого исходник.

scmRTOS: есть поддержка AVR, один компилятор IAR, условная компиляция - и это правильно, комментарии отличные, русская документация с фрагментами исходников OS для понимания, исходники открыты для любого использования, в т.ч. коммерческого, пример использования в комплекте - собирается командной строкой (что не мешает использовать IDE), библиотек нет - только исходники. Автор оперативно отвечает.

Вот пример отладки в среде Proteus программы с использованием scmRTOS на AVR. Видно, как можно шагать по исходному коду системы.


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


Такие вещи надо стараться делать по прерываниям.


Jacos более чем подходит этому описанию, а условная компиляция позволяет отсеять то, что не используется. Один минус: отсутствие исходников и поддержки на данный момент (по известной мне информации, может, она ошибочна).

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



Исходники можно взять для jacos, и повторю, нужны они лишь при обновлении версий компиляторов. Раньше можно было немножко заплатить за поддержку, сейчас ее нет, но есть исходники.
Salvo только за деньги, за довольно приличные. Можно слямзить исходники, но лямженный порт для AVR не встечал. Может есть у кого?

Исходники можно взять для jacos, и повторю, нужны они лишь при обновлении версий компиляторов. Раньше можно было немножко заплатить за поддержку, сейчас ее нет, но есть исходники.
Salvo только за деньги, за довольно приличные. Можно слямзить исходники, но лямженный порт для AVR не встечал. Может есть у кого?
[/quote]

А у вас нет исходника jacos.

Есть. Обращайтесь к автору и у вас будет текущая версия.

>> Один минус: отсутствие исходников
Это не минус. Если система активно развивается автором - не нужно ему мешать. Ну поправите вы что-то, добавите дополнительные сервисы, а автор выпустит новую версию. И ваши проекты уже не будут совместимы с родной библиотекой. В случае с jacOS - уже вряд-ли - обновлений давно нет и не придвидится, но в общем случае править что-то в ядре RTOS - нужно разбираться во всем коде. Иначе система будет работать но в один прекрасный момент вылетит. И хорошо если в момент тестирования, а не у клиента.

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

Что касается правки, то есть и другая модель внесения изменений: пишется письмо автору, где предлагается некая функциональность и патчи примера ее внесения. Если автор считает, что это заслуживает внесения в официальный порт - он это сделает в очередном релизе. Если нет - то нет. Я такую модель обкатал на AVR-USB драйвере - она очень хорошо работает. Все, что мне было нужно, автор дописал в оригинале, сохранив совместимость с исходной версией. В итоге я просто перешел на новую версию, выкинув свои патчи, а драйвер стал более функциональным. При этом диалог был конструктивным: не "а нельзя ли добавить вот это?", а "хочется вот такое, я сделал так - прошу посмотреть и реализовать, если одобрямс".

Согласен на полминуса.
Для того чтобы лучше понять - есть документация. Если она убогая - вообще нужно отказаться от этого продукта, альтернатив всегда хватает.
Опять же, что мешает задать вопрос в техподдержку (если либа или РТОС платная) - ведь деньги платятся не только за архив с исходниками. А если бесплатное - автор, как правило сам охотно идет на контакт.
Дальше. Поставка в скомпилированных либах или объектниках - некая защита интеллектуальной собственности. Можно купить софт гораздо (в разы) дешевле.
И еще. Поставляя библиотеку, ядро РТОС в объектниках производитель может гарантировать клиенту ее работоспособность. С исходниками сложнее - в 99% указывается на то, что автор не несет ответсвенности за ошибки в ПО, если исходники каким-то образом изменены.

В общем тут перетирать эту тему очень долго можно. ИМХО начинающему исходники абсолютно не нужны и даже вредны

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

Защита собственности - да, хотя многие отличные продукты вроде scmRTOS или AVR-USB драйвера открыты. Если это критично, то можно выбирать из таких, в том числе.

А ответственности за ПО никто не несет вообще - даже Microsoft :-) Так что все это условно.

Недавно запустил scmRTOS на микроконтроллере ATmega16. Версия ОС 1.10, компилятор GCC. Никаких сложностей не встретил. Пример, приложенный к ОС, собрался сразу и без проблем. Потом написал свою, с нуля, тестовую программу. Сборка также прошла отлично. Рекомендую обратить внимание на эту ОС: есть исходники, есть хорошо написанный мануал.т Есть отзывы о ее надежной работе.

У многих "универсальных" ОС основная проблема - неоптимизированное ядро. Там бы все ручками...
А так их реакция не радует. Монопольный режим ядра, да и долгое время переключения задач.
Прикрепляю архив с "в последний лохматый раз" переделаной "переключалкой контекстов".
Описывать неохота если кому интересны подробности - спрашивайте.
Сие работает на давайсах с мега48, другой на 16.
Написано на асме и для асма (но очень хочется сами задачи на С писать, сейчас "вопрос прорабатывается").
Если кто-нибудь что-нибудь предложит по оптимизации ядра, будет хорошо.
интересны:
Функция проверки истечения таймаута;
Функция проверки говых по событию задач;
время переключения задач:
с одной на ту же около 150 тактов (примерно)
с одной на другую от 200 тактов (примерно).
прерывания рабоают в монопольном режиме.
планировщик в общем режиме.
//--------------------------------
щаз там уарт на 115200 зашит и прием зациклен на передачу через буферную систему.
При старте выдает тестовую строчку. Работоспособность проверял только что.
С уважением, yod

А ничего, что на сайте scmRTOS висит версия 2.04a-beta от 28.04.2006. Как у нее со стабильностью,как никак бета-версия. Можно ее применить в серьезном проекте.

Думаю, что можно. Для MSP430 применял именно эту бету, работает. Из нее же делал порт для ARM.

Ну jacOS, например:
Функция проверки истечения таймаута - ok;
Функция проверки говых по событию задач - ok;
время переключения задач:
с одной на ту же - 55 тактов (mega16, IAR 420A, prim2)
с одной на другую - от 55 тактов (OS_Cooperate(), скажем, OS_Delay() - 146 тактов).
прерывания рабоают в монопольном режиме - ? Не понял что имеется в виду.
планировщик в общем режиме - ok.

jacOS - это круто, потому что FSM (Finite State Machine)
и соотвественно в расчет не идет - не сравнима.

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



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

"Задача остается текущей столько времени, сколько захочет, а управление ядру передает исключительно добровольно. " это из манаула.
Я не знаю чего тут еще пояснять. Довольно прозрачно.
Т.е. существует конечный ряд состояний всего ПО, для каждого состояния можно определить набор состояний(из общего множества состояний ПО), следующих за ним, и условия перехода (в д.с. события, приоритеты). Это и есть FSM.



А как их сравнивать-то - разная идеология ("архитектура")?
в вытесняющей - сохранение контекста, вытеснение задачей задачи, там одни "такты".
в FSM - упорное выполнение "состояния", переход между состояниями - там другие такты.
Хотя критерий есть: для "RTOS в системе", не важно какая она, основной критерий - гарантированное, детерминированное время отклика на событие. Для кооперативной это считается много легче, чем для вытесняющей(если не сказать более категорично).

Если хочется сравнить "на пальцах": то за какое количество тактов провериться событие на "истечение таймаута"? за какое количество тактов провериться 10 событий на "истечение таймаута"?
в посте:

я спрашивал не "какая ОС это умеет делать", а "кто знает как эту ПиПиСку сделать "круче""?
scmRTOS ИМХО отличная ось, но эта ПиПиСка там для АВР не оптимизирована, мне очень жаль дарить бесценные "ядрёны" такты компилятору. Для "ядра" это "одна из" долгоиграющих функций (кто не понял - void OS::TKernel::SystemTimer())
//----------------------------------------------------------------------
На самом деле из-за своей детерминестической природы FSM
выглядит очень даже привлекательно. Ну а с позиций 8-ми биток, так вообще "шоколадно", это я с Вами, уважаемый, согласен.
из мануала:
"На самом деле, проблема не в том, что для кооперативной ОС нельзя добиться времени отклика сопоставимого с тем, что есть у вытесняющих. Это как раз достижимо ценой частых переключений задач. Проблема в том, что обеспечить такое переключение не всегда будет легко. " - масло масленное конечно, но верно.
Дело за малым - выработать методологию "превращения" каждой задачи в набор состояний
С этих позиций много проще прерывать задачи, сохранять и восстанавливать контекст.
//-----------------------------------------------------------------------
Я постараюсь конкретизировать:
Мне не нравиться, когда ключевые моменты ОС, "отданы в распоряжение" копмилятора С и посему
мне интересно, у кого есть оптимизированные "ядра" на АСМе или может есть какие-то концептуальные идеи реализации? я просто предложил свой вариант.
С уважением, yod

Это просто кооперативная ОСь. Ничего FSM'ного отсюда не следует.


Нет. Эдак любую программу можно к FSM'у притянуть - в любой программе всегда есть состояния.

ОС FSM'ного типа - это кооперативная ОС, в которой каждая задача организована как АВТОМАТ СОСТОЯНИЙ. Делается это для того, чтобы процессор не проводил много времени в задаче - зашел, выполнил кусок, вывалился. В следующий раз зашел и сделал другой кусок (следующую порцию общей работы). Вот так и прыгает по задаче. Латентность тут будет определеяться временем выполнения куска. А само "прыгание" по частям всего кода задачи организовывается как автомат состояний. Salvo и jacOS - обычные кооперативные ОСи, в них вы можете зайти в задачу и сидеть там по посинения, а все остальное (ну, кроме прерываний) будет стоять колом. Поэтому никто так не делает, а всегда сами руками разбивают задачу на куски, между которыми отдают управление. FSM ОС предоставляет формализованный путь сделать это. Примером именно такой ОС - nesos от товарища Нильсена.

Что-то я потерял нить...
Если все задачи реализованы как АВТОМАТ СОСТОЯНИЙ, то зачем тогда ОС? Точнее, можно ли этот способ выполнения задач назвать OC, если каждая задача гарантированно выйдет из обработки своего состояния? :
for (;;)
{
Task1();
Task2();
Task3();
}
Сам так делаю, но наглости назвать это ОС не хватает
ОС и нужна для того, чтобы не самостоятельно "врукопашную" бить каждую задачу на состояния, а чтобы планировщик автоматически предоставлял время каждой задаче. Предоставлял и отбирал, поэтому задача не может сидеть там до посинения. Иначе это не RTOS. Это Windows :-)
Ссылочку посмотрю, конечно...

Не совсем такая структура - см. ссылку на jacOS. Нечто подобное должно быть внутри каждой задачи, только там Task2() в приведенном примере - это, например, OS_Cooperate() вызов для передачи управления, а 1 и 3 - это что-то полезное, что делается в задаче.


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

А насчет Windows - да, в какой-то степени это так. Но не стоит забывать, что OS - это не только переключение задач (и связанные с этим критические секции и т.п. головная боль). Это также и средства межпроцессного взаимодействия (семафоры, очереди, сообщения, поддержка ожидания событий, задержка на заданные интервалы времени и т.п.). И эти средства при правильном их использовании могут быть исключительно удобными и полезными даже в кооперативной OS.

С формальной тз невытесняющие (НВОС) и вытесняющие (ВОС) оси отличаются тем, что задача у НВОС во время работы имеет наивысший приоритет. НВОС и ВОС теряют управление в "конечном ряде" своих "состояний", что само по себе не превращает систему в FSM - вообще не принципиально сколько у задачи есть "точек перехода" 10 или 500. Задачи в системе могут быть вполне автономны и асинхронны. И для системы нет того, о чем вы пишите: "для каждого состояния можно определить набор состояний (из общего множества состояний ПО), следующих за ним,". Все наоборот, из "состояния" одной задачи никак не следует "состояние" другой. Если совсем коротко: обычно задача совсем не знает о существовании других задач (исключения - сервисы создающие / перезапускающие задачи). Межзадачный обмен не рассматриваю по двум причинам: 1) в НВОС и ВОС он сделан одинаково, 2) его может и вовсе не быть.



Вот интересно, а как их не сравнивать-то, раз делают одно дело в одинаковых условиях? Просто беру разные оси и сравниваю, по удобству, достаточности и тп. Мой выбор для AVR - невытесняющая ось для С, причем в самых простых конфигурациях.