[_artem_ 0]

2 osnwt, в слючае роунд робин можно сделать так что для задач с одинакоым приоритетом выдача ресурсов опеределяется временем захвата ресурсов задачей и оно (время ) может быть равномерно распределено между задачами , хотя и ртос не является вытесняющей. То есть в этом случае мы не ждем завершения работы задачи а диспетчер сам останавливает или запускает ее (вне зависимости быполнила ли задача свою работу или нет). Хочу сказать что fsm машины не являются синонимом для кооперативки тоже. Для меня фсм видится как логический подход или метод для решения задачи с детерминированным количеством внутренних состояний в контексте самой этой задачи. По сути дела в каждой ртос сушествуют свои машины с конечным состоянием - допустим состояние какой либо задачи, но они не несут в себе этого названия (фсм).

[osnwt 0]

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

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

 

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

 

То есть в этом случае мы не ждем завершения работы задачи а диспетчер сам останавливает или запускает ее (вне зависимости быполнила ли задача свою работу или нет).

Вот это мне не понятно в том смысле, что как "диспетчер сам останавливает" задачу в случае кооперативной OS? Она на то и кооперативная, что прервать выполнение задачи может только она сама, и если она этого не делает, то вся оставшаяся часть системы будет стоять.

 

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

Этого я и не утверждал. Это разные подходы. Я просто сказал, что nesos, судя по всему, представляет собой гибрид. А то, в каком смысле я противопоставлял fsm & кооперативные rtos - rtos-ам вытесняющим, я уже написал.

[bialix 0]

вот еще один какбы генератор WhatOS: http://www.sticlete.com/whatos/

 

название забавное: в переводе -- нафига тебе ос?

[=GM= 0]

Еще один пример ОСРВ для МК и ДСП можно посмотреть здесь: scmRtos

 

Там есть варианты РТОС для msp430, avr и blackfin'а

[_artem_ 0]

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

 

Нет не про jacos

 

То есть в этом случае мы не ждем завершения работы задачи а диспетчер сам останавливает или запускает ее (вне зависимости быполнила ли задача свою работу или нет).

Вот это мне не понятно в том смысле, что как "диспетчер сам останавливает" задачу в случае кооперативной OS? Она на то и кооперативная, что прервать выполнение задачи может только она сама, и если она этого не делает, то вся оставшаяся часть системы будет стоять.

 

http://en.wikipedia.org/wiki/Round-robin_scheduling

http://www.geocities.com/michaelanburaj/RTOS_Theory.html

[osnwt 0]

То есть в этом случае мы не ждем завершения работы задачи а диспетчер сам останавливает или запускает ее (вне зависимости быполнила ли задача свою работу или нет).

Вот это мне не понятно в том смысле, что как "диспетчер сам останавливает" задачу в случае кооперативной OS? Она на то и кооперативная, что прервать выполнение задачи может только она сама, и если она этого не делает, то вся оставшаяся часть системы будет стоять.

 

http://en.wikipedia.org/wiki/Round-robin_scheduling

http://www.geocities.com/michaelanburaj/RTOS_Theory.html

 

По первой ссылке читаю:

 

Round Robin Scheduling is preemptive (at the end of time-slice) therefore it is effective in time-sharing environments in which the system needs to guarantee reasonable response times for interactive users.

Раунд-робин планирование есть преемптивное.

 

По второй смотрю таблицу с kernels и вижу:

 

Non preemptive: Every task is written in a way that it complete execution within its time slot & gives control for other tasks.

 

Round robin: Every task gets its chance in a sequential manner.

 

Иными словами, выходит так, что под сочетанием Non preemptive (кооперативной) RTOS и round-robin планирования понимается то, что задача обязана быть написана так, чтобы завершить свое исполнение в пределах своего временнОго слота и отдать управление другим задачам. А round-robin в данном случае - это циклический последовательный вызов задач на исполнение без учета их приоритетов, чтобы дать им поработать. При этом они по прежнему обязаны отдать управление в ограниченное временнЫм слотом время. Превышение времени выполнения (более, чем временнОй слот) - это уже нарушение требований RTOS. А большее или меньшее время выполнения в пределах этого слота никак не учитывается в кооперативных RTOS, потому говорить о гарантиях равного времени выполнения в такой системе просто нельзя.

 

Потому мне по прежнему не понятно, как из приведенных ссылок следует, что в кооперативной (non preemptive) RTOS реализуется round-robin планирование по времени так, что "диспетчер сам останавливает или запускает ее (вне зависимости быполнила ли задача свою работу или нет)". Ведь невозможность остановки выполнения задачи в non preemptive RTOS - это и есть само определение RTOS, как non preemptive.

 

PS. Тема уже ушла в сторону...

[let's see 0]

RTOS большая и многогранная тема. Нет и не может быть универсальной на все случаи жизни, а отсюда и все многообразие таких систем. Я преподавал RTOS в Советском Союзе, сейчас делаю это в Америке. Мой опыт позволяет мне судить и делать выводы. Ваше дело, коллеги, соглашаться и разделять мою точку зрения или отвергать ее. Я, ни в коем случае, не претендую на истины в последней инстанции.

Итак. Длая начала надо опредилиться с приоритетами. Что мы имеем и чего стараемся достичь. Для мира AVR характерно ограничение по RAM. а это, в свою очередь серьезно ограничивает, нo не исключает использование preemtive RTOS. Еще интереснее дело обстоит со скоростью. Кооперативная переключает контекст гораздо быстрее - ей не надо сохранять все регистры, а только необходимые (определяется компилятором), кроме того, по системному таймеру нет необходимости переключать контекст активной задачи - переключения не произойдет! Заодно, кстати, и эконом ится стек для каждой задачи и, соответственно, RAM! Еще один аргумент в пользу коопреативности. При весьма ограниченных ресурсах AVR (да и подавляющего большинства других 8 -16 битных микроконтроллеров) разбиение на ос и апликации весьма условно. Проще сказать, что мы имеем scheduler (планировщик) и функции системы. Отсюда следует вывод: каждый проект есть не что иное как новая RTOS с одним и тем же планировщиком и разнообразным набором функций. Когда пишется функция ОС, прекарасно известно о том, что можно делать, а чего нет и какие ограничения необходимо соблюдать - аналогичные требования пред'являются дле задач в кооперативной RTOS. Какое совпадение!

Другой момент, требующий особого внимания - приоритеты задач в кооперативном мире. Если приоритеты постоянны, то низкоприоритетная задача может не получить управления никогда. Если же их менять, то как? Мой совет такой: используйте 2 приоритета: высший для планировщика и round robin для всего остального. В общем случае, работает надежно.

Из всего вышесказанного, в общем случае, кооперативная RTOS это то, что лучше подходит для систем с малым об'емом RAM.

Желаю успехов!

Изменено 3 июля, 2006 пользователем pitt

[vesago 0]

Вперве применил КА когда надо было сделать контроллер двух турникетов. Теперь только на них все и делаю. Сами свитчи тоже люблю. ифы применяю редко. Код получается понятным, скоростным и сатбильным. Мне кажется для встроенных приложений это оптиамльное решение. Хотя по сравнениию с осью сложнее по началу - надо мышление приучить.

[white.wind 0]

Возможно полезным будет ресурс на тему http://softcraft.ru/auto.shtml Там есть даже варианты объектно-ориентированного подхода к автоматам (в том смысле, что тема живет и развивается)

[_artem_ 0]

Вперве применил КА когда надо было сделать контроллер двух турникетов. Теперь только на них все и делаю. Сами свитчи тоже люблю. ифы применяю редко. Код получается понятным, скоростным и сатбильным. Мне кажется для встроенных приложений это оптиамльное решение. Хотя по сравнениию с осью сложнее по началу - надо мышление приучить.

 

Вызов фунцкий по таблице указателей где переменную для switch используют как индекс к таблице работает быстрее конструкции switch.

Эт типа lookup table принцип для бранча . Если не ошибаюсь , таким макаром делают диспатч системных вызовов в осях .

[ig_z 0]

Вызов фунцкий по таблице указателей где переменную для switch используют как индекс к таблице работает быстрее конструкции switch.

Эт типа lookup table принцип для бранча . Если не ошибаюсь , таким макаром делают диспатч системных вызовов в осях .

 

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

[Bill 0]

Вызов фунцкий по таблице указателей где переменную для switch используют как индекс к таблице работает быстрее конструкции switch.

Эт типа lookup table принцип для бранча . Если не ошибаюсь , таким макаром делают диспатч системных вызовов в осях .

Вообще-то, это далеко не всегда так. В принципе, для оператора switch должны генерироваться таблицы переходов. Правда, в IAR такого не делалось раньше, но, говорят, что в последних версиях это все-таки сделано.

Изменено 4 июля, 2006 пользователем _Bill

[_artem_ 0]

Вызов фунцкий по таблице указателей где переменную для switch используют как индекс к таблице работает быстрее конструкции switch.

Эт типа lookup table принцип для бранча . Если не ошибаюсь , таким макаром делают диспатч системных вызовов в осях .

 

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

 

Кстати творение этого кодоавтомата SDL у меня вот уже где. Что интересно - наш процессор вообше функшон пойнтер не поддерживает.) Хотя это в частном .

 

Дюмаю что rtti тоже его немало пользует. Оптимайзеры блин .

Visual state говорите? Бррр, вот куда автоматика нас завела. Еще немного и у меня к автоматам аллергия начнется.)

[bialix 0]

Visual state говорите? Бррр, вот куда автоматика нас завела. Еще немного и у меня к автоматам аллергия начнется.)

 

к чужой аллергии у меня претензий нет. ваша аллергия -- ваше личное дело.

 

но предлагаю не путать теплое с мягким.

[bialix 0]

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

 

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

 

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

 

Сами по себе диаграммы состояний IVS (Iar Visual State) -- это часть стандарта UML, слегка модифицированные под нужды IVS (чего-то добавлено, даже кажется полезного). В итоге получаем проектирование жесткой системы. Наиболее вероятным кандидатом в качестве целевой платформы для генерируемой системы являются ПЛК. На это указывает многое. В частности, так любимый в ПЛК принцип "сначал читаем все входы - затем обновляем все выходы".

 

Генерируемая система хоть и представляет собой си-код, но на самом деле это табличный жесткозашитый автомат, т.е. руками сгенерированный код не отредактируешь даже при большом желании. Плохо это тем, что IVS нельзя использовать для кодогенерации отдельных разнообразных автоматов для нетипичных с точки зрения IVS задач. Так, например, IVS определяет понятие параллельных автоматов, но желание создать массив однотипных параллельных автоматов в количестве N штук не позволяет, т.е. необходимо как-то выкручиваться с copy-paste и не факт, что вам это удастся. По крайней мере для меня это стало одним из главных препятствий в использовании.

 

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

 

В общем, несмотря на красивый фасад и уйму потенциальных возможностей, для областей не связанных с ПЛК использование IVS, особенно на мелких контроллерах (типа АВР) представляется мне неоправданным.

 

Сам по себе автоматный подход (оно же синхронное программирование -- в западных источниках) мне видится единственным способом писать логику работы. НО! не всего устройства в целом в виде одного огромного автомата, а в виде N количества паралелльных слабозависимых (в идеале независимых вообще) автоматов. А там или ОС применить для жонглирования этими автоматами или просто в один бесконечный цикл их засунуть -- это дело личных пристрастий каждого.

 

Поэтому с точки зрения делать всю программу на одном жестком конечном автомате или на ОС -- я не стал бы выбирать первое (только если это задача по написанию ПО для открыванию лотка CDROM или миганию лампочек). Для реальных задач лучше использовать россыпь небольших квазипараллельно работающих конечных автоматов.

 

Сам я ОС до сих пор не пользовался, ибо по сути тщательно спроектированная система в виде набора параллельных автоматов -- это практически тоже самое, что и кооперативная ОС, только памяти жрет еще меньше и ты всегда имеешь полный контроль над процессом. Т.е. каждый раз я делаю примитивную кооперативную карусель, и мне хватает. Из набора сервисов: таймеры, фифо, реже семафоры. Это позволяет обеспечивать максимальную независимость работы разных задач, плюс регулировать насколько часто та или иная задача будет выполнять свою работу. Т.е. deadlock в таком виде невозможен, система работает предсказуемо. Что еще нужно для счастья?