Алгоритм общения с GSM/GPRS модулем, Разбор посылаемых модемом строк, время ожидания Опции

[Slonofil]

Доброго времени суток, уважаемые!

Сажусь писать программу под PIC18 для общения с SIM300DZ в составе модема GNS-300RS. В общих чертах всё понятно: отсылается строка, принимается и разбирается ответ. С отсылкой строк более-менее просто, например putrsUSART ((const far rom char *)"AT+CSMINS?\r\n"); А вот с разбором строк и временем ожидания ответа от модема (в особенности при работе с GPRS) пока туго... хочется сделать нечто автоматизированное, чтобы был массив или структура с запросом, временем ожидания ответа, типовыми ответами и идентификаторами действий, связанных с теми или иными типами ответов. Мне это видится приблизительно так:

Код

struct GSM_Struct
{
    char Send[XX];
    unsigned int Timeout;
    char Receive[YY];
    unsigned char State[Z];
} GSM[NUMBER_OF_OPERATIONS];

Верно ли я подхожу к решению этой задачи? Может ли кто-нибудь поделиться мыслями на этот счёт? Кто как делает разбор приходящих строк? В особенности при работе с GPRS.

Ещё хотелось бы узнать, какие начальные настройки модема должны производиться при его первом запуске.

Добавлю ещё, что устройство, которое будет работать с модемом, призвано делать много чего ещё помимо общения с интернетом, причём это "много чего ещё" является более приоритетным. Логика работы такова, что даже при зависаниях связи/железа SIM300 (в перспективе SIM900) должны выполняться основные задачи.

Думаю, Ваши ответы очень помогут многим начинающим освоиться с темой. Спасибо всем! С уважением, Максим.

[Dron_Gus]

Если нужно делать "много чего" с модемом стоит посмотреть на GSMmux. Получите несколько виртуальных портов. не надо будет делить ресурс.

[Slonofil]

Не могли бы Вы пояснить, что такое GSMmux?

[Dron_Gus]

Мультиплексор нескольких логических каналов (виртуальных последовательных портов) в один физический (железный uart). Позволяет получить несколько "виртуальных" портов. В них можно независимо (в разумных пределах) слать сообщения и получать ответы. Позволяет нескольким задачам общаться с модемом одновременно.

[CADiLO]

Описано в документе: http://microchip.ua/simcom/GSM-GPRS-GPS/SI...exor%20v1.2.pdf

[Slonofil]

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

В конце концов, может, этот вопрос уже всесторонне обсуждался на форуме? Ткните ссылочкой, плиз! К сожалению, нет возможности просмотреть весь форум на предмет искомой темы...

Сообщение отредактировал Slonofil - Aug 27 2010, 13:34

[Dron_Gus]

Слишком много нюансов. Я делал на вложенной машине состояний. Т.е. есть глобальные состояния типа "Подключение", "отключение", "перезагрузка", "бездействие". Была очередь команд. В состоянии "бездействие" эта очередь читалась, далее переход в нужное состояние. В каждом состоянии множество подсостояний "Отправка команды", "ожидание ответа", "еще что-то там" и т.д. На эти глобальные состояния таймауты. Все входящие (от модема) сообщения парсятся до основного switch'а, некоторый набор сообщений отсеивается (типа +CREG и тому подобных) тогда можно усыпить драйвер до прихода следующего сообщения или до истечения таймаута. Если неизвестное сообщение, то "спускаемся" в swith (возможно сообщение ожидается в текущем состоянии). Если состояние ожидало сообщение, то Ок, иначе еще один "пост"-парсер. Туда обычно падают сообщения об ошибках и тому подобные редкие сообщения. Как-то так.

[Slonofil]

Спасибо! Уже предметно. Я примерно так и думал. А нельзя ли чуть-чуть поподробнее?

[av-master]

Немного непонятна тема. ИМХО все пишут по разному...
Процы щас очень быстрые и все успевают....
у меня просто по прерывания работает с разным уровнем приоритета.
в ответственных быстрых местах (например декодер DTMF) просто необрабатываю прерывания. с меньшим приоритеом, после освобождения ресурсов все догонит. темболее управление потоком на автомате работает.

[Dron_Gus]

А куда подробней? Код, к сожалению показать не могу. Есть еще несколько ньюансов. Типа вложенности состояний. Чтобы после каждой команды модему в каждом "большом" состоянии не ждать ответа "Ок", его можно вынести в отдельное состояние. Для уобства я делал некое подобие стека вызовов. Т.е. из состояния "Бездействие" мы как бы "вызываем" состояние "подключиться", посылаем какую-нить команду и "вызываем" состояние "ожидание_ок". Чтобы реалиовать такие "вызовы" нужно уметь "сохранять" текущее состояние. Я просто заводил массив структур. Каждая структура - описание состояния: состояние, оставшийся таймаут и еще некоторые параметры. При вызове просто инкрементируем указатель (индекс) этого массива и инициализируем новое "состояние" (удобно наследовать оставшийся таймаут вызваному состоянию). При выходе - декрементируем и как бы попадаем обратно (плюс некоторая математика с таймаутами). Некое подобие вложенных вызовов. Можно реализовать и классическим методом через функции, но накладные расходы велики. таким образом получаем некий АПИ для работы с модемом, который опирается сам на себя и на более просты функции.

З.Ы. извиняюсь за дилетиантское описание.

[andrewlekar]

Через машину состояний как-то сильно круто. Для работы с модемом не актуально, потому что в один момент времени может быть только одно обращение к модему и можно тупо оформить цикл ожидания до прихода ответа. Внутри цикла поллинг других вещей типа индикации если нет оси. Если есть многозадачная ось, то вообще ничего дополнительно не требуется.
Если всё-таки есть желание писать программу на конечных автоматах, то рекомендую погуглить QPC. Очень нехилый (и вроде бы живой) фреймворк. Имеет даже допиленный lwIP.

[kovz]

Если всё-таки есть желание писать программу на конечных автоматах, то рекомендую погуглить QPC. Очень нехилый (и вроде бы живой) фреймворк. Имеет даже допиленный lwIP.

+1 за QP. Действительно живой и продвинутый framework. Сам пользуюсь, только на С++.

[Slonofil]

Спасибо всем за ответы!

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

Проц у меня простенький, PIC18F8627 (если не хватит памяти на всё про всё, возьму 8722), под задачу общения с модемом осталось уже меньше трети памяти. Вот и гадаю, сумею ли уместиться.

2 Dron_Gus: огромное спасибо, очень предметно и по теме! Мои мысли о реализации очень похожи на Ваши. Кое-что Вы мне прояснили.

2 andrewlekar и kovz: обязательно погляжу на QPC. Спасибо!

Сообщение отредактировал Slonofil - Aug 30 2010, 08:30

[Dron_Gus]

Не буду спорить, можно проще. У меня была ОС и было несколько потоков, которые обращались к модему. Передача данных, опрос аккумулятора, сбор данных о сотах, СМС. У меня такое решение родилось после долгих мучений. Мне кажется вполне адекватным.

З.Ы. жаль, что в sim508 плохо работал gsmMUX, возможно вышло бы проще.

[Slonofil]

Ну, у меня весьма тривиальная задача, насколько я её вижу. Нужно лишь выходить через GPRS и запросами GET/POST передавать данные, принимать настройки и (в планах) принимать обновление прошивки для контроллера. Ни звонков, ни SMS, ни DTMF не планирую. Так что, скорее всего, буду лепить массив структур.