sergeeff 1 12 августа, 2006 Опубликовано 12 августа, 2006 · Жалоба Коллеги! Наверное многие сталкивались с задачей декодирования команд, которые поступают через внешний интерфейс в ваш контроллер. Одним из возможных вариантов реализации такого парсера - в виде автомата состояний (FSM). Ясно, что можно сесть, на бумажке нарисовать структуру такого автомата и реализовать в виде некоторого набора языковых конструкций типа switch/case. Но, когда дело доходит до практической реализации получается громоздкая и трудночитаемая программа, в которой непросто в дальнейшем что-то добавить и, скорее всего, не слишком оптимальная. Вопрос. Не сталкивался ли кто с программами, автоматизирующими процесс декодирования такого потока команд? Ну что-нибудь типа bison'а, lex'a применительно к встроенным приложениям? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yornik 0 12 августа, 2006 Опубликовано 12 августа, 2006 · Жалоба А в чем Вам видится отличие синтаксического парсера для встроенных приложений от "просто" парсера? %) Ну или иначе - что мешает использовать yacc/bizon? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergeeff 1 12 августа, 2006 Опубликовано 12 августа, 2006 · Жалоба А в чем Вам видится отличие синтаксического парсера для встроенных приложений от "просто" парсера? %) Ну или иначе - что мешает использовать yacc/bizon? Ну, например, пришел пакет с данными (через USB или TCP/IP) или просто идет посимвольный прием через паралелльный/последовательный порт. Соответственно принимается за раз только часть команды или даже один символ команды. А yacc/bizon ориентированы на чтение некоторых законченных лингвистических конструкций из входного потока (файла). В этом мне видится коренное отличие. Да и насчет быстродействия в этих системах - это тоже вопрос. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mihail Filonenko 0 30 августа, 2006 Опубликовано 30 августа, 2006 · Жалоба А в чем Вам видится отличие синтаксического парсера для встроенных приложений от "просто" парсера? %) Ну или иначе - что мешает использовать yacc/bizon? Ну, например, пришел пакет с данными (через USB или TCP/IP) или просто идет посимвольный прием через паралелльный/последовательный порт. Соответственно принимается за раз только часть команды или даже один символ команды. А yacc/bizon ориентированы на чтение некоторых законченных лингвистических конструкций из входного потока (файла). В этом мне видится коренное отличие. Да и насчет быстродействия в этих системах - это тоже вопрос. Так как список команд известен то можно построить дерево команд и после приёма очередного символа переместиться в другой узел. А гуляние по дереву можно организовать рекурсивно. Тогда код не будет большим и громозким, нужна будет только память для построения дерева. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergeeff 1 7 сентября, 2006 Опубликовано 7 сентября, 2006 · Жалоба Вопрос то в том, как бы автоматизировать процесс создания такого парсера. Руками и головой можно написать - ясное дело. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
serj_obninsk 0 4 октября, 2006 Опубликовано 4 октября, 2006 · Жалоба Минуточку! Так lex, если мне не изменяет память, как раз таки и вылавливает _слова_ (лексемы, термины, токены, команды - можно называть по-разному) из потока _символов_ (пользуясь лексическим описанием языка). А bison уже оперирует потоком _слов_, и анализирует грамматику. Или я не прав? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SasaTheProgrammer 0 4 ноября, 2006 Опубликовано 4 ноября, 2006 · Жалоба А в чем Вам видится отличие синтаксического парсера для встроенных приложений от "просто" парсера? %) Ну или иначе - что мешает использовать yacc/bizon? Ну, например, пришел пакет с данными (через USB или TCP/IP) или просто идет посимвольный прием через паралелльный/последовательный порт. Соответственно принимается за раз только часть команды или даже один символ команды. А yacc/bizon ориентированы на чтение некоторых законченных лингвистических конструкций из входного потока (файла). В этом мне видится коренное отличие. Да и насчет быстродействия в этих системах - это тоже вопрос. В таких случаях систему строят несколько иначе, чем с "классическими" парсерами. Во-первых, очень чётко оговаривают условия окончания команды, включая таймауты, пропуск пакетов и пр. У "классиков" на входе готовый файл, в случае чего и трапнуться можно, а для встроенных приложений это смертный грех. Всё подозрительное выбрасывается, возможно, с посылкой NAK'а. Во-вторых, парсеры обычно не универсальные, а сильно ограниченые, с жёсткой структурой строки/пакета. Строятся они примерно по одному и тому-же принципу. Сначала выделяется мнемоника/код команды, после чего всё принятое отдаётся соответствующему обработчику ("хендлеру"). Если формат особо жёсткий, то предварительно разбираются параметры - в жёстком формате они у всех команд однотипны. Обработчик может продолжить ветвление в зависимости от значений параметров. А вот дальше начинается настоящее Искусство - учёт взаимозависимости команд и/или состояния системы. Поступило три команды - одна уже начала выполняться, можно ли выполнять остальные? Первая долгая, третья короткая, но высокоприоритетная, важная, а вторая просит подтвердить результат выполнения первой... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergeeff 1 5 ноября, 2006 Опубликовано 5 ноября, 2006 · Жалоба Ну сразу видно, что человек тоже этой темой озабочен и понимает специфику. Но насчет автоматизации данного дела - так ничего и не видно на горизонте? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gall 0 5 ноября, 2006 Опубликовано 5 ноября, 2006 · Жалоба Я для подобных задач приспосабливал аналоги lex/yacc (antlr, ply и проч.). Действительно геморрой есть, но спасает то, что часто FSM не очень-то и сложен. К тому же можно хитрить. Если позволяет процессор, можно делать указатели на функции и выбирать по таблице их; на x86 я как-то делал такое через xlat+jmp. Сам цикл fsm стал буквально в 20 команд на ассемблере. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться