Какой дизайн применить для встроенного конечного автомата
Мне нужно сделать конечный автомат для аппаратного устройства. В нем будет более 25 штатов, и я не уверен, какой дизайн применить.
Потому что я использую C++11 Я думал об использовании OOP и реализовать его с помощью State Pattern, но я не думаю, что это подходит для встроенной системы.
Должно ли это быть больше похоже на дизайн в стиле C? Я не кодировал его раньше. Может кто-нибудь дать мне несколько советов о том, какой дизайн лучше всего подходит?
Системная информация:
ARM Cortex-M4
1 MB Flash
196 KB Ram
Я тоже видел этот вопрос, принятые ответы указывают на дизайн таблицы, другой ответ на State pattern дизайн.
Решение
Шаблон состояний не очень эффективен, потому что любой вызов функции проходит, по крайней мере, через указатель и поиск в vtable, но до тех пор, пока вы не обновляете свое состояние каждые 2 или 3 такта или не вызываете функцию конечного автомата в цикле, критичном к времени. все должно быть в порядке. Ведь М4 — довольно мощный микроконтроллер.
Вопрос в том, нужно вам это или нет. На мой взгляд, шаблон состояния имеет смысл только в том случае, если в каждом состоянии поведение объекта значительно отличается (с учетом необходимости использования различных внутренних переменных в каждом состоянии) и если вы не хотите переносить значения переменных во время переходов состояний ,
Если ваш TS подразумевает только переход от А к В при чтении альфа-события и генерации бета-сигнала в процессе, тогда классический подход на основе таблицы или коммутатора является гораздо более разумным.
РЕДАКТИРОВАТЬ:
Я просто хочу уточнить, что мой ответ не подразумевался как утверждение против c ++ или ООП, которое я определенно использовал бы здесь (в основном из личных предпочтений). Я только хотел отметить, что State Pattern может быть излишним, и то, что кто-то использует c ++, не означает, что он / она должен везде использовать иерархии классов, полиморфизм и специальные шаблоны проектирования.
Другие решения
Рассмотрим Фреймворк активного объекта QP, основа для реализации иерархических конечных автоматов во встроенных системах. Это описано в книге, Практические диаграммы состояний UML в C / C ++: программирование на основе событий для встроенных систем Миро Самек. Кроме того, глава 3 книги описывает более традиционные способы реализации конечных автоматов в C и C ++.
Ничего плохого в классе. Вы можете определить перечисление и передачу ‘State’ в событиях или очередь, используя переключение регистра State для доступа к коду / функции действия corect. Я предпочитаю это для более простых механизмов контроля состояния оборудования, чем для классического подхода «State-Machine 101», управляемого таблицами. Настольные движки очень гибки, но могут быть немного сложными для сложной функциональности и несколько более сложными для отладки.
Должно ли это быть больше похоже на дизайн в стиле C?
Боже, НЕТ!