Коллеги!

Наверное многие сталкивались с задачей декодирования команд, которые поступают через внешний интерфейс в ваш контроллер. Одним из возможных вариантов реализации такого парсера - в виде автомата состояний (FSM). Ясно, что можно сесть, на бумажке нарисовать структуру такого автомата и реализовать в виде некоторого набора языковых конструкций типа switch/case. Но, когда дело доходит до практической реализации получается громоздкая и трудночитаемая программа, в которой непросто в дальнейшем что-то добавить и, скорее всего, не слишком оптимальная.

Вопрос. Не сталкивался ли кто с программами, автоматизирующими процесс декодирования такого потока команд? Ну что-нибудь типа bison'а, lex'a применительно к встроенным приложениям?

А в чем Вам видится отличие синтаксического парсера для встроенных приложений от "просто" парсера? %) Ну или иначе - что мешает использовать yacc/bizon?

Ну, например, пришел пакет с данными (через USB или TCP/IP) или просто идет посимвольный прием через паралелльный/последовательный порт. Соответственно принимается за раз только часть команды или даже один символ команды. А yacc/bizon ориентированы на чтение некоторых законченных лингвистических конструкций из входного потока (файла). В этом мне видится коренное отличие. Да и насчет быстродействия в этих системах - это тоже вопрос.

Так как список команд известен то можно построить дерево команд и после приёма очередного символа переместиться в другой узел. А гуляние по дереву можно организовать рекурсивно. Тогда код не будет большим и громозким, нужна будет только память для построения дерева.

Вопрос то в том, как бы автоматизировать процесс создания такого парсера. Руками и головой можно написать - ясное дело.

Минуточку!
Так lex, если мне не изменяет память, как раз таки и вылавливает _слова_ (лексемы, термины, токены, команды - можно называть по-разному) из потока _символов_ (пользуясь лексическим описанием языка). А bison уже оперирует потоком _слов_, и анализирует грамматику. Или я не прав?

В таких случаях систему строят несколько иначе, чем с "классическими" парсерами. Во-первых, очень чётко оговаривают условия окончания команды, включая таймауты, пропуск пакетов и пр. У "классиков" на входе готовый файл, в случае чего и трапнуться можно, а для встроенных приложений это смертный грех. Всё подозрительное выбрасывается, возможно, с посылкой NAK'а.
Во-вторых, парсеры обычно не универсальные, а сильно ограниченые, с жёсткой структурой строки/пакета. Строятся они примерно по одному и тому-же принципу. Сначала выделяется мнемоника/код команды, после чего всё принятое отдаётся соответствующему обработчику ("хендлеру"). Если формат особо жёсткий, то предварительно разбираются параметры - в жёстком формате они у всех команд однотипны. Обработчик может продолжить ветвление в зависимости от значений параметров.
А вот дальше начинается настоящее Искусство - учёт взаимозависимости команд и/или состояния системы. Поступило три команды - одна уже начала выполняться, можно ли выполнять остальные? Первая долгая, третья короткая, но высокоприоритетная, важная, а вторая просит подтвердить результат выполнения первой...

Ну сразу видно, что человек тоже этой темой озабочен и понимает специфику. Но насчет автоматизации данного дела - так ничего и не видно на горизонте?

Я для подобных задач приспосабливал аналоги lex/yacc (antlr, ply и проч.). Действительно геморрой есть, но спасает то, что часто FSM не очень-то и сложен. К тому же можно хитрить. Если позволяет процессор, можно делать указатели на функции и выбирать по таблице их; на x86 я как-то делал такое через xlat+jmp. Сам цикл fsm стал буквально в 20 команд на ассемблере.