Можно, но (при моём руководстве) боязно делать настолько узкозаточенные алгоритмы — а вдруг попросят сделать последовательность из 7 кнопок? И не говорите мне что если кнопок всего 4, то нужно 2 бита на сигнал и в Uint32 влезет последовательность из 16 кнопок.
Хотя идея тоже красивая в своей оптимизированности.
Дальнейшее оформление — дело вкуса.
В принципе лучше в функцию doFSM выделять отдельный шаг автомата, а не весь цикл. Тогда можно делать «вложенные» машины состояний, когда шаг одной вызывает событие в другой и т.д.
А ещё можно к таблице переходов прикрутить имя автомата и текущее состояние и передавать эту структуру в doFSM. Тогда можно обойтись вообще одной функцией на все автоматы и несколькими структурами с таблицами переходов. Но я решил не перегружать статью, а то можно бесконечно писать.
Можно объявлять как const. Тогда уж сразу же надо заставить компилятор выделать под enum не int, а минимально необходимое число байт.
Но тогда нельзя (сложно) будет переконфигурировать «на лету», т.е. в моём случае, менять кодовые последовательности. Это не всегда нужно, но иногда приятно — например при создании перепрограммируемого кодового замка.
Вообще-то — да. Регулярные выражения здесь вообще overkill.
А вот с поиском подстроки в строке есть несколько нюансов:
Так как нельзя дождаться окончания строки, а надо реагировать на каждый символ, то приходится хранить где-то уже пришедшую строку.
Если образцов несколько — то надо при приходе каждого символа сравнивать получившуюся строку с каждым из образцов.
Если экономить память — то нужно хранить последние m символов в кольцевом буфере и писать собственную реализацию алгоритма поиска подстроки в строке работающую не на подряд идущей строке, а на буфере. Если не писать свою реализацию — надо при приходе каждого символа накопленную строку из кольцевого буфера копировать в линейный.
В принципе всё это решаемо, но по итогам я подумал что собственный ДКА будет компактнее.
Хотя идея тоже красивая в своей оптимизированности.
В принципе лучше в функцию doFSM выделять отдельный шаг автомата, а не весь цикл. Тогда можно делать «вложенные» машины состояний, когда шаг одной вызывает событие в другой и т.д.
А ещё можно к таблице переходов прикрутить имя автомата и текущее состояние и передавать эту структуру в doFSM. Тогда можно обойтись вообще одной функцией на все автоматы и несколькими структурами с таблицами переходов. Но я решил не перегружать статью, а то можно бесконечно писать.
Но тогда нельзя (сложно) будет переконфигурировать «на лету», т.е. в моём случае, менять кодовые последовательности. Это не всегда нужно, но иногда приятно — например при создании перепрограммируемого кодового замка.
А вот с поиском подстроки в строке есть несколько нюансов:
Так как нельзя дождаться окончания строки, а надо реагировать на каждый символ, то приходится хранить где-то уже пришедшую строку.
Если образцов несколько — то надо при приходе каждого символа сравнивать получившуюся строку с каждым из образцов.
Если экономить память — то нужно хранить последние m символов в кольцевом буфере и писать собственную реализацию алгоритма поиска подстроки в строке работающую не на подряд идущей строке, а на буфере. Если не писать свою реализацию — надо при приходе каждого символа накопленную строку из кольцевого буфера копировать в линейный.
В принципе всё это решаемо, но по итогам я подумал что собственный ДКА будет компактнее.