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

"Задача остается текущей столько времени, сколько захочет, а управление ядру передает исключительно добровольно. " это из манаула.
Я не знаю чего тут еще пояснять. Довольно прозрачно.
Т.е. существует конечный ряд состояний всего ПО, для каждого состояния можно определить набор состояний(из общего множества состояний ПО), следующих за ним, и условия перехода (в д.с. события, приоритеты). Это и есть 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 - невытесняющая ось для С, причем в самых простых конфигурациях.

2vod

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

Для этого есть такая рееедко применяемая ,но всетаки существующая команда косвенного перехода на подпрограмму по Z icall .

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

1 Заместь векторов в таблице указываем вызов планировщика
Например заместь
rjmp PROG
rjmp INT0
rjmp INT1
.....

Пишем
rcall PLAN_START
rcall PLAN
rcall PLAN
.....

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

2 К этому адрессу плюсуем адрес начала векторов прерываний одной из программ который выбрал планировщик ,подвигаем стек,и переходим на вектор,ну а дальше как обычно.

3 Естественно в PLAN_START обнуляем память до RAMEND-1 ,последняя ячейка у нас для выбора программы,ну и т.д.

Вот такие извращения.

Что нам это дает?
Можно просто тупо соединять несколько программ,с сохранением абсолютно ВСЕХ прерываний для каждой программы без каких либо переделок,все что нужно если хотим программно перепрыгивать из одной программы в другую - дописать в нужном месте номер проги в последнюю ячейку и call PLAN_START

to bodja74

Этим вызовом я инициализирую
1. в стек задчи сохраняю адрес возврата (в д.с. стартовый адрес)
2. инициализирую соотв. ячейку в таблице указателей задач текущим указателем стека задачи
после всей инициализации молча прыгаю в планировщик. там пусть сам выбирает
[offtopic]

Я пока "не догнал", как там "матеро" можно его использовать, но будем думать. Там еще проблема.
Я регистр Z оставил для пользования прерываниям - такая специфика - надо каждые __256 тактов__ _гарантировано_ обновить ШИМ-регистр таймера. А все значения в таблице прописаны во флэш.
таблица 1кб

ИМХО напрасно, если писать что-то тяжелее "эха" на уарте.

Ну то что Вы копали, спасибо кстати, это и есть "реализация своеобразной многозадачности".
про проги небольшие молчу - свою "ОС" пользую когда прога занимает от 1кб.
[/offtopic]

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

В реализиции "AVRasmOS.zip" на любой евент может быть назначена любая комбинация задач.
ну а в прерывании ____EVENT_SET и в путь
просто лишний переход RCALL (как у Вас) и последющие вычисления требует (ИМХО навскидку) многовато тактов и не способствуют универсализиции, той что не потребует много накладных расходов.

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


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

Хе,ну я уже говорил,я легко вцепил к своему осцилу генератор видео,без лишних телодвижений.
Вот "скоростной" вариант планировщика прерываний

Переход на подпрограмму фиксировано увеличивается на 16 тактов для любого прерывания и любой программы
Кто придумает короче поставлю пиво!!!
В основной программе и подрограммах не используются R2,R16,Z в прерывания можно использовать в качестве промежуточных. В (ramend-1) и ,(ramend) заносится адресс выбранной программы,естественно при иницилизации стека (ramend-2)

ЗЫ В принципе подобные подходы вравнивать ,тоже самое что сравнивать топор с колесом,но думаю кто интересуется многозадачностью будет из чего выбрать

.def Zero = rxx ;любой регистр

clr Zero ; в инициализации нулевая константа часто используется


;adc ZL,R16 ;Складываем адресс программы и адресс вектора
; brcc (PC+2) ;если у нас флаг переноса значит ZH+1
; inc ZH

;в первой строке ошибка !!!

add zl,r16
adc zh,Zero

Кто придумает короче поставлю пиво!!!

, ,

Заместь adc нужно add

В этом коде ,есть еще одна ошибка ,исправив ее,ускорим выполнение еще на 1такт.

Стек уже подправлен, поэтому надо вместо icall поставить ijmp. Выигрыш 1 такт.
Короче, с вас пиво, вас за язык никто не тянул(:-).

Абсолютно верно,ДВА ПИВА!!!
, , ,

Ну ладно, при случае(:-). А вы где территориально?

Кстати, почему изначально 16 тактов было, должно вроде быть 17(:-).

Вот еще подумал, используются три регистра, не гуд. А мы знаем, что первый pop r16 заносит гарантированный ноль. Если написать так

то будет использоваться всего один регистр r2. Но, конечно, под каждое i-ое прерывание должна быть своя подрограмма PLANi и своя константа vector(i) (1, 2, 3, …)

Украина,Бердичев

Команда brcc (PC+2) выполняется за 1 такт если условие не выполняется ,и за 2 если перепрыгивает.
хотя если учесть, что заменяется в векторах jmp(rjmp) на call(rcall) тогда +1

Ну раз такая жара ,тогда в векторах ставим
.org 0
jmp(rjmp) PLAN_START
jmp(rjmp) PLAN1
jmp(rjmp) PLAN2
....

и сносим pop R2
в результате

Хотя перспектива включения такого кода для каждого прерывания меня не очень радует,но звание "сверхскоростного" он заслуживает.

GM Ну ладно, при случае(:-). А вы где территориально?

bodja74 Украина,Бердичев

Ясенько, вам пора музей контрабандистов открывать(:-). Еще вроде там венчание Бальзака было, в костеле...А Никольская церковь стоит?

bodja74 Ну раз такая жара, тогда в векторах ставим
.org 0
jmp(rjmp) PLAN_START
jmp(rjmp) PLAN1
jmp(rjmp) PLAN2
....
и сносим pop R2
в результате

Код

PLANi:  lds  ZH,(ramend-1) ;адрес начала выбранной проги
        lds  ZL,(ramend)
        in   r2,SREG       ;cохраням SREG
        adiw zl,vector(i)  ;реальный адрес вектора
        out  SREG,R2       ;востанавливаем SREG
        ijmp

bodja74 Хотя перспектива включения такого кода для каждого прерывания меня не очень радует, но звание "сверхскоростного" он заслуживает

Ну раз пошла такая пьянка... Если хранить адрес проги не в памяти, а в регистрах (r5-r4), то получим суперсверхскоростной код(:-)

Код

PLANi:  in   r2,SREG       ;cохраням SREG
        movw r30,r4        ;current program address
        adiw zl,vector(i)  ;реальный адрес вектора
        out  SREG,R2       ;востанавливаем SREG
        ijmp

Ужоснах, если сравнивать с исходным кодом(:-). Всего 5 слов кода на прерывание, не так уж и много для вставки. Зато скорость удвоилась: 10 тактов по сравнению с 20 исходными! Это ж скока пива! Не, я стока не выпью(:-)