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


8

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

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

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

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


Я бы держался подальше от 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-битные легко.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.