Задался вопросом, а существует ли классический алгоритм обработки ответов модуля на стороне микроконтроллера?
Лично я пробую обрабатывать на лету:
Временный буфер (50 байт, например), он до начала приема заполнен значениями 0А, это для обработки двух-символьных ответов 30 0D и 34 0D.
Указатель - переменная на последний принятый байт в буфере, по умолчанию = 1.
В основном цикле отправляю команду в модуль и в цикле жду изменения переменной результата.
По прерыванию на UART:
- пополняю временный буфер принятым байтом (пополнение начинается не с нулевого байта, а с первого, опять же, для обработки двух-символьных ответов);
- если указатель >= 2, проверяю три последних символа буфера на соответствие маске (0A 30 0D, 0A 34 0D etc.);
- если соответствие есть - записываю в переменную результата (соответственно 30, 31, 34 etc.);
- инкрементирую указатель на последний принятый байт и опять жду прерывания.

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

Я сделал структуру для ответа с собственно массивом строки (довольно большим - 500 байт) и длиной.И таких структур штук 5-6. Отсекая строки по 0D 0A отправляю в Очередь сообщений FreeRTOS указатель на заполненную структуру и в самой структуре еще ставлю флаг что она не обработана. Это все в прерываний.
В основном потоке - собственно ожидание указателя на Очередь со свежими данными и после обработки ставлю флаг освобождения в структуре.
Что это дает: удобство в том, что строки обрабатываются в том же порядке в каком они приходят, фрагментация не имеет значение. Минус - откусывается кусок RAM в несколько кБ, но у меня 96к, могу позволить себе такую роскошь:-)

Так не все же ответы заканчиваются 0D 0A, некоторые только 0D.

У каждой структуры свой обработчик? Т.е. например ожидание соединения обрабатывается индивидуально?

А бинарный поток, я так понимаю, отдельно обрабатывается?

Ну да, если приложение не ресурсоемкое, то использование камня среднего или старшего семейства будет иметь сомнительное оправдание

Еще минус вижу в сложности написания стандартной библиотеки.
В общем, идея понятна, спасибо за ваш ответ. А то я сомневался, что на лету это рационально, т.к. теоретичсески можно нарваться на переполнение стека или опоздать на прием следующего байта...

Классики нет, особенно если требуется принимать данные в режиме CSD или работать с Simcom TCP стеком. Лично у меня все принятые данные проверяются на наличие CR, LF и если есть перенос строки, то обрабатывается строка от начала буфера до переноса. Обработка вынесена из прерывания с помощью двойной буферизации (пока обрабатываем первый буфер, второй заполняется в прерывании). Алгоритм требует модификации для команды CMGR, CMGL, приёма данных по символу > и для проприетарных симковоских команд.
Ну и при обнаружении нужного ответа формируется флаг для основной задачи. Не очень удобно, но переделывать уже не стал.

Применяю всегда RTOS для этих целей.

В прерываниях просто записываются символы в кольцевой буфер и отправка события в задачу модема о приеме символа.

Задача модема извлекает символы из кольцевого буфера в свой линейный буфер и ищет в нем заданный при вызове функции чтения терминатор строки.
Терминатором может быть и 0D 0A или '>' или что угодно, зависит от того что в данный момент приложение ожидает от модема.
Ожидание получения строки длится определенное заданное время.
Если в течении этого времени терминатор не обнаружен, то принятый буфер данных дополнительно сканируется
на асинхронные сообщения по их строчным шаблонам и если и их не обнаружено, то буфер обнуляется.
Асинхронные сообщения могут иметь иметь каждое свою задачу назначения. Задачи приемники заранее регистрируют свои обработчики в задаче модема.

Не выгодно каждый символ передавать - я делаю по концу строки или по установленным маскам. Бинарные данные просто записываются и по счетчику передается событие и готовности.

0D 0A всегда, если отправляешь например AT\r то эхо все равно будет AT\r\n
тут еще AlexandrY правильно подметил, что по ">" тоже нудно отсекать - все верно, для SMS по нему отсекаю так же. В другое время этот символ никогда не появляется.

Я описал как бы сам механизм отлова строк, а сама функция подачи АT команд выглядит примерно так: как у printf неограниченно количество аргументов в виде строк с возможными ответами и выход из функции либо по таймауту либо по успешному нахождению одной из строк в аргументах

Да, отдельно, после команды ATD*99# используется просто буфер в виде той же очереди FreeRTOS, а уж TCP стек забирает оттуда данные - тут совсем все просто.

Соглашусь.

Код достаточно переносимый.
Я еще не стал уподробняться, что у меня не просто прерывание по RX, а используется DMA, так как STM32 и поверх еще прослойка в виде CMUX, но сути это не меняет. Кстати CMUX очень рекомендую: я допиливаю трекер, так что очень приятно иметь виртуальные порты: один для GPRS, другой для SMS и звонков, третий для качества сигнала и определения видимых сот.
Еще в эту систему для полного счастья следует добавить поддержку спящего режима модема (с линией DTR как правило). Кстати, модемы SierraWireless мне в этом плате понравились - дополнительных сигналов не требуется. В общем вроде простая задача, а можно зайти очень далеко :-)

Немного не понял ваш механизм, разъясните куда данные записываются, что за счетчик и каким образом передается событие.

В моем варианте из процедуры прерывания в задачу RTOS передаются не символы, а асинхронные сообщения о приеме символов.
Поскольку процедура прерывания не может посылать никакие данные, так как не знает своих задач-приемников.
Задача-приемник же может забрать и посимвольно и большим блоком в зависимости от того как она успевает.

Формировать же строки имеющие разные терминаторы в процедуре прерывания означает слишком усложнить процедуру прерывания и перенести в нее часть логики прикладного приложения.
А если учесть еще, что приходится работать и с протоколом PPP и с мультиплексированием, то вообще неприемлемо втягивать в это процедуру прерывания.



DMA? Очень интересно.
А как вы задаете для DMA размер пересылаемого блока? На основе чего его определяете?
И почему DMA только по RX?

Прерывание IDLE line USARTа приходит на помощь. В нем хвост забирается и ресетится DMA. Буфер DMA при этом может быть довольно большим - 128 или 256 например, при этом практически все АТ строки забираются из этого прерывания.
TX тоже по DMA, кстати тоже неприятный момент, что DMA работает с блоками выровненными на 4, это не позволяет решать задачу в лоб.

С кольцевым буфером это интересно, нужно попробовать, меньше "телодвижений" должно получиться...

Тогда не выполнится условие RTOS.

Очень круто, но я так понимаю это исключительно Telit`овская фича?

SIMы так же работают.

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


Нет, стандартная (3GPP TS 07.10), но не обязательная. Кроме Telit'ов встречал в Quectel'aх

Тю, оказывается в SIM`ах это тоже есть (AT+CMUX Multiplexer Control), когда доку штудировал наверное не обратил внимания.
Надергал апнотов, буду впитывать...

И после всего этого еще ругают OCPU, EAT etc. На сколько же все становится проще...

А что это за звери такие "OCPU" и "EAT"? Где почитать?

Ну да, ну да. Особенно если учесть, что часть функционала и там приходится извлекать AT-командами...

Недавно соорудил управление Quectel M10 аналогии с проектом для MSP430 с сайта AlexandrY (тест GSM-модема) - вроде бы, когда отправляю комманды модему во время звонков или инициализации - все работает нормально. Но не знаю, как сделать отлов сообщений от модема типа RING или сигнала о пришедшей SMS. Подскажите пожалуйста - работаю с Keil RTX на LPC2378.

А может и не нужно делать отлов этих сообщений?
Статус входящего соединения можно запросить командой (для sim900 команда +CPAS).
СМСки можно запросить командой AT+CMGL.

Думаю "отлов" это единственно правильный метод. Если "отлов" не ловит 100% сообщений от модема, то и нет гарантии, что ответ на запрос будет правильно обработан и получен вообще. Если бы модем только отвечал на запросы, и никогда сам ничего не генерил, то отлов не нужен был бы. А если есть хоть малая вероятность того, что модем сам что-то выдаст, то нужно быть готовым в любой момент, обработать любую строку от модема.

У меня так:
const char READ_SMS_descriptor[] = "+CMGR:";


потом в где-то в основмном цикле
if(CPUSearchInArray(READ_SMS_descriptor, GL_BUFFERS.GSM))
{
GL_INTERRUPTS.SMS_IS_COMING = SMSPreprocessSMSMessage();
}

делаю всё как AlexandrY но с некоторыми отличиями:
Все строковые AT-ответы свожу к битам, и тогда при отправке ждем тупо маски at_send( "AT+BLA\r", mdm_tx_ok + mdm_tx_dialing, MY_TIMEOUT, RETRIES_QNTY )
Сама работа делается через сообщения: типо отправь смс #1, #2 и позвони. Эти сообщения помещаются в очередь, и выполняются по очереди. Если в момент выполнения приходит ассинронное сообщение, то оно размещается в очереди (к примеру что пришлс смс с порядковым номером 3). И после выполнения текущей пользовательской операции, обрабатывается если есть ассинхронные сообщения, с оповещением юзеру.

Вы уверены, что в документации на модем описаны все 100% сообщений, которые может выдать модем?

Думаю что речь не идет о 100% парсинге, а только о 100% приеме

to megajohn
А как у вас построенна эта обработка асинхронных сообщений?
Просто у самого была отдельная задача, которая постоянно опрашивала кольцевой буфер приема на наличие заветных сообщений о звонке или смске. Но при этом возникают проблемы, когда нужно модему самому или позвонить, или отправить смс. Как сделать так, чтоб в этот момент или задача, следящая за RING или смс вообще не лезла в буфер, или же ждала, пока не будет нормально сделан звонок или отправлена смска?

А зачем RX и TX пихать в один буфер?

По логике модем не должен пихать unsolicited в промежуток между отправкой эха команды и результатом выполнения команды.

Ловить надо только то, что нас интересует.

В том то и дело, что модем никому ничего не должен.
Он черный ящик, может отработать, может нет, может отвалится в любой момент может нет.

Задача должна занимать порт модема, на определенное время.
Если это отсылка смса, то после отсылки, никто в порт ничего не должен слать, пока не пришло подтверждение отправки, после этого порт отпускается.
А другая задача, контролирует это время, она определила, что порт сильно долго занят, она принудительно отпускает его + пишет сообщение в лог, для последующего разбора полетов.

Если пришел юрц, то просто обрабатываем его, и если он нас интересует, записываем в буфер, какое действие надо сделать.
И сделаем его, как только порт освободится.

По такому принципу сделан прием смс.
В любой момен приходит юрц, с позицией смса в буфере симки.
Эта прозиция сохраняется.
И когда порт будет свободен, смс вычитывается из той позиции.

Получается конечный автомат занятия юарта процессами.

Перед занятием юарта, любая задача должна убедиться, что порт свободен, если не свободен, задача должна проверить юарт через некоторое время и так пока порт не освободится или задача потеряет актуальность.

Какая из мыслей окончательная у Вас?


Поведение модема должно соответствовать даташиту.
Хотя попадался мне модем который даже после команды ATV0 на некоторые команды внутреннего TCP/IP стека отвечал <CR><LF>OK<CR><LF>.


А я вот не могу себе позволить такую роскошь - несколько процессов для работы с одним только модемом

Буферы действительно разные, но охота, чтоб задача, которая ожидает RING, не мешала получить ответы на комманды
А если с помощью мьютекса не пускать задачу, ожидающую RING, когда идет набор номера или прием смс нормальным будет решением?

Окончательная мысль в том, что получаем все строки от модема, те которые нас не интереуют в данный момнет, пропускаем мимо "ушей").
ЮРЦ нас инересуют всегда и везде, но только те которые нас интересуют.

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

При приходет ответа, функция разбора ответа, видит, что порт занят, той функцией, и обрабатывает ответ в ее контексте.
Если ответ подразумевает отпускание юарта, то он отпускается.

В общем, как-то так)


Это не нормальное, это правильное решение!

А как Вы обрабатываете ситуацию когда URC приходит непосредственно перед отправкой команды модему?

Для этого, этого использую контроль потока.
Процессок, перед проходом по "отправляющим" функциям, выставляет сигнал РТЦ.
После выхода, убирает.

Вы имеете ввиду RTS?

да, ртс

Ну это скорее к отсрочке чем к отработке относится. Самое интересное это как отличить URC от ответа на команду?

По этому поводу нашел вот такую ссылку

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

Список юрц известен, просто проверяем каждую строку на начало интересующего юрц, если совпало - значит пришел юрц.
Если пришел ок или еррор или еще чего, то мы же знаем, в каком состоянии находится порт==знаем какую последнюю команду отправили, соответсвенно можем и ответ обработать.
К тому-же на 90% ответов можно сделать такую-же ловушку как на юрц, если строка начинается на что-то, значит это ответ.

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

Спасибо. У меня на том же принципе все построено (эхо включено и анализирую эхо команды). Из плюсов получаю на выходе TX модема следить за командами и ответами. Но вот гарантированно ли URC не вклинивается между эхом команды и результатом ее выполнения нигде в документах не нашел.

Если я правильно Вас понял то ответы у Вас парсятся обработчиком текущей команды. Так вот чтоб в каждом парсере не вылавливать все возможные URC и пригодилось бы всегда знать что мы получили: результат выполнения команды или URC.

У меня такой проблемы нет. После отправки команды модему жду (с тайм-аутом) получения эха команды. После получения эха все строки до OK, ERROR , CONNECT и др. считаются результатом выполнения команды.

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

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

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

void ProcessOKAnswer(char who_called)
{
if(GL_GSM_STATES.UART_State == GSM_STATE_TIME_SYNCHRONISATOR)
{
TMR_ProcessAnswer(TRUE);
}
else if(GL_GSM_STATES.UART_State == GSM_STATE_VOICECALLREJECTING)
{
GSMSetUARTState(11, GSM_STATE_FREE);
}
else if(GL_GSM_STATES.UART_State == GSM_STATE_VOICECALLANSWERING)
{
GSMSetUARTState(12, GSM_STATE_VOICECALLONGOING);
GLF_SetOutgoingCallTime(1, 60);
}
}

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

Проверялось, но хотелось бы убедиться в этом и документально.

GSM 0710, Time that a station will wait for an acknowledgement before resorting to other action, 100 milliseconds

Думаю это что-то другое. 0710 я не использую и не планирую пока