Всем привет!

Может ли в процессе выполнения AT-команды, т. е., между запросами AT+XXX и ответами типа OK, ERROR, ... от модуля/модема придти какой-нибудь URC?
Ну, кроме +CME/CMS и ответов с данными...
Задекларировано ли это где-нибудь?

Может. Задекларировано в самой логике работы сотовой связи.
Любое событие - асинхронно.

А если поставить вопрос по другому: может ли во время отправки AT команды прийти URC? По логике взаимодействия с модулем разницы между двумя вопросами нет, но зато на этот вопрос, по-моему, отввет очевиден.

Вы не поверите, но URC может прийти даже во время приёма ответа, внутри него. Или между ним и "\r\n"; или между '\r' и '\n'.
Т.е. например: ERR<URC...>OR
Даже такое бывает.

Ну, это уже совсем жесть. Которая никак не соотносится со стандартом GSM 07.07

Абсолютно соотносится, так как нет никакого ограничения в стандарте на это.

Может прийти в любом месте. Скажу даже больше, в ранних прошивках SIM300C был косяк - URC приходили прямо внутри других строк Такого больше никогда не попадалось, так что по факту надо рассчитывать на приход целых строк но в любом порядке

Это конечно косяк, но это печальная реальность - сталкивался с таким в Bluegiga WT-12.
К сожалению - таков уровень их программистов написавших её прошивку.

Насчет такого скажу, что это грубая ошибка ПО и при работе с SIM300/SIM900 такого никогда не видел.


А вот у Bluegiga, подтверждаю, видел. Работал с WT11i и с BLE112 - и там и там случается.
Вроде солидная фирма, их даже Silicon Labs купила, а такие баги.


Я в своем софте применяю след. гипотезу
Ответы на команду есть двух видов: от стека модема и от мобильной сети.
Вот я считаю, что между командой и ответом стека ничего влезть не может (не должно ).
А вот при ожидании ответа от ГСМ сети может что-нибудь и влезть, хотя тоже очень редко, обычно это ошибки и отлупы от ГСМ сети.
Типа PDP DEACT может придти когда угодно.

А чтобы не разгребать все возможные ответы модема (там бесконечное число вариантов ) просто периодически проверяется состояние конекта, и если что не так, запускаются процедуры восстановления.

О да! В стандартах не прописывают, что п/о должно быть без глюков и багов


Ну и зря. Выполнение команды модемом можно разделить на этапы:
1. Прием команды по физическому интерфейсу.
2. Разбор принятого модемом
3. Выполнение команды.
4. Формирование ответа.
5. Отправка ответа по физическому интерфейсу.

Так вот, даже если допустить, что от момента выполнения команды до отправки ответа ничего влезть не сможет, то как определить фазу выполнения команды?
Пока мы что-то отправляем на модем, нам УЖЕ может валится URC типа "у меня смс новое". Естественно, после отправки команды мы ждем "OK", а получаем "+CNMI" и злимся на модем, что "незванный гость хуже татарина.."

Имхо - неправильный алгоритм. Я классифицирую по-другому.
Сообщения от модуля к клиенту (не важно GSM или какой другой общающийся через UART посредством команд от клиента) можно разделить на:
а) синхронные - реакция модуля на переданные ему команды клиентом (т.е. - это ответы на команды, в том числе и многострочные);
б) асинхронные - уведомления о некоторых событиях внутри модуля, напрямую несвязанных с переданными ему командами, происходящими асинхронно относительно основного командного обмена.
Любая передача как от клиента к модулю, так и наоборот, делится на кадры (строки). Кадр - это последовательность допустимых символов, ограниченная символами "\r\n" (или одним из них).
После передачи модулю команды клиентом, клиент переходит в состояние ожидания синхронных ответов на команды (могут быть многострочные) и ждёт ответов разбирая входящий поток кадров.
Ожидание заканчивается по получению ответа (или цепочки ответов если команда может генерить цепочку ответных кадров), либо по истечении таймаута ожидания.
Таким образом - URC может вклиниваться в любой момент между командой и первым кадром ответа или между двумя кадрами ответа. лавное - чтобы он не нарушал целостность кадров (строк).
Сам URC тоже должен иметь такой-же формат кадра (строка).
Когда URC влезает внутрь другой строки, нарушая её - это конечно баг, тут уже ничего нельзя сделать.

+1

Добавлю только что "правильные команды" заканчивают свой вывод "OK", а промежуточные ответы формируют с "+" вначале. Таких большинство.
А вот отличить симкомовкий Call Ready от промужуточного ответа (к примеру, на +GMI (SIMCOM_Ltd) проблематично.
Как бы уважаемый Cadilo не защищал производителй модемов, палки в колеса они вставляют..

>>А вот отличить симкомовкий Call Ready от промужуточного ответа (к примеру, на +GMI (SIMCOM_Ltd) проблематично.

И в чем проблема? Сложно найти "CALL READY\r\n" ?

Ну да, я имел в виду одно, а получилось другое, написал не подумавши

На самом деле, то что я применяю на практике, примерно соответствует описанному вами:
кольцевой приемный буфер для ответов модема, который анализируется по тайм-ауту после прихода последнего байта и периодически во время ожидания ответа. Сканируется на соответствие шаблонам ответов по принципу функции strstr();
так что положение ответа значения не имеет. После обнаружения ответа, ответ удаляется из буфера (только он).
Всякие неожиданные URC периодически сканируются в бэкграунде.
Чтобы уменьшить вероятность переполнения приемного буфера, периодически происходит полная его очистка (с защитными механизмами типа слежения за принимаемыми байтами на уровне прерываний и поднятия RTS).

А вот разбиение на строки по \r\n не использую. Применяю обмен бинарныим данными, кроме того есть присловутые приглашения модема при отправке данных и СМС из одинокой треугольной скобки (>)

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

Смотря как подходить к вопросу.
Чтобы 100% отделить мух от котлет, нужен полный перечень либо мух, либо котлет.
Чем больше перечень, тем больше памяти нужно. Чем более перечень завязан на конкретный тип модема, тем он менее универсальный.
И то и другое маложелательно.

В вопросу.
Что "CALL READY\r\n", что "SIMCOM_Ltd\r\n" являются чисто строками, без цифр, причем длиной 10 символов. По косвенным признакам одинаковы.
Если искать "CALL READY\r\n", то "Call Ready\r\n" можно никогда и не найти, в зависимости от реализации поиска.

Мало того, в 800й серии добавилось еще и "SMS Ready". Видимо, чтобы еще упростить жизнь ардуинщикам. И сделать их железо еще глючней, так как при таком подходе вряд ли кто будет заморачиваться, к примеру PDU режимом для SMS (при наличии в теле сообщения зарезирвированных сочетаний /CONNECT/OK/RDY/.../).