Стоит задача разаработать устройство которое должно иметь возможность управляться через UART.
Думаю встроить отладочную консоль чтобы можно было посылать в устройство комманды и получать ответы.
Комманды в виде одиночных символов реализовал. Теперь хочу расширить функциональность консоли и реализовать длинные команды
(наподобие АТ-комманд). Причём хочется сделать аппаратно-независимую консоль чтобы можно было переносить из проекта в проект меняя только низкоуровневые функции приёма/отправки символовов через UART.

Подскажите кто как делает подобные консоли. Интересует прежде всего как осуществляется поиск комманд в потоке принимаемых символов (выделение слов длиной 2 и более символа)? Какие стандартные библиотеки можно использовать?

Сейчас реализована входная FIFO-UART которая заполняется в прерываниях и функция считывания символа из FIFO которая возвращает -1 если нет данных или принятый символ. Одиночные символы отлавливать легко (считал - обработал), два - уже сложнее но пока реализую устанавливая флаги.
Как отловить три и более символа - вот тут нужны идеи

У Вас все просто: все что отдал - сканкод, все что принял - подлежит отображению...
Я другое имел ввиду. К примеру возьмем дисплей с управляемой внешне подсветкой. Скажем, увеличить на одну градацию - символ "h", уменьшить - "l" . Остальное - отображаем. Как тогда контроллер отреагирует на на сообщение "hello world", если не использовать детерминацию ни по длине строки, ни по времени между поступлениями символов? Если же команды будут длинными, типа "light_background_down" / "light_background_up", то лишними проверками можно себя не утруждать - шанс, что потребуется отобразить именно такую строку, минимален. В этом суть моего первого замечания...

Понятно.
Пожалуй, мы ушли далеко от обычного определения консоли.
Если устройство выдает "промпт", а человек как-то реагирует в пределах предоставленных ему возможностей, то подобные коллизии исключаются.

А все-таки, если у человека тупо буфер, нету манагера кучи для построения деревьев в ОЗУ - АВР средненький, короче, - так построить интерпретатор команд не получится!


Ага, ОРС-серверы всякие не забывают, а тут-досада
Ничего сложного в универсальной программе - все действия реализуются через регистровую модель. В одном регистре - временной интервал выборки, в другом - адрес источника, в третьем - размер данных. К терминалке это уже не будет иметь отношение - это личное дело девайса - поддержит он данную функцию или нет.



Это все бессмысленно без
а) строгого разделения команд без аргументов, хотя бы пробелами.
б) минимального синтаксического разбора команд с аргументами.

ОРС-серверы - это для устройств, постоянно находящихся на связи. Тут действительно, забыть проблематично Если же терминал применяется изредка, то шансы возрастают.



Как реализовать через регистровую модель мини-DOS для флеш-карточки, например?

Легко. Регистр адреса + регистр данных + регистр управления/статуса.
Остальное - епархия девайса.

Что-то не могу себе представить... Расскажите чуть подробнее, как, например, будет реализована команда "DIR"?

Тогда лучше определиться, что мы хотим - получить блочное устройство накопитель данных или девайс, общающийся посредством терминала. А команда DIR - средствами оси.

Насколько я понял, автор темы хочет консоль управления/отладки.
Если мы реализуем блочное устройство и будем читать карточку средствами оси, то это мало поможет нам отлаживать код работы с файловой системой внутри устройства.

Именно. Мне нужна консоль в устройстве чтобы посылая определённые команды из терминала можно было изменить настройки, перепрошить устройство, считать текущие параметры и т.д. Ничего сверхумного и сверхсложного не нужно.
Может быть я даже неправильно назвал тему - скорее нужно было назвать "как отловить из потока симмволов команды длиной более 2х символов".
Но пару идей в дискуссии по тому как это сделать (ну и как собственно организовать консоль и систему команд) я уже приметел

Все спасибо за дисскуссию. Надеюсь она не остановится и ещё прозвучит ещё много идей

По поводу длинных команд - буквы F, E, L не так информативны как WFLASH, EFLASH, WLOCK и т.п.
Сразу видно что я хочу записать флэш, стереть её, записать лок-биты. Вобщем небольшое увеличение длины команды позволяет сразу переходить на необходимую подпрограмму обработки. Будет и самому интуитивно понятнее и система команд значительно расширяется.

Сообщение отредактировал mempfis_ - Aug 13 2009, 06:46

Тогда здесь регистровая модель(у нас с Вами болтовня именно с нее началась) - никаким макаком. Но, вернемся к периодическому опросу АЦП или чего другого. Очевидно, что хотя бы период опроса может быть регулируемым.


И обязательная команда help (лучше "?")для всех приборов.
А еще страшнее - контекстная помощь, например help WFLASH или ?WFLASH - как по мне, то лучше в постфиксной форме . Объясню: "?" может рассматриваться как стандартный аргумент команды, минимум писанины. Дополнительные хинты уже зависят от принятой команды.

И еще раз скажу: просто команды - это уже обговорили. А как же быть с аргументами? Они ж тоже переменной длины!

Дык, какие проблемы? Аргументы (всё что после команды) передаются обработчику. Там может быть и период:
>POOLADC 0 0 20 - опросить АЦП, число опросов 0 (до нажатия кнопы), канал 0, интервал 20 мс.



+1, кроме постфиксной формы. Зачем делать это в каждой команде, проще централизованно
Типа :

Ага. Не увидел сразу.
? без параметров вываливает список команд из CommandTable[]

Ну, сразу и не было, я убрал, чтоб не загромождать идею



Ага. Плюс к этому есть такой же массив описаний переменных, с именем перемнной, ф-ями Get/Set, типом переменной границами и описанием (для хелпа). Я таскаю это хозяйство по всем проектам, очень помогает.

Так в принципе, ничего нового не выдумано, насколько я понимаю. Всё тоже как и 30 лет назад.

1) если идёт сплошной поток, то префикс команды (Байтстафинг). Как вы уже отметили в модемах используется. Префикс AT (за малым исключением). То есть "hgjghjhati3" будет квалифицировано как команда "i3" - идентификация устройства. Префикс может быть любым, в том числе и односимвольным. Я обычно использую "Ъ". Естественно префикс из простого потока данных изымается (заменяется на комбинацию), либо удваивается. Один из вариантов WAKE.

2) Применяется пауза (в том числе определённой длительности) перед началом команды.

3) Применяется комбинация 1 и 2.

Есть ещё битстафинг (я применял), но он неподходит для UARTа.

В дополнение ко всему хотел бы заметить, что конфигурирование устройства и его отладка это немного разные вещи. Конфигуратор на основе текстового меню легко делается. И совершенно без разницы куда выводится это меню: на экран устройства или в UART и соответственно откуда управляется: с клавы устройства или опять же из UART.