Подскажите пожалуйста, про многозадачность. Опции

[_Алекс]

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

[yod]

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

Прикрепленные файлы

 AVRasmOS.zip ( 36.65 килобайт ) Кол-во скачиваний: 69

 

[µµC]

Функция проверки истечения таймаута;
Функция проверки говых по событию задач;
время переключения задач:
с одной на ту же около 150 тактов (примерно)
с одной на другую от 200 тактов (примерно).
прерывания рабоают в монопольном режиме.
планировщик в общем режиме.

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

[yod]

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

[µµC]

потому что FSM (Finite State Machine)

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

и соотвественно в расчет не идет - не сравнима.

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

[yod]

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

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

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

Ну jacOS, например:
время переключения задач:
с одной на ту же - 55 тактов (mega16, IAR 420A, prim2)
с одной на другую - от 55 тактов (OS_Cooperate(), скажем, OS_Delay() - 146 тактов).

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

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

Функция проверки истечения таймаута;
Функция проверки говых по событию задач;

Функция проверки истечения таймаута - ok;
Функция проверки говых по событию задач - ok;

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

[dxp]

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

"Задача остается текущей столько времени, сколько захочет, а управление ядру передает исключительно добровольно. " это из манаула.
Я не знаю чего тут еще пояснять. Довольно прозрачно.

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

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

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

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

[Dog Pawlowa]

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

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

[osnwt]

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

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

ОС и нужна для того, чтобы не самостоятельно "врукопашную" бить каждую задачу на состояния, а чтобы планировщик автоматически предоставлял время каждой задаче. Предоставлял и отбирал, поэтому задача не может сидеть там до посинения. Иначе это не RTOS. Это Windows :-)

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

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