Как обрабатывать сообщение REMOTE IP: Опции

[david_off]

В моей программе все сообщения обрабатываются по установке флага получения нового сообщения. Анализатор флага работает так: получив CRLF (начало) - начинает ожидать CRLF(конец). Как только получен конец - флаг устанавливается. Обработчик сообщений, получив флаг, смотрит в буфер и обрабатывает пришедшее сообщение. После обработки флаг сбрасывается.

Алгоритм работает шикарно. Единственный его нюанс - нельзя работать с командами типа CLCC, которые возращают несколько строк и строки начиная со втрой не имеют CRLF (начало). Данные ответы имеют вид: CRLF<line1>CRLF<line2>CRLF...<lineN>CRLF OK CRLF. Проблема решается путём отказа от таких комманд - они мне не нужны.

Так вот с сообщением <CRLF REMOTE IP:> тоже наблюдается лажа.
Есть вариант выхода из сложившейся ситуации следующий: после соединения модулей посылать текст, который всегда будет заканчиватся на CRLF. Тогда сообщение будет иметь вид
<CRLF REMOTE IP: текст CRLF> - такое корректно обработается.

Но вот найти решение корректной обработки, когда приходит RING или ещё какое-то неожиданное сообщение - не могу. По сему спрашиваю здесь. Как обрабатывать REMOTE IP на тот случай, если влазит кто-то?

Сообщение отредактировал david_off - Nov 7 2008, 11:20

[Baser]

В моей программе все сообщения обрабатываются по установке флага получения нового сообщения. Анализатор флага работает так: получив CRLF (начало) - начинает ожидать CRLF(конец). Как только получен конец - флаг устанавливается. Обработчик сообщений, получив флаг, смотрит в буфер и обрабатывает пришедшее сообщение. После обработки флаг сбрасывается.

А я так и не пойму, как при таком алгоритме можно принимать не только сообщения модема, но еще и данные, которые сыпятся по GPRS-у (или по CSD). Я уже писал об этом тут рядом.

У меня основа алгоритма - кольцевой приемный буфер достаточного размера, чтобы разместить мах возможный пакет данных + несколько ответов модема, включая незапрашиваемые (unsolicited).
Признак получения данных - таймаут (дырка в данных) в ~50ms
После чего начинает работать обработчик по разбору всего, что пришло (причем в это время могут начинать валится новые данные, они попадут дальше в кольцевой буфер и будут обработаны позднее)

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

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

Еще добавлю, что работать с модемом без операционки я не рискую, уж больно большой гемор
Правда, я сам полноценную ОС не использую, а применяю ее зачаток, где кроме главного цикла и прерываний есть еще один поток, в котором выполняются модемные процедуры и можно применять "ожидания событий", во время которых крутится главный цикл (ну и прерывания ессно)

[david_off]

А я так и не пойму, как при таком алгоритме можно принимать не только сообщения модема, но еще и данные, которые сыпятся по GPRS-у (или по CSD). Я уже писал об этом тут рядом.

Не знаю что у вас за железо, но я это реализую на mega128+SIM300C. Чего то для этой парочки не слышал про какую-то ось. Что касается алгоритма обработки, то мой алгоритм отлично работал, до появления сообщения REMOTE IP и данных GPRS. Ведь именно по этому я и создал эту тему.
Тут мне подсказали сделать таймауты. После их добавления наши с вами алгоритмы стали практически близнецами. Сами судите.
У меня тот же кольцевой буфер. Размер его выбран по такому же принципу. Байты ловятся в прерывании по приёму USART. Там же стоит логика, которая отслеживает появления LF по принципу StateMachine. Появилось LF дважды (пока таймер ещё не сработал) - значит в буфере уже лежит что-то осмысленное и можно это обработать. Для всех используемых мною команд можно это использовать. При появлении команд, которые в конце не имеют LF - обработку инициирует срабатывание таймера. После начала обработки, StateMachine возращается в начальное состояние, что бы начинать отлов новых ответов с "нового листа".

Сам же принцип обработки тоже очень похож.
Идём по буферу, сравниваем его содержимое с готовыми шаблонами ответа. Определённые ответы выставляют особые флаги. Например нашли OK - ставим OKfound = true. Если в буфере встречается ERROR или ему подобные, то ставиться ERRORfound=true. Если не нашли нужного шаблона - значит это просто ответ - для него есть флаг ANSWERfound.
Когда есть три таких флага, то после посылки любой комады нужно дождаться либо экстернного вываливания (ERRORfound) либо нужного сочетания ANSWERfound и OKfound.
После того как в буфере обработана инфа, он так же чистится, как и у вас. Перед посылкой новой команды, все флаги сбрасываются.

Может это и покажется диким, но у меня как ни странно всё класно работает. Проверял, тестил сутки - сбоев не было. Отработаны команды поднятия GPRS сервиса, инициализации и приёма звонков, посылки и приёма TCP сообщений.
Алгоритм обработки не падает при вклинивании UNSOLICITED сообщений типа RING или +CMTI. При появлении их появлении, они обрабатываеются, затем в буфере происходит откат указателей и программа продолжает корректное ожидание или обработку прерванной комады - все ок.

А Вы не пробовали действовать методом исключения? Получив первый символ, после LF, Вы сразу "отсекаете" из набора возможных сообщений все, начинающиеся с другого символа. Очень часто, после приема первых двух-трех-четырех символов, остается только один возможный вариант ответа. С этого момента, уже можно считать сообщение принятым - выставить флаг, определить код сообщения и переключиться на ожидание следующего LF. C какой задержкой придет оставшаяся часть ответа и завершающий LF (или LF нового сообщения) - уже не будет иметь значения. Прием сообщения еще не окончен, но его обработка уже завершена...
P.S. Конечно, этот алгоритм не отменяет необходимость обработки таймаутов.

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

В итоге скорость не на много повышается, а писать не удобно. Единственное, что я сделал для ускорения, это считаю длину полученной посылки во время приёма. Процесс сравнивания сначала пытается найти похожий шаблона ответа в ответах фиксированной длины (OK, ERROR, CONNECT ...), если же после попадания в раздел нужной длины соответвий не найдено, то идем в раздел ответов неопределённой длины (+IPD, REMOTE IP: ...). Если и там ответ не найден, то получен не шаблонный ответ, который будет обработан по индивидуальному алгоритму для каждой нестандартной комады.

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

Сообщение отредактировал david_off - Nov 8 2008, 13:03

[Baser]

Не знаю что у вас за железо, но я это реализую на mega128+SIM300C. Чего то для этой парочки не слышал про какую-то ось.

Ну, если люди умудряются в PIC-и с 8-ю килограммами памяти запихивать маленькие ОСьки, то в mega128 можно применить любую из доступных для МК Здесь в конфе много инфы по этому вопросу.
Но да ладно, это уже отход от существа вопроса. Просто, именно столкнувшись когда-то с задачей управлением модемом, я понял все прелести наличия ОСи, когда передача данных через модем - это только одна из N-цати задач, которые нужно решать одновременно.

[david_off]

Ну, если люди умудряются в PIC-и с 8-ю килограммами памяти запихивать маленькие ОСьки, то в mega128 можно применить любую из доступных для МК Здесь в конфе много инфы по этому вопросу.
Но да ладно, это уже отход от существа вопроса. Просто, именно столкнувшись когда-то с задачей управлением модемом, я понял все прелести наличия ОСи, когда передача данных через модем - это только одна из N-цати задач, которые нужно решать одновременно.

Не знал что под мой зверёк тоже есть оси. Я думал оси пишут только для DSP и выше.
Поищу. Может быть жить станет красивей.
Кстати будет ещё интересно пару слов о ваших предпочтениях в этом вопросе. Наверняка будет много разных вариантов, львиную долю которых вы уже забраковали и лишите меня приятного права наткнулся на уже пройденные грабли.
PS: cпасибо за просвящение.