Встроенные автоматы программирования

8

Я смотрю на реализацию нетривиального конечного автомата (заданного как иерархическая диаграмма состояний UML) на 32-битном MCU с gcc.

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

Также: кто-нибудь оценивал Boost MSM для встроенных приложений? Я знаю, что Boost MSM обычно оценивается как очень эффективный, но для встроенных приложений эффективность может быть измерена иначе, чем в мире программирования на ПК.

Кто-нибудь знает, как выглядит скомпилированный конечный автомат MSM? Больше похоже на таблицу переключателей или больше на таблицу переходов указателя функции? Использует ли он динамическое распределение памяти или может использоваться статически?

embedded programming state-machines ARF
источник
Я бы держался подальше от Boost MSM (и шаблонов C ++ в целом), так как они очень быстро увеличивают размер кода.
JMS
Есть некоторые другие подводные камни в C ++ , чтобы быть в курсе ...
Matt Young
@jms Это все равно, что сказать, что лесоруб должен держаться подальше от острых инструментов и вместо этого использовать молоток, потому что острыми инструментами он может порезаться. Шаблоны - это отличный инструмент, который - при правильном использовании - может увеличить скорость и уменьшить размер вашего кода, особенно для небольших микроконтроллеров. При неправильном использовании - любой инструмент может быть использован неправильно!
Вутер ван Оойен

Ответы:

8

Я был бы удивлен, если есть большая разница на 32-битном MCU. Избежание условных переходов может сэкономить вам несколько циклов, но действительно ли вы добьетесь успеха или потерпите неудачу на основе нескольких циклов? Количество состояний ожидания в вашей оперативной памяти и ПЗУ, вероятно, по крайней мере так же важно. Так же и набор команд процессора.

Преждевременная оптимизация - корень всего зла. Начните с того, что проще в реализации и обслуживании, и оптимизируйте его только в случае необходимости на основе профилирования.

Адам Хаун
источник
Я ожидал бы, что влияние на производительность структуры конечного автомата (будь то DIY или из некоторой библиотеки) - в отличие от действий - очень мало. Итак, как говорит Адам: сначала код для удобства чтения. Второй. И третье. (A на 10-й позиции: профиль. Локальная оптимизация намного ниже этого.)
Wouter van Ooijen
3

Для одной реализации UML на встраиваемом взгляните на QP framework -> http://www.state-machine.com . Оба варианта C и C ++ доступны. Сопровождающий GUI (QM) даже позволяет кодировать, используя нотацию UML. Фреймворк достаточно мал, чтобы работать на Arduino; 32-битные легко.

Олег Мазуров
источник