Есть ли классика обработки ответов от GSM модуля на стороне МК ?, Асинхронный режим, без контроля потока Опции

[vassabi]

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

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

[vassabi]

Отсекая строки по 0D 0A...

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

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

в Очередь сообщений FreeRTOS

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

откусывается кусок RAM в несколько кБ

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

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

Сообщение отредактировал vassabi - Mar 17 2013, 13:07

[kan35]

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

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

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

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

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

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

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

Соглашусь.

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

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