А может ли быть такое?..., Порядок получения ответов на AT-комманды Опции

[david_off]

Не знает ли кто-то из местных жителей, может ли влезть какое-то сообщение между эхом и ответом на команду.

например,
1) шлю команду AT CR
2) приходит эхо <AT> CR.
3) теперь я жду подтверждения OK, а в этот момент звонит кто-то и я получаю crlf <RING> crlf crlf <OK> crlf.

От этого зависит, как обрабатывать комманды контроллером. Не очень хочется после получения эха быть готовым к сообщениям любого содержания (RING, потерял сеть и т.д.)
PS: использую модуль SIMCOM300C.

[Guest_@Ark_*]

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

[david_off]

А можно как-то отключить поступление сообщения RING? У меня контролируется нога RING, мне не нужно отлавливать это сообщение.

[aaarrr]

А можно как-то отключить поступление сообщения RING? У меня контролируется нога RING, мне не нужно отлавливать это сообщение.

Вообще-то программу надо строить так, чтобы быть готовым обработать любой ответ модема в любое время. Помимо RING'а это могут быть сообщения о регистрации, приходе СМС и т.п. Отключать их все - не выход.

[david_off]

В общем случае это правильно, но у меня частный случай.
Мои устройства ждут несколько секунд, пока не зарегистрируются в сети (находятся в местах гарантированного приёма сигнала). Затем поднимают GPRS сессию, получают реальные IP адреса и настраивают себя как сервер (TCP/IP стек).

Далее на них возлагается всего две функции:
1) сначала передать опрашиваюшему блоку свой IP через CSD;
2) при поступлении запроса от опрашивающего блока настроится на прозрачный режим передачи данных и обменятся информацией.

Т.е. как вы видите, на блоки практически никто не будет звонить (кроме опращивающего блока). SMS мне не нужны - могу их игнорировать. Зачем тогда программу перегружать обработчиками сообщений RING, пришло SMS и т.д.:?

Я тут думал, можно и на все возможные сообщения сделать обработку, но вот загвоздка остаётся при неконтроллируемом получении команды RING. @ARk писал, что он может влазить даже внутри эха.
Получается, что при его влазиния могут быть такие последовательности:
Для эха: <Начало эха> CRLF RING CRLF <конец эха> CR
Для ответа: CRLF<Начало ответа> CRLF RING CRLF <конец ответа> CRLF

Я обрабатывают эхо и ответы по счётчику символов CR и LF. А при таком поведении RING-a эта схема не подходит. Приходится делать какой-то сверх умный буфер, который бы мог долго накапливать даные, потом их сканировать на наличие "наглых вставок", потом вынимать их из буфера, затем только обрабатывать содержание. Это явно снизит быстродействие из-за дополнительных ожиданий "А может дальше прийдёт что-то, что потом ошибочные данные дополнит и сделает их правильными".

Мне кажется для контроллера это будет передоз!

[PIC_Embedder]

Мне кажется, что ты несколько драматизируешь ситуацию. У меня похожий алгоритм обработки. При ответе ожидаю LF. Если это будет LF от RING, а не от OK, то ничего страшного не произойдёт. Максимум пришедший позже ОК, будет воспринят как входящее сообщение. Поскольку его нет в списке на обработку, программа его просто проигнорирует.

[david_off]

Мне кажется, что ты несколько драматизируешь ситуацию. У меня похожий алгоритм обработки. При ответе ожидаю LF. Если это будет LF от RING, а не от OK, то ничего страшного не произойдёт. Максимум пришедший позже ОК, будет воспринят как входящее сообщение. Поскольку его нет в списке на обработку, программа его просто проигнорирует.

В том то вся соль, что распознать вместо OK, приход двух сообщений RING, а потом ОК не получится.
Допустим что RING влез, тогда данные поступившие с порта будут:

CRLF O CRLF RING CRLF K CRLF

CRLF O CRLF RING CRLF K CRLF
Тогда контроллер, по алгоритму который я описал, получит сообщение O, после него мусор RING, он как бы не взят с двух сторон CRLF, а затем ещё какое-то K.

Так как же по твоему распознать два сообщения OK и RING, не делая тот мудрый буфер с накоплением и дополнительным анализом?

[PIC_Embedder]

В том то вся соль, что распознать вместо OK, приход двух сообщений RING, а потом ОК не получится.
Допустим что RING влез, тогда данные поступившие с порта будут:

CRLF O CRLF RING CRLF K CRLF

Нужен тебе этот "ОК"? В моей программе, нет проверки ответа. Только ожидание "LF".

Так как же по твоему распознать два сообщения OK и RING, не делая тот мудрый буфер с накоплением и дополнительным анализом?

Чем мудренее алгоритм, тем вероятнее, что будет глючить. Проверено личной практикой.

[Guest_@Ark_*]

Я тут думал, можно и на все возможные сообщения сделать обработку, но вот загвоздка остаётся при неконтроллируемом получении команды RING. @ARk писал, что он может влазить даже внутри эха.
Получается, что при его влазиния могут быть такие последовательности:
Для эха: <Начало эха> CRLF RING CRLF <конец эха> CR
Для ответа: CRLF<Начало ответа> CRLF RING CRLF <конец ответа> CRLF

К сожалению, невнимательно прочитали мое сообщение.
Ответ RING может быть получен на фоне ввода или выполнения любой другой команды. Но не на фоне вывода другого ответа! То есть: RING может "вклиниться" в эхо. Даже несколько раз. Например, если медленно набираете команду вручную. Может прийти несколько ответов RING, до того как получите ответ на вашу команду (ОК или что-то еще). Но "вклиниться" внутрь другого - ответ RING не может! Он будет или до ответа или после, но никак не в середине.

[david_off]

Спасибо, теперь действительно всё встаёт на свои места.
При таких условиях можно сделать нормальную обработку.