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

[Lem]

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

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

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

[_artem_]

имхо автомат конечных состояний и ртос это две различные веши и их сравнение не является корректным.

[osnwt]

имхо автомат конечных состояний и ртос это две различные веши и их сравнение не является корректным.

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

В этом плане реализации похожи по ресурсам как памяти, так и времени.

В отличие от этого в преемптивной RTOS мы можем позволить себе писать сколь угодно долго работающие задачи, не беспокоясь о том, чтобы дать поработать другим. За переключением следит сама RTOS. Но это влечет за собой существенно бОльшие накладные расходы как по памяти (на сохранение контекста), так и по времени (на его переключение).

Я имел в виду только этот момент, а никак не сходство идеологий.

[_artem_]

имхо автомат конечных состояний и ртос это две различные веши и их сравнение не является корректным.

В кооперативной RTOS мы попадаем в задачу, выполняем (также быстро) определенные действия и возвращаем управление диспетчеру задач.

а как для случая роунд робин в котором переключение задачи не обьязательно управляется ею самой ?

[osnwt]

В кооперативной RTOS мы попадаем в задачу, выполняем (также быстро) определенные действия и возвращаем управление диспетчеру задач.

а как для случая роунд робин в котором переключение задачи не обьязательно управляется ею самой ?

Не совсем понял вопроса.

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

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

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