Конечный автомат против RTOS для микроконтроллеров

Question

Я наткнулся на свободный конечный автомат . Похоже, это для графического программирования встроенных систем. Тем самым автор утверждает, что полученный код более удобен в обслуживании, чем если бы использовалась ОСРВ. Этот инструмент основан на UML, который приятно знать, но имеет крутой курс обучения.

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

Я занимаюсь разработкой встроенного приложения для микроконтроллера LM3S5P36 . У TI есть IDE, которая называется Code Composer Studio (CCS). Я еще не попал в CCS, но сомневаюсь, что у него есть классная особенность, заключающаяся в возможности ввести желаемое поведение в диаграмму конечного автомата, повернуть рукоятку и открыть код C или C ++. Затем вернитесь и отредактируйте диаграмму, чтобы создать соответствующий пересмотренный код. Я запрограммировал микроконтроллеры на C, но почти ничего не знаю о UML. В прошлом я поддерживал два файла, один из которых - код микроконтроллера, а другой - блок-схему. Каждая ревизия кода подразумевала ведение двух отдельных файлов.

Итак, моя дилемма заключается в том, что, обнаружив этот классный инструмент «все в одном», включающий диаграмму в код, я бы с удовольствием его использовал, но, более того, я просто хочу завершить свой проект. Я делаю это по-старому или провожу несколько недель, изучая UML?

Answer 1

Вас также может заинтересовать книга Миро Самека " Практические UML Statecharts на C / C ++ ".Обратите внимание, что Миро является основателем и президентом Quantum Leaps, поэтому эта книга неразрывно связана с этим инструментом.

Похоже, что Миро много вложил в разработку диаграмм состояния по сравнению с разработкой ОСРВ, написавКнига и блог на эту тему широко.Он начал тему в группе встраиваемого оборудования реального времени в LinkedIn под названием " Является ли ОСРВ действительно лучшим способом проектирования встроенных систем? " - там много мнений по этому вопросу !.

Я не уверен, что оба обязательно различны;часто полезно (и часто делается) реализовывать отдельные потоки RTOS как конечные автоматы.В своем блоге он делает несколько хороших замечаний: « Я ненавижу ОСРВ , но его рассуждения в значительной степени основаны на плохом дизайне приложений, чем на самой технологии ОСРВ. Так же, как С или С ++ могут быть опасны, когда используются неуместно,может RTOS. Что я обычно вижу, это приложения с слишком малым количеством нитей с плохой связностью и жесткой связью, но я уверен, что Миро будет рвать на себе волосы, думая, что решение - это больше нитей !

UML 2.2 определил 14 типов диаграмм, конечный автомат - всего один, поэтому нет необходимости изучать UML полностью. Он используется в этом случае, потому что это четко определенная модель с четким синтаксисом и семантикой, пригодный для определения поведенческих подробностей. Диаграммы конечного автомата (или диаграммы состояний), вероятно, являются наиболее простыми для понимания диаграммами поведения UML и имеют наиболее четко определенную семантику из любой диаграммы UML.

Answer 2

Один подход, который может удовлетворить ваши потребности, представлен на http://www.StateSoft.org. Он использует очень маленькое, но функционально полное подмножество UML - если вы посмотрите на набор графических API в State Machine Gallery, вы узнаете необходимое подмножествоUML SM обозначение интуитивно в считанные минуты.Для эффективности использования памяти встроенной системы производится высокооптимизированная таблица.В зависимости от того, используете ли вы C или C ++, вы выбираете компактный табличный исполнитель.

Answer 3

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