+1

Кроме того, я бы не вставлял в рабочую прогу отладочные режимы. Отладка предполагает свободный доступ к железу. Для рабочего режима это, на мой взгляд, недопустимо. Фактически - это даст возможность пользователю убить работоспособность изделия.

Делали один проект, и программист, который писал головную прогу (на IBM) требовал, чтобы я предоставил прямой доступ к памяти устройства (под MODBUS). Я наотрез отказался. Их мотивация - что будет всё отлажено и PC прога не будет вредить устр-ву. За то это даст более широкие возможности, в том числе и по отладке. Моя мотивация - кто будет нести ответственность за работоспособность моего железа?

Ну почему, можно запаролить критические команды. А пароль никому не давать.

Обычно использую бинарный протокол для отладки, но если надо текстовую консоль, скопировал бы схему работы с юниксовых шелл+терминал, что то лучше придумать сложно.



Конечно тут мало проверок, и можно удалять только последний символ, это упрощенный пример.

1. Байт парсер, выделяющий строки команд и управляющие символы из потока. Вызывается или непосредственно из RX INT или из обработчика "OnRead" TCP сокета.
2. Задача поиска обработчика для выделенной из потока строки. (по табличке, в точности так как привел AHTOXA).
3. Обработчик каждой команды.
4. Общий парсер параметров, который пытается интерпретировать строку параметров всеми известными ему форматами: как целое число, как float-point число, как IP addres, mac-address, дата, время, строка и т.д и т.п..
5. Ну и контекстный Help. (вызываемый в обработчике каждой команды, если команда вызвана с параметром "?" или "--help").

А не трудно показать начало ветвления (switch). Что за тип Вы ему даете? У меня как-то не срабатывает подобное, хотя пытался такое изобразить не раз. Компилятор варнингует, что нельзя сравнивать мультичарестерный чар (multi-character character constant).

И везде встречал побайтный анализ, что приводит к огромным ветвлениям switch/case.

Естественно, что это исходник, как уже писал, для 32bit. Для 16bit, соответственно только пара символов, ну а с 8bit
Если какой-то компилятор warning, выдает, что бывает - надо отключить для этого куска через #pragma
Предупреждать он, конечно, может, но работать, как приказано, обязан.

А расскажите пожалуйста теорию про FIFO (я на асме пишу под Мегу8). Не понимаю самого принципа.
Форма команд моему девайсу: <префикс начала><команда> [<параметры>]<CRLF>
Выделил какой-то буфер, думаю тупо заполнять его поступающими данными из UART, инкрементируя указатель... и не могу сообразить, с какого момента начать его обрабатывать?
Вижу варианты:
1. Буфер переполнен - выдаём ошибку
2. Нашли CRLF - парсим буфер, обрабатываем команду
3. Какой-то тайм-аут передачи - буфер отбасывается, ошибка
4. Неверная команда - выдаём ошибку.
Обрабатывать думаю - искать старт команды в буфере (три байта), и написать что-то типа strcmp.

Мыслю верно? Смущает, как определить то, что передача данных закончилась...

Если кому интересно, нашёл "для тупых" тут статейку. Идеи разжёваны идаже примеры есть http://www.atmel.ru/Articles/Atmel12.htm

<префикс начала><команда> [<параметры>]<CRLF>
<CRLF> - как раз передача данных закончилась. Про таймаут Вы уже говорили...

<префикс начала> - если будете обрабатывать в прерывании, FIFO Вам не нужен будет совсем.

2_Pasha Кхм, я путаюсь уровнем ниже. Как принимаемое пихать в буфер и что делать, если будут слать следующую команду,пока обрабатывается текущая. Думаю отключать UART на приём(?).
То-есть есть отдельно принималка строки и есть отдельно парсер. Вот с принималкой строки затыки следующие:
0. Есть область памяти и счётчик адреса = буфер. Так?
1.1. По прерыванию пихаем байт, инкрементируем счётчик, проверяем переполнение счётчика, выдаём ошибки, если надо (переполнен буфер).
1.2. После принятия очередного байта проверяем два последних на CRLF. Если равны = отключаем приём, передаём буфер парсеру.
2. Парсер уже сам разбирается - команда/ошибка, выдаёт ответ или выполняет её, в конце разрешая приём.

Есть ли тут какие-то подводные камни? Первый вижу сам - пока обрабатываем что-то, теряем посылаемое в этот момент. Это я закладываю в протокол: если не пришёл ответ от команды, повторить посылку.

И ещё непонятно с таймаутом - как его посчитать? Выходит что-то типа ватчдога? Или вообще не делать, а просто ждать CRLF?

Видел модуль, там типа терминала через RS-232 написано, так, вроде там таймаута нет никакого. Просто строка кончается CRLF.

Тогда FIFO (пардон за Си):



Для начала определитесь, для чего именно Вам таймаут. Он может быть как на время между принятыми командами, так и на время между символами.
ЗЫ для определения переполнения буфера можно параллельно ввести счетчик принятых байт. При чтении - декрементировать его.

На время между символами. Наверное, может и не нужен. Заложу - если команда не выполнилась - послать CRLF (очистка буфера) и повторить команду.
А sym_pending у Вас как вызывается? Где-то в цикле или по таймеру?

Во-первых, кто это будет так плохо себя вести? Во-вторых, если такое всё же возможно, можно сделать два буфера на приём (и соответственно два счётчика), один принимается (в прерывании), другой обрабатывается (парсером). И флажок, номер_готового_буфера (0/1).

На да. При каждом принятом символе некий счётчик устанавливается в заданное значение, а в прерывании таймера - декрементируется. Как стал нулём, так тогось, тайм-аут. Только вот что делать по тайм-ауту?

Да, так гораздо проще. Единственно, когда тайм-аут нужен, это в том случае, если при входе в консоль устройство перестаёт работать в штатном режиме. Тогда его минут через пять после ухода забывчивого наладчика таки желательно вернуть в рабочее состояние
И это правильно. Вдруг человек просто задумался?

Конечно, где-то в основном процессе. Вначале узнаем, сколько символов принято, а потом можем еще и покапризничать - надо обрабатывать или нет. Может, есть другие более важные задачи.
Затем - читаем посимвольно. Разворачиваем это все в другой буфер (к сожалению). и парсим от замеченного начала и до замеченного ВКПС.
ЗЫ FIFO_flush делается как присвоение pos_wr = pos_rd. позаботившись об атомарности . Если надо, конечно.

Аааа! А я-то хотел обрабатывать в том же, куда принял. Тогда можно рыбу накатать и проверить.

По таймауту - чистить буфер. Не успели передать строку целиком - значит пришёл мусор. Оставлю как опцию.

Насчёт плохо себя ведущих - вообще, потом думаю о каком-то протоколе, где несколько мастеров и несколько подчинённых. Хотел, чтобы они слали друг другу инфу в формате АдресПолучателя АдресОтправителя Инфа. Выходит, что сама магистраль может быть забита чем угодно, и в этом случае просто будет несколько попыток достучаться до девайса (передаёт и принимает всегда одна пара).
Но это пока задумки и вопросы для другой темы. Мне б пока с компютера научиться управлять и команды парсить...

FIFO ведь не самоцель, а средство разгрузки основного процесса от тяжелых прерываний. Оно может быть каких-нить компромиссных размеров, скажем, 8 байт. Учитывая двойную буферизацию UDR, может хватить.
Да и приемный буфер может быть динамическим.
А если "рыбу накатать" - у Вас будет эдакий бегемот в ОЗУ сидеть статически, чтоб не прозевать команду, да еще и там же ее парсить... не думаю, что сие полезно.
ЗЫ: это ж ответ от девайса пойдет только после приема команды? Тогда у Вас большой буфер для работы на RX/TX и ФИФО на прием.