Автоматный подход (SWITCH), Поделитесь опытом использования Опции

[Lem]

Решил в последнее время освоить более строгие-формальные методы проектирования программ для МК (да и для ПК). Делаю уже третий проект с помощью КА. правда, я использую некую смесь из того, что где-то прочитал и того, что сам придумываю по ходу. При этом всё выполняется на бумаге (проектирование КА), а далее ложится на код, по моим личным предпочтениям.

Результаты положительные, но тут хотелось бы спросить совета профессионалов, каким путём дальше идти, стоит ли использовать кодогенераторы и прочее ПО и т. д.

Интересно было бы узнать, насколько часто микроконтроллерщики используют автоматный подход к проектированию программ. Какое ПО при этом используется (Visual State etc.), каковы результаты (увеличение скорости разработки, надёжности, улучшение взаимопонимания в коллективе разарботчиков).

[_artem_]

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

[osnwt]

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

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

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

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

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

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

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

[_artem_]

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

Нет не про jacos

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

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

http://en.wikipedia.org/wiki/Round-robin_scheduling
http://www.geocities.com/michaelanburaj/RTOS_Theory.html

[osnwt]

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

Вот это мне не понятно в том смысле, что как "диспетчер сам останавливает" задачу в случае кооперативной 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. Тема уже ушла в сторону...